Gateway+AP ... radio on AP stops even though GUI says it is on

Discussion in 'Tomato Firmware' started by darksky, Aug 4, 2013.

  1. darksky

    darksky Addicted to LI Member

    I have two TomatoUSB routers, one gateway and one AP. Their configuration is listed below. The problem I am experiencing is that the radio on the AP stops after several days of uptime despite the GUI indicating that it is indeed on. I know it stops because none of my devices are able to see the SSID nor connect to it. Rebooting the AP solves the problem. I see nothing in the logs on the AP to indicate a problem. Perhaps I have it misconfigured?

    Gateway ( = original router directly connected to cable modem.
    AP ( = new router connected via long cat5e to gateway.

    Gateway runs Tomato Firmware v1.28.7501.3 MIPSR2Toastman-RT K26 USB Ext
    AP runs Tomato Firmware v1.28.7502.8 MIPSR2Toastman-RT K26 USB Ext

    On Gateway:
    WAN/Internet: Type = DHCP
    LAN: IP Address =

    Wireless (2.4 GHz):
    Wireless mode = Access Point
    Channel = 1
    Wireless Network Mode = N Only
    Security = WPA2 Personal
    Encryption = AES

    Miscellaneous: Mode = Gateway

    On AP:
    WAN/Internet: Type = Disabled
    IP Address =
    Subnet Mask =
    Default Gateway =
    Static DNS =

    IP Address =
    Netmask =
    DHCP = Disabled
    Static DNS=

    Wireless (2.4 GHz):
    Wireless mode = Access Point
    Channel = 11
    Wireless enabled and using the same SSID and auth mode and password as on the gateway.

    Miscellaneous: Mode = Router
    Last edited: Aug 10, 2013
  2. Marcel Tunks

    Marcel Tunks Networkin' Nut Member

    Your settings are fine. Could be wireless driver issue. What hardware are you using? Have you tried older Toastman firmware on the AP, before the latest driver update?
  3. darksky

    darksky Addicted to LI Member

    Gateway is a Neargear WNR3500L.
    AP is an Asus RT-N16.

    Both have been running flawlessly when used as stand-alone gateways themselves... it is only when I connected the N16 to the WNR3500L as configured above that this issue began to happen.
  4. darksky

    darksky Addicted to LI Member

    Well, I have disabled my access restriction (basically off midnight - 7 AM) and haven't seen the problem appear going on 3 days now. Perhaps there is a bug with it? Toastman? It's running Tomato Firmware v1.28.7502.8 MIPSR2Toastman-RT K26 USB Ext if that helps.
  5. Toastman

    Toastman Super Moderator Staff Member Member

    I haven't seen this problem on any of my installations. It may be something peculiar to the 3500L or your particular setup, althought everything you posted looks fine. I never had any problem with access restriction here either.
  6. darksky

    darksky Addicted to LI Member

    OK, just wanted you to be aware of it. 6-1/2 days of uptime with access control disabled and no issues. Again:

    Gateway (disabled radio) <---------------cat5e-----------------> AP

  7. koitsu

    koitsu Network Guru Member

    M gut feeling is that there's no way the Access Restrictions feature could cause any kind of wireless-level issue (and my feeling/opinion is still of that nature. The wireless driver/layer can crap out on its own while other things continue to work just fine -- here's an example of such on FreeBSD which I discussed/reported, where the driver maintainer (who works at Atheros) responded with details showing exactly what I've said).

    Basically it's possible for "wireless stuff" -- either the firmware (code that runs on the chip itself) or the driver (code that interfaces with the chip or firmware that runs on the router CPU) -- to get wedged in such a way that the only way to recover from it is to reboot (thus reinitialising the driver, radio, etc.). As I've shown above, even other chipsets (Atheros vs. Broadcom) can experience this.

    It's very likely that the wireless driver used by Tomato -- which is closed-source/a binary blob -- does not emit any indication of its problems in this type of scenario. Thus the only thing the user knows is "the wireless has stopped working". I've seen this kind of report more times than I can count; "problem goes away when I reboot the router".

    All that said:

    There is only one wireless-related "tie-in" to the Access Restrictions stuff, and the logic there has to do with the rrules_radio NVRAM variable but more importantly may run the CLI command "radio on" or "radio off" (which either, via software, enables wireless functionality or disables it, respectively). I have not looked at what the foreach_wif() or get_radio() routines actually do (though I can speculate on the former). That's it. I don't see how else Access Restrictions could cause any kind of issue.
  8. darksky

    darksky Addicted to LI Member

    I don't have a mechanistic link either. I can only report the behavior I am observing. I will leave AC disabled for a few weeks and if I do not see the behavior again, I will re-enable it and see. If the wireless "disappears" when AC is enabled, we can conclude that it is somehow, directly or indirectly to blame.
  9. Monk E. Boy

    Monk E. Boy Network Guru Member

    Are both routers on the same channel? Is Access Control disabling wireless on one or both routers? Are both routers scheduled to bring up/down the wireless interface at the same time?

    I have seen "issues" when bringing the wireless interface up/down on a daily basis (weak signal, router coming and going from wireless visibility, etc.), sometimes it doesn't come back cleanly.

    Instead of rebooting the router with the problem you can try changing the wireless channel, this should quit/reload the wireless driver (I think,... or at least it always brings it back to full strength).
  10. darksky

    darksky Addicted to LI Member

    No, it is disabled 24/7 on the gateway.
    No, since the gateway's radio is off.

    I seem to recall trying what you proposed: changing the channel on the AP when the wireless was not detectable by devices but that had no effect. Even disabling/enabling it again in the GUI had no effect.
  11. Monk E. Boy

    Monk E. Boy Network Guru Member

    Ah, I thought you were familiar. So wireless is disabled on the router and enabled on the AP. What does your access control rule(or rules) on the router do?

    I honestly can't think of a way for anything except enabling/disabling the wireless radio (preferably both, and scheduled at the same time) to cause one of the radios to shut down. You could try switching to one of the RT-N builds on the RT-N16, it can accept both RT and RT-N builds, and the wireless drivers are (very) different.

    Maybe you've got a neighbor who's sending malicious packets at your router overnight to try and bring the internet connection back to life after you've shut it down. But since the connection is managed on a different router their maliciousness does nothing except, eventually, cause the wireless interface to completely die. Complete and probably baseless conjecture, but I always suspect the 9yo kid next door, mainly because I've sniffed neighbors trying to do crazy stuff like this before (because if he tried to do this to his parents router he'd get in trouble). I would hope its harder to do now with WPA2/AES, back in WEP days it was the wild west...
  12. darksky

    darksky Addicted to LI Member

    Nothing; radio is totally disabled as are AC.

    Ha, unlikely given the distance to the nearest neighbor's house.
  13. Monk E. Boy

    Monk E. Boy Network Guru Member

    Currently your router has access controls disabled. What did you have configured under access controls when they were enabled?
  14. darksky

    darksky Addicted to LI Member

    @MEB -
  15. Monk E. Boy

    Monk E. Boy Network Guru Member

    So, in other words, your access control rules were disabling wireless and enabling wireless on your router (but not AP) when you had the problem? Why did you say "no" to "Is Access Control disabling wireless on one or both routers" then? Surely you couldn't be confused about the topic at hand here, which is the problem you were having and the configuration in use at the time, not the configuration you're using right now w/o the problem occurring. By responding with the current config when queried about the problematic config you've made this far a more confusing discussion.

    I would try using an RT-N build on the RT-N16, in the hope that the different wireless driver can handle whatever the 3500L is blasting out when bringing up its wireless interface.
  16. darksky

    darksky Addicted to LI Member

    The Gateway has disabled wireless and disabled AR as you can see in the screenshot above.
    The AP _had_ AR which switched it off from midnight - 7 AM everyday but that seemed to cause the issue so I disabled it and it has been fine.
  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