D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-655 => Topic started by: Al Dente 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.
-
So, that's why the restore feature doesn't work? I never tried that since I always use https:// now. Good find!
-
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.
-
Seems pointless to use https unless you are loading the config file outside your LAN which I doubt you are.
-
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 :P
-
To a reasonable level, more security is better. Thinking otherwise is stupid.
-
If it's pointless then they should take it out. ::)
-
I would say false sense of security.
-
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?
-
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
-
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?
-
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:
Do NOT flash your firmware over an SSL (HTTPS) connection. Make sure you are using HTTP.
-
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?
-
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.
-
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 (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.
-
Can't see that is a problem !
Do you update your router daily?
What I have seen on other routers, you can't restor on HTTPS.
Anyway you have to do a reset before you update and restor your settings.
I don't think that is a problem. Just accept I't !!!
kthaddock
-
The more I read the dlink forums, the more I think that some people on this board have no clue about quality control or are in some sort of denial about the quality of the firmware. If a feature exists, and it doesn't work correctly, then its definitely a bug, and it should be fixed. Whether or not the feature was unintentionally added has nothing to do with whether its a bug. It only affects the path to resolution. If its an unintentional feature, then remove it. If its a purposely added feature, then fix it.
-
Won't happen.
There will never be "the" perfect solution or "the" perfect router or firmware. Deal with the fact that nothing in life is perfect and company's are not out to please only 1 person, or a group of people. Pros and Cons I am sure, are always weighed and I am sure there will always be 1 person pointing out SOMETHING that needs to be fixed, as insignificant as it may be.
Case in point: I have had NO problems with the dir above f/w 1.2 where others have.
I have had continuous problems with f/w above 1.2 where others have not.
How could this be?
-
It's quite simple: if https was not meant to be used (as with lots of other routers), there is no bug. Wanting the feature is an entirely different story.
Dlink determines what they put in and what they don't put in and how they want to sell it. They also decide how to manage this in accordance with their line of products. So either request this feature to be added (risking a No, but thanks for your consideration) OR plenty buy shares so you can manage the company. ;)
So if you're desired feature is not there, don't call it a bug.
It's like picking a wife, you chose her because of the features she has, not because you can ***** about the lack of certain features.
-
It seems any reasonable observer would agree with mbtoloczko. This thread provides some clear examples of buffoons posting nonsensical responses to a bug report.
It poses the common internet forum puzzle. Are they dimwits? Trolls? Shills attempting to drive the signal to noise ratio to 0?
-
nah. it's just done so that everything gets out of context and the thread locked.
-
Hasn't worked yet though...
-
LOL. ITS A BUG. DROP IT.
-
'Facts' are facts because they can be proven and confirmed. Unless someone can prove Dlink intended the https port to have the feature (unlike other brands) this qualification is merely an opinion.
-
The Slashdot posters who claimed D-Link would only fix a bug that was given wide public exposure appear to have been correct. (See http://it.slashdot.org/story/10/01/19/0147239/D-Link-Warns-of-Vulnerable-Routers (http://it.slashdot.org/story/10/01/19/0147239/D-Link-Warns-of-Vulnerable-Routers).) There's been no acknowledgment from D-Link of the bug I reported in this thread. Although it did give the forum buffoons et alia something to do. They would do well to continue to put the word "facts" in quotation marks whenever they use it.
The incompetence D-Link demonstrated in handling the HNAP security vulnerability was another cause for concern. D-Link was unable to reproduce the widely discussed HNAP bug on the then-current DIR-655 firmware release without being led by the hand through the steps. The original description of the HNAP security vulnerability was posted at http://www.sourcesec.com/2010/01/09/d-link-routers-one-hack-to-own-them-all/ (http://www.sourcesec.com/2010/01/09/d-link-routers-one-hack-to-own-them-all/) 10 days before I posted the steps to this forum. See my post and the D-Link moderator's reply at http://forums.dlink.com/index.php?topic=10458.15 (http://forums.dlink.com/index.php?topic=10458.15). Had I not posted painfully detailed steps to reproduce the HNAP security vulnerability to this forum, that bug might still not be fixed.
Here are some posts from the above linked Slashdot article concerning the HNAP security vulnerability that appear to fit the observed facts. From http://slashdot.org/comments.pl?sid=1515222&cid=30816580 (http://slashdot.org/comments.pl?sid=1515222&cid=30816580):
Have you ever tried to contact D-Link? Remember, they have DDOS'd NTP servers, and they continue to publish BUGGY dynamic DNS clients even when given bug reports.
D-Link outsources their routers to 3rd parties. The developers can not follow bug reports unless, sadly, they are written in Mandarin or Simple Chinese. And unless the bug report is blindingly and stupidly obvious (or on Slashdot), there's no one at D-Link US headquarters who cares enough to start a billable conversation with the contract developers. Don't expect D-Link QA in India to catch it - D-Link USA did not put this in the test plan! And the router tech support (all outsourced to India) doesn't gain anything by presenting issues back to Corporate.
Yes, I've worked with D-Link in one of the above scenarios. The best way to contact them is via a non-company contact, such as one of their major shareholders. I'm not [redacted] kidding either.
From http://slashdot.org/comments.pl?sid=1515222&cid=30818570 (http://slashdot.org/comments.pl?sid=1515222&cid=30818570):
DLink's response to everything consumer-grade is is thus.
1. Act dumb (well, they're not REALLY acting)
2. Sit on hands
3. Offer an exchange
4. Hope the problem customer just "goes away".
Years of experience with trying to get them to actually SUPPORT the [redacted] they ship has taught me this.
Given these data points, it makes sense to move on to any one of D-Link's large number of competitors to see if they act more competently and responsibly. I take my time and security seriously even if D-Link does not. Does anyone have data to offer to dispute these conclusions? For example, will this post produce a response from D-Link?
-
Good to see that tons op people 'know' how to run a business. Their main goal is to make money for their shareholders, and if this is the way they want to do that: fine. If you, as a consumer, require more from your hardware supplier (like 5 breaks a day for employees, free lunch tickets, specific testprograms etc) you might to consider applying for an executive position at Dlink ;D
-
I dont think he speaks manderin.
-
I've seem some testing reports from Dlink and they are all in plain English, both the tester review and test manager remarks about severity etc.
So they might have changed their outsourcing vendors in between, that can happen. Although our testing and development (at a large multinational bank) is done by TCS and Infosys, with large offshore teams. And that hasn't given us a lot of real issues...