Pages: [1] 2
  Print  
Author Topic: bug: Cannot restore D-Link DIR-655 configuration via HTTPS.  (Read 9679 times)
Al Dente
Level 1 Member
*
Posts: 9


« on: January 25, 2010, 05:13:21 PM »

Under D-Link DIR-655 hardware version A3 and firmware 1.32NA, the latest released North American DIR-655 firmware, attempting to restore the router's configuration using HTTPS fails. Restoring the router's configuration using HTTP works correctly. I believe this was also broken in firmware 1.21.

Steps to reproduce:

1) Open D-Link DIR-655 System Settings page at [D-Link DIR-655 web server]->Tools->System, i.e., https://[DIR-655 IP address]/Tools/System.shtml (or http:).
2) Save the current router configuration to a file with Save Configuation.
3) From the System Settings page at https://[DIR-655 IP address]/Tools/System.shtml (NOT http:), attempt to restore the saved router configuration using Restore Configuration from File.
4) Note error from router:
    Restore Invalid

    The restored configuration file is not correct.  You may have restored a file that is not intended for this device, or the restore file is from an incompatible version of this product, or the restored file may be corrupted.
    Try the restore again with valid restore configuration file.
    Please press the button below to continue configuring the router.


If you open the System Setting page at http://[DIR-655 IP address]/Tools/System.shtml (NOT https:), restoring the router configuration using Restore Configuration from File works correctly. I think this may have been a bug in the router firmware for quite a while.

This bug is not dependent on the router configuration settings involved. It occurs with any router configuration settings, including the Factory Defaults.

This bug is not dependent on the client's browser. It occurs under both Firefox 3.6 and Internet Explorer 8.0.

There is a simple work-around: Use HTTP instead of HTTPS to restore a saved router configuration. But it's silly to have to do that.

Please fix this bug and add HTTPS configuration testing to your internal firmware tests. Thanks.
Logged
Krusher
Level 2 Member
**
Posts: 73


« Reply #1 on: January 25, 2010, 08:53:26 PM »

So, that's why the restore feature doesn't work?  I never tried that since I always use https:// now.  Good find!
Logged
Al Dente
Level 1 Member
*
Posts: 9


« Reply #2 on: January 25, 2010, 09:07:35 PM »

It looks like it.

Like you, I had always used HTTPS to access the router web server. And restoring a configuration never worked. But since I only tried to restore after firmware upgrades, I thought maybe the configuration settings file format changed across firmware revisions. Then I saw a post that instructed the user to save and restore the router configuration across a firmware upgrade, and realized something was wrong.

I would guess this bug has frustrated and wasted the time of a significant number of customers. But at least the work-around is trivial. Hopefully a fix won't take long.
Logged
Cobra
Level 4 Member
****
Posts: 477



« Reply #3 on: January 25, 2010, 09:34:32 PM »

Seems pointless to use https unless you are loading the config file outside your LAN which I doubt you are.
Logged
lotacus
Level 4 Member
****
Posts: 450


« Reply #4 on: January 26, 2010, 12:02:37 AM »

not really that pointless. if the admin is on a large network, then it is a little bit more added security. Though if the admin was on a large network, I would hope he would be using something other than a dir-655. A little arp poisoning could circumvent that Tongue
Logged
Al Dente
Level 1 Member
*
Posts: 9


« Reply #5 on: January 26, 2010, 04:06:55 PM »

To a reasonable level, more security is better. Thinking otherwise is stupid.
« Last Edit: January 26, 2010, 04:10:50 PM by Al Dente » Logged
sideloaded2
Level 1 Member
*
Posts: 5


« Reply #6 on: January 26, 2010, 04:53:57 PM »

If it's pointless then they should take it out.  Roll Eyes
Logged
lotacus
Level 4 Member
****
Posts: 450


« Reply #7 on: January 26, 2010, 05:27:31 PM »

I would say false sense of security.
Logged
Al Dente
Level 1 Member
*
Posts: 9


« Reply #8 on: January 30, 2010, 02:29:09 PM »

I realize D-Link has had a number of other more significant DIR-655 bugs to fix recently.

Has anyone from D-Link seen this bug report? Has this bug been reported to someone who will fix it? What is the ETA for a fix?
Logged
EddieZ
Level 11 Member
*
Posts: 2500



« Reply #9 on: January 30, 2010, 03:57:19 PM »

I realize D-Link has had a number of other more significant DIR-655 bugs to fix recently.

Has anyone from D-Link seen this bug report? Has this bug been reported to someone who will fix it? What is the ETA for a fix?

beta section.... 1.33
Logged

DIR-655 H/W: A2 FW: 1.33
Al Dente
Level 1 Member
*
Posts: 9


« Reply #10 on: January 30, 2010, 09:49:58 PM »

Apologies for being obtuse, but what do you mean? I have DIR-655 firmware 1.33NA installed. This bug still exists in firmware 1.33NA and there is no mention of a fix in the release notes. Is there a different beta version of the firmware that includes a fix for this bug?
Logged
Cobra
Level 4 Member
****
Posts: 477



« Reply #11 on: January 30, 2010, 10:08:47 PM »

I don't think it is a bug.

Https is NOT recommended for any manufacturers firmware upgrade process that I know of so I assume restoring the config would be the same.

For example, from DD-WRT site:
Quote
Do NOT flash your firmware over an SSL (HTTPS) connection. Make sure you are using HTTP.
Logged
Al Dente
Level 1 Member
*
Posts: 9


« Reply #12 on: January 31, 2010, 06:27:18 AM »

SSL / TLS shouldn't matter here. Why should it? Upgrading the DIR-655's firmware over https: works correctly. This bug only affects restoring the DIR-655's configuration over https:.

In any case, it seems like any reasonable user would agree that the error message generated by the DIR-655 when attempting to restore the router's configuration over https: is bogus:

    Restore Invalid

    The restored configuration file is not correct.  You may have restored a file that is not intended for this device, or the restore file is from an incompatible version of this product, or the restored file may be corrupted.
    Try the restore again with valid restore configuration file.
    Please press the button below to continue configuring the router.


How does this fail to qualify as a bug?
Logged
EddieZ
Level 11 Member
*
Posts: 2500



« Reply #13 on: January 31, 2010, 07:34:56 AM »

SSL / TLS shouldn't matter here. Why should it? Upgrading the DIR-655's firmware over https: works correctly. This bug only affects restoring the DIR-655's configuration over https:.

In any case, it seems like any reasonable user would agree that the error message generated by the DIR-655 when attempting to restore the router's configuration over https: is bogus:

    Restore Invalid

    The restored configuration file is not correct.  You may have restored a file that is not intended for this device, or the restore file is from an incompatible version of this product, or the restored file may be corrupted.
    Try the restore again with valid restore configuration file.
    Please press the button below to continue configuring the router.


How does this fail to qualify as a bug?

If the restore feature was meant to work with https and it doesn't that might qualify as a bug. If it wasn't designed to do so, its working properly. You might want to send an email to Dlink support.
Logged

DIR-655 H/W: A2 FW: 1.33
Al Dente
Level 1 Member
*
Posts: 9


« Reply #14 on: January 31, 2010, 09:49:02 PM »

To be clear, there is obviously no sensible way to describe the DIR-655's behavior here as correct. It's either a bug that the DIR-655 can't restore configuration over https:, or it's a bug that the DIR-655 reports a bogus error message in response to such an attempt. The former appears to be the obvious bug.

From other threads, it is clear that D-Link employees read the forum threads. For example, after I posted steps (http://forums.dlink.com/index.php?topic=10458.msg62628#msg62628) to reproduce the HNAP security hole on the DIR-655, that post was redacted by a D-Link moderator within 15 minutes. Three days later, D-Link made beta firmware available that fixed that bug. And six days after the beta release, D-Link released retail firmware that fixed that bug.

So it would seem that my initial post in this thread is sufficient as a bug report.

D-Link's responses to issues such as these are useful data points for customers.
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Theme by webtechnica.com.