1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Random reboots with WRT54GL v1.1?

Discussion in 'Tomato Firmware' started by jdm157, Mar 9, 2009.

  1. jdm157

    jdm157 Addicted to LI Member

    Just upgraded to subject hardware and installed Tomato 1.23. Can't seem to get more than about a day's uptime...?! Known problem? With firmware or device? Is something triggering this? No Schedule or Scripts are set. Interestingly, when I was logged on to the device all weekend, it was fine and did not reboot.

    Apologies in advance if this has been discussed before. Searched the forum and did not see it.
  2. jdm157

    jdm157 Addicted to LI Member

    Did another search and yes I do see that this has been a problem for others and discussed elsewhere. Does anyone know of a solution? Is this problem solved under dd-wrt? The Broadcom wl drivers were suspected. FWIW, I have two Dell laptops each running the latest Dell WLAN drivers.
  3. RonWessels

    RonWessels Network Guru Member

    Try installing Victek's Tomato RAF 1.23.8513 ND from here. It uses a newer Broadcom driver than the stock Tomato ND version and has implemented the configuration fix required by the new driver. It's supposed to handle problematic wireless clients more gracefully.
  4. landa

    landa LI Guru Member

    Try to clear NVRAM (trought) and set-up manualy the router.
  5. Planiwa

    Planiwa LI Guru Member

  6. astehn

    astehn Addicted to LI Member

    For what it's worth, I had random reboots on 5 WRT54GL v1.1 routers in the apartment block I take care of when using the regular Tomato 1.23. Changing to the 1.23 ND version solved the problem, in conjunction with turning of the redundant features in the wlan driver known to cause problems with Intel cards (and maybe others). See http://www.linksysinfo.org/forums/showthread.php?t=60509&highlight=wireless+intel+fix

    So my recommendation would be to try upgrading to 1.23 ND, clearing the NVRAM (this will ensure that your reboots aren't coming from some corrupted setting), then re-configuring (including the following commands issued from telnet):

    nvram set wl_reg_mode=off
    nvram set wl0_reg_mode=off
    nvram commit

    Or, if you're interested in Victek's features, or your want the newest wireless driver, you can follow the good advice given by RonWessels. Note that Victek's 1.23.8513 ND version already defaults to the modified NVRAM settings I just mentioned. In either case, I recommend you take the time to clear NVRAM and re-configure for scratch, as it's the only way to be sure that the reboots aren't coming from some unknown problematic setting.
  7. Toastman

    Toastman Super Moderator Staff Member Member

    The use of the newer wireless drivers and the configuration above has made a dramatic improvement in the "random reboot" problem. But there is still something left that needs to be found and addressed if possible.

    On occasions an event will trigger a reboot for no apparent reason. The one that affects me quite regularly is when I connect to the Web GUI from my computer. I had previously established that when this happens the router is often only lightly loaded. Yesterday I had a little more feedback - because a user came to ask why the internet access was slow. He'd run speedtest and got 150kbps instead of the normal 3-4Mbps. When I connected to the router to check, it did not reply for a few minutes - it had rebooted when I connected. So it appears the router had been limping along in a stressed state for some time - and the HTTP connection then caused it to reboot. But stressed by what? The network was hardly in use.

    I have another site where I am using ASUS WL500gP v2 on an almost identical setup, and so far this has never happened on that system. I don't believe it has happened on any of my WRT54GL's which are just used as AP's either, they stay up for many months.

    I'm not sure we'll ever get to the bottom of this, unless somehow we can write some meaningful logs during the time leading up to the reboot - but currently there is almost no information.

    EDIT: On several occasions now I have been lucky enough to notice something happening to cause the slowdown/reboot. A machine on the network send many thousands of DNS lookups and connection requests all at the same time, the router just quails under the onslaught, but it's all over in seconds. P2P and DHT, perhaps DNA too, seems to be responsible. Nothing much appears in the logs, in fact it's usually not possible to access the logs. I made it to the conntrack page one time and hit the "drop idle" button, and 17 seconds later the router recovered. Now - I want to see if it's possible to trigger an immediate "drop idle" event if a defined threshold is reached.
  8. Planiwa

    Planiwa LI Guru Member

    The reboots I don't mind anymore.

    It's getting stuck. I know of two stuck-modes:

    1. Wifi clients associate and get leases, but none are routed. -- I can now detect this, and WL down/up or reboot if necessary.

    2. There is no way to get into the router, either Wifi or Ether.
    WLAn appears to be up. SSID is broadcast, but passwords appear to be inoperative (could be a client misfeature)
    WAN is long gone. No DSL problem. No connection attempt.

    The (frequently) affected one is a WRT54GLv1.2 -- no button.
    I plan to get it to leave secret messages in the modem (which runs Unix) later.

    For now, I have a script scheduled every 30 minutes. (Naturally the condition hasn't happened since I installed the script, so I'm waiting to see if it works.):

    LNS=$(nvram get wan_gateway)
    ping -c3 -q $LNS >/dev/null 2>&1
    if [ $RC -gt 0 ]
    then if [ -f /tmp/STUCK ]
         then reboot     
         else touch /tmp/STUCK
    else rm -f /tmp/STUCK
  9. Toastman

    Toastman Super Moderator Staff Member Member

    Hmm not much help to you - but:

    1) Had this happen with various wireless clients, mostly Intel. Almost all of them cured by:

    a) changing to latest wireless drivers on the router, with correct config. as shown above.
    b) changing mode from using Windows Zero Configuration Utility to manufacturer's own - or vice versa (!!)
    c) In the case of a zyxel USB wireless adapter, throwing it in the nearest bin...
    d) Has a couple of latest Intel "n" cards which are completely unpredictable - no cure yet.​

    2) Not had this happen to me... or at least, not the same way..

    One way to get routers "stuck" is when they lose power during a power cut, then if the power is restored and then immediately cut off again by a trip somewhere. But when this happens, generally the router is completely dead, with power light flashing. Having said that, it is only a rare occurrence though. I put a 4,700MFD capacitor in a few routers on the incoming power line, and those routers don't do it any more (normally there is only a 22MFD reservoir capacitor). A UPS is the answer to a lot of ills.
  10. jdm157

    jdm157 Addicted to LI Member

    Thanks to all of you for your help and suggestions. I have flashed and reconfigured by hand Tomato Firmware v1.23.8513 RAF ND by Victek (thank you, Victek!). We'll see how this runs for about a week and I will report back.
  11. jdm157

    jdm157 Addicted to LI Member

    Quick update: Big difference. The WRT54GL is much more stable with Victek's 8513 ND version. Going on 3+ days with no random rebooting and good performance as seen by all clients on the net. Next week: going to throw a Vonage voip router on the LAN, set some QoS and see how we do.
  12. RonWessels

    RonWessels Network Guru Member

    Thanks for the update. Good to hear that you're getting good performance.
  13. jdm157

    jdm157 Addicted to LI Member

    I promised I would report results of the random reboot issue after switching to Victek's 8513 ND version:

    Been up 8 days and running solid as a rock. Low CPU usage. Good throughput. Running WPA/WPA2 and have some 802.11n clients on the LAN. Have added a Vonage V-Portal behind the WRT54GL and configged some QoS. Working fine. (As reported elsewhere in this forum, the Vonage device keeps an outbound connection to the mother ship alive on port 10000 (for me) so that inbound calls do not need port forwarding through the firewall. It's plug n play.) The telemetry available from this firmware is just fantastic. Can never go back to commercial firmware again. Thinking about adding WDS at some point. Will likely reboot tonight to change some logging settings, and then see if it goes a month. Any questions, let me know. Thanks to you all for the feedback. Would never have found Tomato + Victek without you.
  14. everdred

    everdred Addicted to LI Member

    Does anyone know if this problem still exists in new releases of Tomato (1.24, 1.25)?
  15. jdm157

    jdm157 Addicted to LI Member

    Sorry, I cannot help you with that because I am still running the 1.23 Victec version as in my sig below. I has been rock solid. Uptime is now about 80 days! The only configuration change I made to what I described earlier in this thread is that I added a 2nd WRT54GL and enabled WDS. With this kind of stability and performance I am reluctant to immediately upgrade to the latest version, especially if I have to manually reconfig 2 routers.
  16. Toastman

    Toastman Super Moderator Staff Member Member

    Interesting, as this thread was resurrected, I realised that I have actually also gone back to 8513, for stability reasons. Various compiles since that one seem to all have minor issues which, although I can't seem to put my finger on anything, don't happen so much in 8513....
  17. Alucard

    Alucard Addicted to LI Member


    I am having this problem with a WRT54GL, random reboots on both 1.23 and 1.25, which is what led me here. Based on this and other threads I am going to try Tomato's ND version first, and report back. nvram get wl0_corerev = 9 on my model.
  18. FattysGoneWild

    FattysGoneWild LI Guru Member

    Hey Toastman. You said you gone back to 8513 Is that with official Tomato or Vicktek's mod?

  19. TVTV

    TVTV LI Guru Member

    Alucard, do you have Intel wireless clients on the network? Those can sometimes cause the router to reboot.
  20. TVTV

    TVTV LI Guru Member

    P.S. - Use the search function to locate the Intel problem thread.
  21. Toastman

    Toastman Super Moderator Staff Member Member

    Fattys - It's Victek's version (which I mod slightly from his source code, but only to add some labels to the QOS).
  22. ooglek

    ooglek LI Guru Member

    I've got a Linksys WRT54GSv4 running 1.25. I was running 1.23 solid for a while, but since the upgrade lately it has started rebooting seemingly randomly after a few days of uptime.

    I'm using Verizon FIOS 20mb down 5mb up service.

    Just happened again. I am logging to my desktop, so I don't lose the logs. I see some ssh brute force attacks, but not enough to cause concern (using key-based auth only). Just turned on brute force limiting to help mitigate that (Sweet!).

    How do I help troubleshoot the crash? Can Tomato save a core dump if I add JFFS2? Could it be a certain type of remote command/access? Somewhere there is something that is causing the router to reboot -- dunno if it is my provider, some remote party, or the code running on the device. I just know that 1.23 didn't reboot by itself, though 1.25 does. And I'm a guy who is also a geek so I wanna do what guys do -- fix it.
  23. Alucard

    Alucard Addicted to LI Member

    My WRTG54GL has now been up for 10 days with nary a reboot. Preliminary results suggest that the ND version of Tomato is better for me.

    I have one Intel wireless client, a 4965 chipset. I do live in an apartment complex so unassociated Intel clients might have caused problems?

    Thank you for the pointer to the search function, that's how I found this thread and the suggestion to try the ND version when wl0_corerev >= 9.
  24. ooglek

    ooglek LI Guru Member

    Linksys WRT54GSv4 Reboots in 1.25 Solved

    I have been up for more than 7 days on my Linksys WRT54GSv4 running 1.25 after random reboots that occurred between 20 hours and 3 days apart.

    June 19 13:29:28 was when my router last came up, and it looks like on June 20 at 9:36:08 I disabled NAT-PMP, a new feature that was added. Since I disabled it, I've been up for 7+ days without issue, which hadn't happened since I installed 1.25.

    I'm running 1.25 with NAT-PMP enabled on my Buffalo WHR-G54S, but it is running in Bridge mode, so I would assume NAT-PMP doesn't apply.

    I'm logging everything via syslog to my Mac Pro for this very reason. A few suspect lines in the log:
    Jun 17 17:34:50 miniupnpd[102]: HTTP listening on port 5000
    Jun 17 17
    :34:50 miniupnpd[102]: Listening for NAT-PMP traffic on port 5351
    Jun 17 17
    :34:50 miniupnpd[102]: chain upnp not found
    Jun 17 17
    :34:53 miniupnpd[102]: received signal 15good-bye
    Jun 17 17
    :34:53 miniupnpd[144]: HTTP listening on port 5000
    Jun 17 17
    :34:53 miniupnpd[144]: Listening for NAT-PMP traffic on port 5351
    Why would it start, then kill itself, then start again?
    Jun 18 11:02:01 miniupnpd[1385]: HTTP listening on port 5000
    Jun 18 11
    :02:01 miniupnpd[1385]: Listening for NAT-PMP traffic on port 5351
    Jun 18 11
    :02:10 miniupnpd[1385]: get_redirect_rule() : iptc_init() failed Invalid argument
    Jun 18 11
    :02:10 miniupnpd[1385]: addnatrule() : iptc_init() error Bad file descriptor
    Jun 18 11
    :02:10 miniupnpd[1385]: Failed to add NAT-PMP 8500 tcp-> 'NAT-PMP 66361'
    Jun 18 11:02:10 miniupnpd[1385]: get_redirect_rule() : iptc_init() failed Bad file descriptor
    (repeats 250times)
    Jun 18 11:02:11 miniupnpd[1385]: received signal 15good-bye
    Jun 18 11
    :02:11 miniupnpd[1385]: get_redirect_rule() : iptc_init() failed Bad file descriptor
    Jun 18 11
    :02:11 miniupnpd[1385]: addnatrule() : iptc_init() error Bad file descriptor
    Jun 18 11
    :02:11 miniupnpd[1385]: Failed to add NAT-PMP 8500 tcp-> 'NAT-PMP 66362'
    Jun 18 11:02:11 miniupnpd[1385]: get_redirect_rule_by_index() : iptc_init() failed Bad file descriptor
    Jun 18 11
    :02:11 miniupnpd[1473]: HTTP listening on port 5000
    Jun 18 11
    :02:11 miniupnpd[1473]: Listening for NAT-PMP traffic on port 5351
    And just cool:

    Jun 16 08:53:01 ntpc[2290]: Received a kiss of death packet from 0.us.pool.ntp.org (


Share This Page