Please help with your experience of "random" reboots

Discussion in 'Tomato Firmware' started by Toastman, Dec 13, 2010.

  1. Toastman

    Toastman Super Moderator Staff Member Member

    I've been bugged for some time by apparently random reboots, which have been very frustrating. For standalone users this isn't at all important, though it may be irritating. But in a large apartment block, it causes a lot of problems with residents who lose their connections, maybe in the middle of something they consider important.

    Many months ago, this was commonplace, and it was tracked down to the Intel wireless cards causing the old Broadcom driver to throw a wobbly and somehow or other this caused the router to reboot. Soon the old driver was replaced by the so-called "ND" drivers, most of us moved over to using them, and the problem ceased.

    Or did it?

    My routers do still reboot. I've been keeping massive databases of who was using the network at the times they crashed, and trying to make sense of it. It appears that connection storms, often due to viruses on resident's PC's, are responsible for some, but it did seem a bit excessive. I have not really proven that these reboots were caused by users traffic, but my thinking was along those lines. Don't forget I have hundreds of users and they are **always** doing weird things. But several days ago, I made a discovery.

    In the course of testing out some new compiles, I wanted to keep the logs clear of DHCP messages, so I gave everyone the longest lease I could enter, 10080 minutes. Usually I issue a 1 day lease, so that users who have not paid their bills don't get free access for more than a few hours. Afterwards, I forgot to change the DHCP lease back. After a day or two, all the residents had a pretty long lease and few came on to renew - and the router has not rebooted since !

    Next, I set it to issue a 30 minute lease, and suffered reboots quite regularly. It does seem to be related and is repeatable.

    I'm asking if forum readers who have suffered this problem and are just living with it, can try giving the long lease and see if they also get an improvement. If they do, and it's not just something I'm doing, we may have something we can track down. There may still be an issue with certain wireless cards, or the DHCP renewal, or something related. So any observations on what wireless cards tyou have that may cause a reboot or be involved would also be useful.

    Thanks for your help!

  2. mstombs

    mstombs Network Guru Member

    Is it significant that dnsmasq is the binary that does both lan dhcp and dns? Connection storms that try to open connections to named connections would be making lots of simultaneous dns lookup requests. Also on a wan connectivity glitch lots of clients (XP and Wii for example) can be observed to do "dhcp renew" presumably to try to restart the connection?
  3. Dashiell

    Dashiell Network Guru Member

    Thank you, Toastman! I was starting to believe it was just me...

    I've only experienced this on RT-N16s. Two of them.

    I experienced it first with Teddy's Build 48. I originally attributed it to a power supply problem with the RT-N16s, and had it replaced. I have 4 of these models running now, but since moving to mikrotik routing in half the locations I am using 2 of them as wireless access points.

    2 of them are running Teddy's Build 54. The other two are running Victek's 1.28.8653, which are only being used as wireless N access points.

    Here's what I've experienced:

    The original Victek release (his first for RT-N16s) never seemed to reboot on its own. The latest build does.

    Teddy's builds seem to be a bit more random in the rebooting.

    I see this happen a lot more in the EXT builds, less in the VPN builds. Still there, but less.

    One of my RT-N16s will rarely stay up past 3 days without a reboot. This is the 8653 version.

    In short, all four units reboot randomly. Whether under network load (the two I'm using for routing) or not (the two I'm using for APs), they all do it. Before anyone asks, I used the Asus firmware utility to flash and did a thorough NVRAM erase before implementing any of these routers. Some I even erased a couple of times.

    I don't have the expertise to try and crack what is happening here, but I'm pretty sure that it is not a power supply or overheating issue. My gut tells me it has something to do with dnsmasq...
  4. Toastman

    Toastman Super Moderator Staff Member Member

    Interesting. I don't waste RT's on being just AP's, because N access points wouldn't work here - I have up to 30 on some buildings. I use WRT54GL's as B/G only, which is plenty fast enough for individual users. So all of my (expensive) RT's are routers. In most of my blocks, there are two routers and two ADSL lines, but the allocation of IP and the choice of which router as gateway is done by DHCP on only one. This one always reboots - but of course that's the one I notice most. Generally the one which only acts as gateway, does not reboot. If you can try the lease thing, it would be very useful. Especially if you set a 30 minute lease, this should provoke reboots quite quickly.

    By the way, when it does reboot in this manner, there is nothing at all in any logs nor any warning at all. It's just as if you had pulled out the plug.

    The original Victek RT release was actually based on my build, I believe, from the git code I uploaded. Did it have my QOS code in it? That would be a clue. So it shouldn't have been any different. However, I'm not sure exactly what version it was based on now. But I think it also suffered reboots. But now maybe we have something to test. I completely agree with you, there are no overheating issues with the RT-N16 and the power supplies are perfectly adequate.

    Would your AP's be using dnsmasq?
  5. Toastman

    Toastman Super Moderator Staff Member Member

    mstombs, sorry didn't see your post in between...

    Yes, it could be significant. But I don't think it is DNS. I can generate thousand of DNS lookups and the routers survive. But it may be new DHCP issue or renewal of older lease. Or it may be that this coincides with a user turning on his trusty old laptop and connecting - when of course it could also be a wireless problem, similar to whatever it was that we experienced with the old non-ND driver. In which case I'd be willing to bet my right arm that it's Intel's poxy wireless cards again. Soon I will start reviewing all my stored logs to see if any particular residents connect/renew right before it happens, but I didn't see anything before that was obvious.

    Any thoughts or observations anyone has would be very helpful. But the routers I have set to long leases have all been up now for three days. Normally I was getting them reboot 1 or two times a day. It would be worse at weekends when more people log on, so the fact that survived this weekend is very significant.

    Oh, a question. I am wondering, why not let one of the AP's earn it's keep, and be the main DNS server. Then even if we can't fix the problem, it wouldn't really matter if an AP rebooted. It would be a sensible thing to do anyway. But it would need to issue an IP that is not it's own as the primary gateway, using the GUI to enter everyone's details - static IP etc. The DHCP extras box I normally use to split half the users to a second gateway by MAC address mask, so all my main entries need to be handled by the GUI. Maybe a box to enter gateway instead of assuming it is the router itself, but with it's own IP as default. If you could help me code that in, I'd be a very happy bunny :)
  6. Dashiell

    Dashiell Network Guru Member

    My APs are in router mode, nothing plugged into the wan port. Wan disabled on Basic page. Yet dnsmasq does seem to restart itself every so often.

    PS - Yes, the original Vic build did have your QOS tags on it.
  7. Toastman

    Toastman Super Moderator Staff Member Member

    OK, you might try turning off DNSmasq in a startup script and see if it helps. Thanks for the reports, speak later!


    Just remembered a site which is still using WL500gP v2 as router. I hardly ever get a call from it. It's running my 7616 Beta which was based on TomatoUSB and built on September 19, with Linux kernel and Broadcom Wireless Driver, dnsmasq version 2.55 cachesize 150. The wireless isn't active though, it is just a router.

    Despite not being on a UPS it has been up 27 days in a fairly busy block with 75 users. It issues lease for 1 day.
  8. Dashiell

    Dashiell Network Guru Member

    Will do! I will run "killall dnsmasq" in ssh now, and add it to startup script as well. We'll see what happens...
  9. ~nephelim~

    ~nephelim~ LI Guru Member

    Currently support for scripts is disabled but -6 --dhcp-script=<path> might provide some way to carry diagnostic on lease updates.

    Though I don't really know what could be made from them, there are additional info in the proc folder

    cd /proc/$(pidof dnsmasq)
    for i in $(ls) ; do
    if [ "$i" != "exe" ] && [ "$i" != "cwd" ] &&  [ "$i" != "root" ] && [ "$i" != "mem" ] &&  [ "$i" != "fd" ]; then 
    logger  "$i: $(cat $i)"
    echo  "$i: $(cat $i)"
    And probably more specific commands might be included as more clues will be gathered.

    I don't know if this will actually help but since the events are related to leases it looked like this feature could prove an useful tool.
  10. Toastman

    Toastman Super Moderator Staff Member Member

    Looks useful, perhaps we can do this later, if my theory holds up.
  11. teddy_bear

    teddy_bear Network Guru Member

    Very interesting observations about dnsmasq!
    It may help if somebody with this problem can obtain a serial console crash dump...
    Well, there were 2 possibly related changes around that build - dnsmasq has been updated from version 2.52 to the latest version 2.55 in build 47, and in build 48 I turned on DNS rebind protection in dnsmasq by default...
    These 2 should be easy to test - but before we go there can someone verify that the old build 46 really doesn't have this issue?
  12. mstombs

    mstombs Network Guru Member

    The minimum lease time you can put in web gui is 1 minute, but dnsmasq then logs it has used 2 minutes. I run my adsl modem with a 30 second lease (simple renew from router on WAN every 15 seconds) without problem, it shouldn't be a big overhead!

    dnsmasq forks to handle dns requests, it clearly doesn't have a timeout for valid data after connection made so you can get 20 copies :-

      411 nobody    1056 S    dnsmasq
      715 nobody    1120 S    dnsmasq
      716 nobody    1120 S    dnsmasq
      717 nobody    1120 S    dnsmasq
      718 nobody    1120 S    dnsmasq
      719 nobody    1120 S    dnsmasq
      720 nobody    1120 S    dnsmasq
      721 nobody    1120 S    dnsmasq
      722 nobody    1120 S    dnsmasq
      723 nobody    1120 S    dnsmasq
      724 nobody    1120 S    dnsmasq
      725 nobody    1120 S    dnsmasq
      726 nobody    1120 S    dnsmasq
      727 nobody    1120 S    dnsmasq
      728 nobody    1120 S    dnsmasq
      729 nobody    1120 S    dnsmasq
      730 nobody    1120 S    dnsmasq
      731 nobody    1120 S    dnsmasq
      732 nobody    1120 S    dnsmasq
      733 nobody    1120 S    dnsmasq
      734 nobody    1120 S    dnsmasq
      737 root      1244 R    ps
    Each with associated connection
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    tcp        0      0     ESTABLISHED
    and these can hang around for a long time, but don't bring down the router, only seems to be 20 per client and this only takes an extra 1.5MB ram. They do get cleaned up eventually, but I don't see why not much quicker. I don't know how to do the same for udp ports...
  13. Toastman

    Toastman Super Moderator Staff Member Member

    I can run the variations on this with the earlier releases, with the network known to have these problems. I'll report back if I find any useful results. My only problem being the one of annoying the residents too much. However if we get results it may be worth some hassle on my part. I believe I tried turning off rebind already, but I will check it. T/B - I have serial console for RT - but not sure how to use it to obtain the result you need. I'm assuming it won't have anything useful after reboot, or do you mean try to catch it right when it reboots, and log the output? Please explain how, and I'll try to get what you need.
  14. teddy_bear

    teddy_bear Network Guru Member

    If you run PuTTY with serial connection, you can configure it to log the session output to the file. Then you don't need to catch when the reboot happens ;)...
  15. Toastman

    Toastman Super Moderator Staff Member Member

    OK, I will try later to bring the router up here, attach serial, connect to modem downstairs in switch room via the CAT5 cabling. It does get a bit complicated, it's in another building and about 150m away. Do I need to do anything else, issue any command, or just plug in cable boot router, log to file, and wait ?

    mstombs - never mind, I see that just dhcp-option = option:router, in the dhcp options box would allow me to issue my choice of primary gateway from dnsmasq running on an AP. It didn't work when I tried it before because of a typo. An extra box in the GUI would be a nice touch though.
  16. Toastman

    Toastman Super Moderator Staff Member Member

    Well, this is great. Set to a 2 minute lease, been running ever since last message with average of 25 or so people online and still no reboot after thousands of renewals. I don't know what is going on today. Damn!

    Anyone else tried it yet?
  17. Dashiell

    Dashiell Network Guru Member

    Running 1 day, 19 hours with dnsmasq inactive on an RT-N16 used solely as a WAP.

    Running Tomato RAF 1.28.8653
  18. TexasFlood

    TexasFlood Network Guru Member

    My lease time on the RT-N16 is 60 mins, uptime 5 days, 18:19:08 & last reboot was my own doing but I can't recall why I did it. Have not noticed spontaneous reboots. Running Teddy Bear "Tomato Firmware v1.28.9052 MIPSR2-beta23 K26 vpn3.6".
  19. Toastman

    Toastman Super Moderator Staff Member Member

    Thanks T/Flood!

    I have it running now with serial console to logfile so I hope will get some useful dumps. I just missed one problem this morning, one room (identified) sent out thousands of SMTP to port 25 and this killed the router so fast it would reboot and immediately die again. I just caught the "details" page in time - it listed about a hundred odd connections before it died. I have not banned the user so that I can get some logs if and when he does it again.

    I have had no reboots from DHCP renewal, doesn't seem to be that, at least, not at the moment. The problem here is of course I have no way to know if there is a problem, but the guy causing it has gone on holiday for a week.

    These new additions to the "details" pages from Wes Campaigne make diagnosis a lot easier.
  20. TexasFlood

    TexasFlood Network Guru Member

    Mass mailing email worm?
  21. Toastman

    Toastman Super Moderator Staff Member Member

    Yes, guess so. I have a script that is supposed to limit the number of simultaneous connections to port 25. It does work under normal times, but it looks like it actually does nothing for a real flood.

    mstombs - yes, when a flood like this begins, of course there are also thousands of DNS lookups too. If dnsmasq can spawn 20 copies of one lookup then this would compound the problem, I remember this business was raised some time ago by planiwa. I wonder if there is a deliberate limit of 20?
  22. Toastman

    Toastman Super Moderator Staff Member Member

    Running all day and I see no problem with DHCP.

    However, the SMTP worm is interesting. From mid-morning I have had serial console attached. Nothing has been logged since the last boot-up. However, in early evening the router suddenly rebooted, and did this several times in a row. Nothing on serial console except the new boot details.

    Thinking about this, I have been going back through all of my logs for months and looking for clues around the time of these reboots. One thing that is often there, just before a reboot, is a message "dnsmasq[431]: nameserver refused to do a recursive query" that may be related, but I don't think this is the cause.

    But - I see evidence that on the occasions I have NOT been running the router with a firewall script to limit the number of connections, the router hasn't been rebooting. On the occasions when routers have been running these scripts, I seem to have had reboots. It could be that the overhead of running these scripts is what kills the router. To test this, this evening I did a little experiment. I have a remote site with two RT-N16 routers, so I placed the rules on one, and not on the other. Already I see that the one with the rules has rebooted. Not conclusive yet, but ...

    These are the rules in question, they've been around for some time, and they do limit as required under normal circumstances. They were confirmed some time ago by u3gyxap. But for a real attack, they seem to do nothing.

    # Limit outgoing TCP connections per user
    iptables -I FORWARD -p tcp --syn -m iprange --src-range -m connlimit --connlimit-above 150 -j DROP

    # Limit all *other* outgoing connections per user
    iptables -I FORWARD -m iprange --src-range -p ! tcp -m connlimit --connlimit-above 20 -j DROP

    # Limit outgoing SMTP simultaneous connections
    iptables -I FORWARD -p tcp --dport 25 -m connlimit --connlimit-above 5 -j DROP

    I suspect this is the real problem. I'm waiting for the guy with the worm to come on again to try again for some logs. After that I will remove those rules and try yet again.
  23. mstombs

    mstombs Network Guru Member

    I only tested TCP connections to DNS TCP port 53, because I could! These are supposed to be rare, most dns and dhcp requests are "connectionless" UDP.

    Pretty sure it was dnsmasq that limited the spawn to 20 children, and this matches the entries in config.h

  24. Toastman

    Toastman Super Moderator Staff Member Member

    Router has rebooted again during the night, again, nothing in the serial output. Repeated several times, nothing.

    Trying now with all scripts removed, and the guy who had the mail virus is logged in but no sign of any reboot (but also no proof he still has the problem - he may have run a virus check by now).
  25. Toastman

    Toastman Super Moderator Staff Member Member

    Just to bring this thread to a conclusion. The lease renewal was a red herring. I believe what has caused these reboots are the firewall scripts designed to prevent that very thing from happening. Exactly why, I do not know. The router appears to instantly run out of resources and reboots without any logging, serial output, and no warning whatsoever. In fact, there's really no way to know if it is a connection storm or not. I just happened one day to catch a mail virus, with some output (probably not a good virus LOL). But normally, there's no warning and no trail of evidence.

    "Planiwa" wrote some wonderful scripts to trace connection storms about a year ago, they can be found on this forum. But they seem to no longer work. Possibly something has changed in TomatoUSB that was needed.

    Anyway, I found that removing all firewall scripts and then bringing the number of connections permitted in conntrack/netfilter down to around 2000 is a far better solution. The router hasn't rebooted and nobody has lost connectivity. In the event of a connection storm it appears to drop packets as it should and recovers gracefully afterwards.

    Would anyone who understands the firewall care to investigate ?
  26. Dashiell

    Dashiell Network Guru Member

    Wait one second, Toastman. :)

    This does not explain it for those in my situation. I have no scripts running on any of my four RT-N16s, and was still getting random reboots.

    However, after I disabled dnsmasq (on the two that are used as waps) there have been no reboots for the last three days.
  27. mstombs

    mstombs Network Guru Member

    I wonder if just dropping the connection actually encourages the malware to try again and cause the connection storm. If this is true it should be possible to reproduce in a 'lab' and track down the root cause in the kernel, but its all pretty mature code and will usually fail with a "Rusty's brain broke" or similar obscure message. I guess the Broadcom binary Ethernet drivers could a difficult area to diagnose.
  28. Toastman

    Toastman Super Moderator Staff Member Member

    Dashiell's problem may be a different thing, of course. Dnsmasq is obviously doing something odd on his AP's. Also, as mstombs points out,we are not testing under lab conditions at all. The problem that I had when I initially thought it was dnsmasq may have coincidentally disappeared after I began testing - the resident concerned may have gone on holiday, ran a virus checker, reinstalled his OS, whatever. We don't know. Of the problem I have left, I know almost nothing, except that one guy had a mass mailer program which I saw briefly in action on one occasion. There may at any one time be several people with viruses of different kinds. In this block, I am able to see a little of what goes on, in my other blocks, this usually happens without my knowing how often or why. So let's face it, all I know is that every time I remove the "firewall" rules, the router becomes stable.

    Of course, there are also a few firewall scripts running by default, these may also be suspect, not that they do much. It is possible also that the firewall may have been broken by something in the not too distant past. Or this may always have happened. Without a test lab or something approximating such, it's damned near impossible to test this.

    The feeling it leaves me with, is that there is something not quite right here, iptables should be able to drop connections with a firewall rule if conntrack can do the same thing with no problem. It also seems to indicate there's not much point in having a firewall.

    I've spent so much time on this, now and in the past, and although Tomato is a lot more stable than it was, this just shouldn't be happening!
  29. Toastman

    Toastman Super Moderator Staff Member Member


    Refer to this post and those following

    Following suggestions from phuque99 in the QOS thread, the existing limit rules were switched to the prerouting chain and run for about a week. The rebooting issue was pretty much gone. Returning the rules to the forward chain made the reboots return again. So it looks pretty conclusive - the connection limit rules in the normal firewall chains INPUT and FORWARD seem to invoke some mechanism which rebooted the router almost instantly in the event of a "real" DOS attack or connection storm.

    The new rules in the firewall script box were:

    iptables -t nat -I PREROUTING -p tcp --syn -m iprange --src-range -m connlimit --connlimit-above 150 -j DROP
    iptables -t nat -I PREROUTING -p ! tcp -m iprange --src-range -m connlimit --connlimit-above 100 -j DROP
    iptables -t nat -I PREROUTING -p tcp --dport 25 -m connlimit --connlimit-above 5 -j DROP

    Now I am able to see much more of what is happening with the new connections and rates info from Wes Campaigne's mods, it is becoming clear that a lot of these problems are from mobile phones belonging to residents or their guests.
  30. Gewehr98

    Gewehr98 LI Guru Member

    Toastman, I don't know if you've gathered enough data points...

    But my WRT54G-TM has been randomly rebooting now for the last few months.

    The router is running straight Tomato v1.27, which is how I had it configured by the person who sold it to me on eBay.

    I have not loaded earlier or later versions of Tomato yet, nor have I loaded alternatives like Victek's until I could do a little more investigating both at home and here at

    One thing I did notice is that even after the random router reboots, the processor overclocking stayed at the previous 240 Mhz (overclocked) setting, which I had figured would automatically reset to the as-delivered default speed of the WRT54G-TM. That's odd.

    I don't really have any clues as to what's causing this Tomato 1.27 reboot problem, but I have added a BlackBerry to the home network, and enabled WiFi to augment the "iffy" AT&T signal reception in my neck of the Wisconsin woods. I see in the system logs that the BlackBerry is constantly hitting the router about every 2.5 hours with a DHCP DISCOVER/OFFER/REQUEST/ACK string. This hardly seems like something that would overwhelm the WRT54G-TM and Tomato firmware, and the logs are sometimes the first place I go to see if there are hiccups in the system. I could turn off logging to see if the random reboots go away, but there are also a lot of settings I could potentially toggle in search of a remedy.

    Hopefully, this particular example of a rebooting router will help narrow down the solution... :frown:
  31. Toastman

    Toastman Super Moderator Staff Member Member

    If it has tomato 1.27 (straight) there is a probability that it is running the old wireless driver and not the "ND" driver. There were old issues with some wireless cards causing the router to reboot, which were cured by the use of the ND driver. While the troublesome wireless cards were mostly Intel, I did see issues with other cards, such as D-Link on some occasions. It might well be that the Blackberry is the cause. Check to see what wireless driver you are using and change to the ND driver if you're not already using it. You may be unnecessarily putting up with something that was cured a couple of years ago.

    On another note, I am now seeing a lot of weird stuff coming out of mobile phones hitting my network. Residents always try to input the Network Key on any new phone they purchase to see if they can access the internet for free. Some of these phones do send out an extraordinary amount of stuff to several hundred destinations. Especially the suspicious copy ones with MADE IN CHINA on them .... go figure.
  32. EntityPacket

    EntityPacket LI Guru Member

    I have a reboot problem as well. Forgive my ignorance (read the original post and skimmed the replies) I'm not familiar with the flavors of Tomato being mentioned and kinda wonder what hardware is being used.

    My setup is a WRT54GL with the 1.25 SgtPepper build. A little background on my reboot mystery. I think it's been going on for a while (ever since I got into Macs) because I've had a problem where my Mac mini's lose network connectivity for no apparent reason. I never investigated much and solved the problem by disabling and enabling the NIC or rebooting the Macs usually. It doesn't happen often, maybe once every two weeks. I have a two mini's one running mac server the other just snow leopard. It doesn't seem to matter if my mini is configure for DHCP or static (more testing required on that). Today the issue occurred again and when I checked the Linksys I noticed the up time was only a few hours. I didn't lose power, so it must have rebooted. I had the same network connectivity issue, this time, on the mini server. I currently have both mini's configured with static addresses (as well as static DHCP on the router - just in case I want to use DHCP). When the router rebooted, one of the mini's was able to ping the router, the mini server was not. Usually changing from static to DHCP fixes the issue, then I usually set it back to static. This time however, it didn't do the trick. I rebooted the router as well as shutdown the mac server. Powered up the mac server once the router was reloaded, still nothing. Checking the log on the router and enabled DHCP on the mini server, I see the router getting a discover and sending an offer. Doing a tcpdump on the mini server I only see the discover going out. I find this very strange and even if there is a problem with DHCP why would static addressing have a problem? I've always chalked it up to maybe Apple just doesn't work well with Linksys, until I noticed my router was randomly rebooting. Eventually flip flopping between static and DHCP I am able to ping the router from the server and everything is fine again. So I went to the store and just came home and refreshed my router GUI and saw my uptime as 1 minute 20 seconds. My router rebooted again just as I was pulling in my driveway, but this time both my macs (using static addressing) did not lose network connectivity. So it's hit and miss. Any suggestions on how I can narrow down the reboot issue? I can also vouch that I do not have this problem with the Macs when I use my time capsule as my router/dhcp server.

    Also just got me another Linksys GL as a test router to test other firmware on. Is there a more VPN friendly solution?
  33. Gewehr98

    Gewehr98 LI Guru Member


    I ended up downloading the straight version of Tomato 1.28, and also disabling the BlackBerry's WiFi connection. The logs show far fewer DHCP transactions, and my random reboots have been absent since those actions. I'm keeping my fingers crossed that I've found the culprit. The BlackBerry will just have to get signal from AT&T's tower, sans my WiFi network. :wink:
  34. EntityPacket

    EntityPacket LI Guru Member

    I haven't had another reboot yet, still waiting for the next one..
  35. bangkokiscool

    bangkokiscool Addicted to LI Member

    A week ago I finally upgraded from the WRT54g-TM to the Asus RT-n16. The WRT was running Victek, and the N-16 is running tomatousb, VPN version. The WRT was losing connectivity periodically and I thought I was looking at hardware failure. Almost immediately the N-16 began experiencing random reboots. The router is hooked up to three AP's and in frustration I even began to swap AP's. Then I found this thread. Thanks to everyone who contributed, esp. Toastman, it sounds like we had exactly the same problem. I swapped out the firewall scripts and voila, no reboots in the last 24 hours.

    Just to confirm what is happening though -- is the consensus that the reboots were caused by a client computer and a virus or spam traffic, or a connection storm, and the old firewall script was unable to handle it? I have another setup running a WRT with the old script. Toastman, did you swap all your scripts to prerouting or only on the n-16's?
  36. Toastman

    Toastman Super Moderator Staff Member Member

    I still have a few WRT54GL's and WL500gP v2's in use at some remote sites. I did change the scripts but got no feedback - however the routers have stayed up a long time. I'd guess the situation with the GL is no different.

    As to exactly what mechanism causes the router to reboot, I am personally quite sure it is connection storms from various sources such as infected PC's. It's possible that a PC running a P2P application might be able to do it, but I rather doubt it. However, I wish I knew the exact reason the scripts running in the normally-used firewall chains cause the router grief. It does rather cast the idea of running scripts in the firewall script box in a rather bad light, because the majority of tutorials on firewalls shows them being written into the FORWARD chain.

    After this discovery, I am very happy to say that it is very rare indeed to see a router fail these days.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice