D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-655 => Topic started by: mbtoloczko on November 14, 2009, 05:08:23 AM
-
I just bought a second DIR-655 (A4) for a friend, and upgraded the firmware to 1.32NA. After I enabled NTP lookup in the options, the router started crashing continuously. I had to use the manual reset button to regain control, and the second time through I avoided enabling NTP. Working great now. I haven't tried duplicating the crash, but thought I would mention it anyhow.
-
You would think somebody would care about this, wouldn't you?
Its been documented and written about really well on this forum, and yet, the problem still exists...
Good on you for posting anyways though
-
minor issues will remain... As with all other software and more or less all firmwares from whatever brand.
-
It's not a minor issue. If you run into it and you aren't extremely tech savvy, it's going to bring you down permanently.
And, even more worrisome, is that it shows the crap error handling that they use over at dlink HQ.
You show your bias by basically supporting this NOT being fixed. How silly.
-
It's not a minor issue. If you run into it and you aren't extremely tech savvy, it's going to bring you down permanently.
And, even more worrisome, is that it shows the **** error handling that they use over at dlink HQ.
You show your bias by basically supporting this NOT being fixed. How silly.
It's minor since choosing 99% of other NTP will work. And will give the same result (time) ;)
I'm in IT and know something about issue/bug classification. This is not a major bug. Also I cannot reproduce any of the NTP crashes. Not even with the pool ntp's. So I doubt firmware is th cause.
Major issues get solved first, minor issues might never get ssolved. D-link is no exception to that. And rule number one in bugfixing: never fix more then 1 issue simultanuously in the code by different coders. And luckily they're doing that, doing it step by step.
-
I just bought a second DIR-655 (A4) for a friend, and upgraded the firmware to 1.32NA. After I enabled NTP lookup in the options, the router started crashing continuously. I had to use the manual reset button to regain control, and the second time through I avoided enabling NTP. Working great now. I haven't tried duplicating the crash, but thought I would mention it anyhow.
Have you look at this side ? http://www.pool.ntp.org/zone/europe (http://www.pool.ntp.org/zone/europe)
rgs
kthaddock
-
It's minor since choosing 99% of other NTP will work. And will give the same result (time) ;)
I'm in IT and know something about issue/bug classification. This is not a major bug. Also I cannot reproduce any of the NTP crashes. Not even with the pool ntp's. So I doubt firmware is th cause.
Major issues get solved first, minor issues might never get ssolved. D-link is no exception to that. And rule number one in bugfixing: never fix more then 1 issue simultanuously in the code by different coders. And luckily they're doing that, doing it step by step.
Have tried several NTP sites. I have verified logs stating that connection to ntp site failed. This was followed by a reboot and resetting of time on several, but not all occasions. This leads me to believe NTP plays a role but isn't the only culprit for reboots. Manually setting time seems to help....... somewhat.
-
Try resetting to factory defaults, reflash and set it up manually. This has worked with many others experiencing reboots. I know it sux, but the flash mechanism can give these errors sometimes.
-
I've only been able to get the D-Link servers to work (aka the ones in the list). If I use something like ca.pool.ntp.org, the router just crashes and gets stuck in a reboot loop. That was with the 1.32NA final, haven't bothered trying with the beta09. D-Link's NTP works good enough.
-
I've only been able to get the D-Link servers to work (aka the ones in the list). If I use something like ca.pool.ntp.org, the router just crashes and gets stuck in a reboot loop. That was with the 1.32NA final, haven't bothered trying with the beta09. D-Link's NTP works good enough.
If you have wrote like in the text ca.pool.ntp.org (,) try to remove ,
rgs
kthaddock
-
It's minor since choosing 99% of other NTP will work. And will give the same result (time) ;)
I'm in IT and know something about issue/bug classification. This is not a major bug. Also I cannot reproduce any of the NTP crashes. Not even with the pool ntp's. So I doubt firmware is th cause.
Major issues get solved first, minor issues might never get ssolved. D-link is no exception to that. And rule number one in bugfixing: never fix more then 1 issue simultanuously in the code by different coders. And luckily they're doing that, doing it step by step.
If it isn't a bug, then its poor error handling.
-
Have tried several NTP sites. I have verified logs stating that connection to ntp site failed. This was followed by a reboot and resetting of time on several, but not all occasions. This leads me to believe NTP plays a role but isn't the only culprit for reboots. Manually setting time seems to help....... somewhat.
For me NTP causes the same problems. Only standard DLink NTP (chose from drop down on page) seems to work. Setting manual time does not work. Within a day it can lag half a day regarding time. This can be observed via syslog. The router seems to keep different time variables inside the code. Syslog prints two different ones if you disable NTP.....
Btw this is the first time I have seen a device not being to able general NTP. Severity is not A (saftey) nor B (show stopper) but certainly C (major annoyance). Handling time is a problem with the software versions. Have seem problems with this since March.
Which region are you from? I am from the Netherlands, maybe it is region related with GMT settings or whatever.
-
Mine works with d-link NTP and german ptbtime1.ptb.de without problems.
Did not try any other servers - to lazy ;D
(http://lizzi555.dyndns.org/PICS_ETC/time.png)
(http://lizzi555.dyndns.org/PICS_ETC/wanset.png)
-
I am using NTP for my 655 with 1.32NA firmware. The NTP server defined points to one of my telco's NTP servers.
Everything works fine. No issue at all. It's able to sync time on the pre-defined intervals.
-
I experienced this problem yesterday for the first time.
I've been using NTP with the server "hora.roa.es" (official time in Spain) for months, and only had the issue of the router time being changed sometimes (specially with no active WAN connection). Yesterday morning I found my network connection rebooting constantly, and I could barely access the admin interface to reboot it. The rebooting only stopped when I disconnected the WAN cable, so I did it and then logged to the admin interface to disable NTP. Now the router works normally.
-
I am having the exact same problem. I've tried both the internally coded NTP servers (ntp1.dlink.com, ntp.dlink.com.tw). In the log it shows they have been unsuccessful sync'ing the time. So I tried ca.pool.ntp.org, and even the north-america.pool.ntp.org servers. This sends my router into a downward spiral and it becomes a $109 useless brick.
I had NTP turned off at home last night. This morning remotely from work I tried to set it up again, but the same crap happened. My WAN connection goes mental as you can see from my ping output below:
ping -a x.x.x.x
PING x.x.x.x (x.x.x.x): 56 data bytes
64 bytes from x.x.x.x: icmp_seq=11 ttl=58 time=17.784 ms
64 bytes from x.x.x.x: icmp_seq=12 ttl=58 time=1607.947 ms
64 bytes from x.x.x.x: icmp_seq=13 ttl=58 time=607.836 ms
64 bytes from x.x.x.x: icmp_seq=14 ttl=58 time=2406.850 ms
64 bytes from x.x.x.x: icmp_seq=15 ttl=58 time=1406.759 ms
64 bytes from x.x.x.x: icmp_seq=16 ttl=58 time=406.635 ms
64 bytes from x.x.x.x: icmp_seq=28 ttl=58 time=17.844 ms
<snip>
.
.
.
<snip>
64 bytes from x.x.x.x: icmp_seq=2434 ttl=58 time=29.192 ms
64 bytes from x.x.x.x: icmp_seq=2435 ttl=58 time=18.902 ms
64 bytes from x.x.x.x: icmp_seq=2436 ttl=58 time=1002.894 ms
64 bytes from x.x.x.x: icmp_seq=2437 ttl=58 time=18.679 ms
64 bytes from x.x.x.x: icmp_seq=2438 ttl=58 time=1810.220 ms
64 bytes from x.x.x.x: icmp_seq=2439 ttl=58 time=810.122 ms
^C
--- x.x.x.x ping statistics ---
2446 packets transmitted, 834 packets received, 65% packet loss
round-trip min/avg/max/stddev = 16.796/916.474/3225.398/771.878 ms
Look at the amount of packet loss (65%), and the terrible round trip times! And this all because of flaky NTP implementation. I need time to be synchronised because I use schedules.
I am also an irate customer of the physical power-cycle camp as I have to regularly physically power down/up the router to even obtain internet access. This router is becoming a POS with every passing minute.
C'mon Dlink, get your act together and do right by your customers... else you won't have any left.
-
Wow. Me too.
I know for a fact that one of my (now many) sets of rebooting issues was after I noticed that the router time was incorrect. I noticed it was getting a bad time from the default d-link NTP servers (Dec 28 2009 when it was Jan 6 2010).
I switched to time.windows.com which is what my PCs use. Since then, the NTP related flakiness seems to have died down and my device clock is now correct again. I haven't tried turning NTP off to further reduce my nearly constant reboots, but I think I will go try this now.
I am definitely thinking that my reboots are caused by maybe just one or two buggy features in the firmware. A simple dump and source code would prove it. But alas, no one from D-Link cares or wants to take me up on the offer to get them data.
-
@ironic77, I also figured out the using the seemingly problematic Dlink NTP servers was causing issues. I have remote access into my home network from my workplace based on a business day schedule (9pm-6pm). Since last week my attempts to remotely connect have failed and I didn't know why. Yesterday I figured out that the time on my DIR-655 was way off, just like yours... causing me to not have remote access.
So that's when I started moving away from D-Link's NTP servers. Something is wrong with them. Trying the pool addresses have caused havoc with my internet access now. Router is rebooting every 30 seconds!
-
If using Windows, open the clock and choose one of those other than time.windows.com
-
I can't say how happy I am to have found this thread. I am having the exact same issue and was going nuts trying to figure out what was wrong with my router. For now I have disabled NTP and all is well.
Any idea when or if DLink will actually fix this?
-
The problem has existed for some time and is well documented here:
http://forums.dlink.com/index.php?topic=5980.0
Make sure the ntp server you want to use is NOT part of a pool or using a round-robin dns. Don't use something like time.apple.com or time.microsoft.com because those are certainly servicing ntp requests by using several machines. Perhaps your ISP has a single ntp server.
If you get into the reboot loop, then unplug the cable to the WAN interface and the rebooting will stop. After that you can connect to the router again and change your ntp settings.
By the way, on my router the option to manually set the time doesn't work either. It sets the time correctly when I save the changes in the web interface, but then it also resets the time to the same thing the next time I log on to the web interface. I've just stopped trying to use schedules at all, so it doesn't matter that the time is always wrong.