D-Link → Re: DI 624 Rev C 2.45b24 Firmware!

said by Pla9:

---

So far after the updating to this firmware it hasn't rebooted even once!!! That's 5 days without a single reboot.

---

Pla have you tried turbo yet? I'm using 2.45b24 with static turbo and still getting the 2.4 GHz SS phone reboot issue.

And Talon88 is way off on this issue, it is a dlink problem! If there is interference its ok to drop the wireless signal but not to reboot the entire router. Its like your car restarting itself just because you drove thru a tunnel and lost the signal to your AM radio. Its ok for the radio to drop the signal but not for anything to turn itself on and off, over and over again, until the interference is removed.

Not yet, I switched to dynamic turbo to see if it is stable. Dynamic turbo stays at 54 mbps most of the time so the problem may not appear.
I'll try static turbo to see if this firmware is any better.

:::

Maybe because those 2.4G phone radio signal mixed
with the WiFi signal, then the router recieved
this kind of super crazy signal & start the error
correction, CRC.... but, because the signal became
too crazy, the router is OD & kill itself by reboot.

Maybe D-Link is abit less strong enough to stand
for this crazy OD than other brand, Not sure is
the stupid Firmware OS or Hardware....!

By the way feed it less 2.4G Phone Drug & keep it
stay behind OD may help ..... haha....!

:::

Talon --

new 2.50 version to try out (at least this isn't boring!)... check the other thread:
»New firmware for DI-624: 2.50

I just loaded 2.50 (from Israel!) - seems to work fine (but they all seem to for me). Give it a try...

said by jonazen:

---

I just loaded 2.50 (from Israel!) - seems to work fine (but they all seem to for me).

---

Jonazen, did your gas mileage increase again after upgrading to fw 2.50

Talon, your right there could be number of reasons (fw/hw) that are the cause of the 2.4ghz phone reboots. Though interference should never cause the unit to reboot but only cause it to drop the wireless connection. The strange thing is the phone never causes the 624 to drop the wireless connections when in use. All connections remain strong during the phone call. You only lose the connections when the units starts its endless rebooting.

And you'll notice that dlink monitors this forum and they never defend this behavior. They agree that interference may cause the unit to loose the wireless connection but they never agree that wireless interference should cause the entire unit to reboot over and over and over again. So the interference isn't strong enough to drop the wireless connection by its self but the interference is strong enough to reboot the entire router which then causes the wireless connection to drop

Hey SoCal -

It's getting embarassing to post here! Enough unhappy people so that I'm starting to feel a bit guilty that my own experience has been so good...

Your point is one that I've thought about every time I read more about this issue. RF interference from sources like 2.4 ghz phones will certainly degrade the radio signal. But there's NO inherent reason that this should cause a router to reboot. None whatsoever. The rebooting is a symptom of either hardware or software design - period.

Ideally, the router firmware / hardware should be smart enough to use what it can of the signal -- and in cases of interference, simply deal with the reduced throughput & bandwidth. In general, if telecomm signals encounter interference, the systems at each end should "know" to retry until packets get through. Net effect might be declining throughput, and worst case - no throughput - but I fail to see why the hardware would have to reboot itself. The ONLY reason is should force its own reboot is if it encounters a condition from which it cannot recover.

If RF interference is causing an unrecoverable condition, this doesn't speak too highly of error and exception handling in the hardware and firmware. Having seen hundreds of software implementations (loads of different types of applications, platforms, etc), forcing a restart like this is often an "easy" way out of an ugly situation -- and is sometimes used as a substitute for proper software design. It lets the router "get back to work", but without dealing with the actual problem that's occurring.

But as you say - D-Link watches this forum, and for some reason, refuses to acknowledge the situation. It's a shame - because, as you know from experiences like mine, when conditions are right, the hardware really CAN perform well. I hope that D-Link will eventually go the extra mile and debug the device properly.