Access Restriction quick question

Discussion in 'Tomato Firmware' started by JTD121, Aug 26, 2014.

  1. JTD121

    JTD121 Addicted to LI Member

    So I have a small network, with a single device that is purposefully fubar'd. Only used 802.11B, and only allow 31-character WEP.

    Needless to say, I didn't want this thing on my main network, nor let roam free, or crackable as much as I could help it.

    So, it's got it's AP, and I have set it to shut off WiFi outside of normal usage hours for the device. Is this set correctly? So everyday, the WiFi is only on from 4:30AM to 8AM. It seems to either have stopped working, or I have it set wrong?


    WRT54G running Tomato Firmware v1.28.7635 Toastman-IPT-ND ND Tiny if that helps any.
    Last edited: Aug 26, 2014
  2. Campigenus

    Campigenus Networkin' Nut Member

    Start at 16:30, end at 8:00.
  3. JTD121

    JTD121 Addicted to LI Member

    While I like how you're thinking, I only want the WiFi active for 4½ hours every day. Kind of sucks the only real default rules are 'Off Altogether' or 'WiFi Off'....Unless I'm missing some advanced rule-making functions in Tomato's Access Restriction area?
  4. koitsu

    koitsu Network Guru Member

    This whole thread confuses me -- not what you want to accomplish, but all the numbers/times being discussed. Everything shown so far has been wrong.

    1. The initial post shows a time window of 0800 (8:00am) to 0430 (4:30am). Because of how Access Restrictions works, that almost certainly results in WiFi being shut off at 0800 (8:00am) and being re-enabled at 0430 (4:30am), so in effect WiFi would only be usable between the hours of 0431 and 0759. Please note that my 12-hour times are correct -- the OP clearly said 4:30AM to 8AM. Simple math says 0800-0430 = 3.5 hours.

    2. The follow-up post from @Campigenus says to set the start time to 1630 (4:30pm) and end time at 0800 (8:00am). That would disable wireless for 15.5 hours, and it would be available from 0801 (8:01am) to 1629 (4:29pm).

    3. The follow-up post from the OP explicitly states he wants the WiFi usable for only a 4.5-hour period.

    So, respectfully, folks here need to figure out how to do math, or figure out what they want to accomplish. The initial post seems correct to me, aside from the fact that it only covers a 3.5 hour window.

    The problem with Access Restrictions is that it's very difficult to debug. The way it works is that there's a cronjob added to the system (specifically rcheck --cron) which runs every 15 minutes (specifically at xx:00, xx:15, xx:30, and xx:45). The cronjob under the hood examines a bunch of NVRAM variables, parsing out the Access Restrictions settings (they're encoded in a way that's hard to decode visually unless you're familiar with them), and then doing whatever they're set to do (ex. disable the radio, enable the radio). I've talked at length before about the syntax of these variables.

    I've discussed how possibly turning off the radios simply doesn't work on some models of hardware or firmwares in the past, or intermittently works. This has come up before (read every post please, you'll see Toastman's explanation):

    A workaround would be to change from "Disable Wireless" to "Normal Access Restriction" and choose "Block all Internet access". This doesn't have the same effect as shutting off the radio though -- all that will do is block outbound Internet access if someone is able to connect to the router to begin with. My guess is that because you're using WEP128 you really do want the entire radio shut off to minimise any chance of someone capturing wireless packets during longer windows and eventually breaking your WEP key. (Warning: you're free to disable the radio as a way to minimise that, but WEP breakage does not require linear/uninterrupted access to work -- a person can get 15 minutes of traffic, then a few days later get another 15 minutes worth, etc. and eventually they can/will break it. So your methodology of minimising impact is understandable but doesn't solve the problem. Maybe you should rotate WEP128 keys on a daily basis? I bet that'd be annoying for whatever device you have that uses 802.11b though...)

    Alternately you could add your own cronjob that enables the radio at 0430 and disables the radio at 0800 (though again that's only 3.5 hours), using the radio off and radio on commands, but those are almost certainly susceptible to the same bug as described by Toastman. I'm not 100% certain, but I don't think you could use iptables to block traffic (even to anything on the local LAN/WLAN) because that's not how "LAN packets" work. But I bet you probably could use separate VLANs to accomplish this task (basically the cronjob would blackhole all traffic associated with VLAN X during certain hours, and allow all traffic associated with VLAN X during other hours), but VLAN setup on TomatoUSB is a pain in the butt, if you ask me.

    So if you want something that works? Try one of these. Yup you got it -- a device that literally drops all AC power to whatever's plugged into it for specific durations and re-enables it later. It's cheap and is absolutely guaranteed to work. And it's a physical device with an internal (probably manual) timer -- no firmware bugs involved.

    P.S. -- Newer Toastman firmwares, and probably Shibby and others, have changed the Access Restriction part of the GUI to use 24-hour time ("military time") exclusively. 12-hour time is so utterly ridiculous. So you might try upgrading to Toastman's firmware and see if your problem goes away. It might, but Toastman's explanation seems to indicate the bug is intermittent and nobody is sure how to debug it.

    P.P.S. -- Just a random question: let me guess, you have someone on your local network who has a handheld game console (ex. Nintendo DS) and thus requires 802.11b and WEP/WEP128? :)
    Last edited: Aug 26, 2014
    JTD121 likes this.
  5. JTD121

    JTD121 Addicted to LI Member

    Thanks for the correction, it is in fact, 3½ hours of operation! Tiredly posting, I tried not to do.

    Will try the upgrade at some point soon; been quite a while since I've even tried. It's almost a job in and of itself to download a Toastman build.

    And, no, it's not quite as awesome as that. This device is a 'connected scale' that measures weight, fat/water content, etc and syncs with your fitness tracker and such.
  6. Siff

    Siff Serious Server Member

    @JTD121: If you decide to go with an AC power on/off timer I would recommend you to get a digital one. The mechanical ones, although cheaper, usually are making clicking noises when they work and this can get irritating over time. I replaced all the mechanical ones I had (I'm using them for the Christmas lights) with digital ones for that exact reason.
    Last edited: Aug 26, 2014
  7. koitsu

    koitsu Network Guru Member

    If you want a specific firmware, give me the full filename and I can upload it onto my Dropbox account + give you a direct link to make your life easier. :)
    JTD121 likes this.
  8. JTD121

    JTD121 Addicted to LI Member

    Sweet, thanks for the (future) help! Time to go digging for filenames!

    If anything, I can see if Shibby or Victek have a semi-recent build for the WRT54G and just wipe NVRAM and begin anew!
  9. koitsu

    koitsu Network Guru Member

    You need to disclose what exact WRT54G revision/version (of router) you're using (there are several versions; see the underside of the router for what rev). I hate referring to DD-WRT's site, but:

    Also be aware that builds for that model are not generally... how do I put this... given a lot of attention in the past 6-9 months. The flash space is simply too small/limited for all the changes and stuff people are wanting/etc.. So there may not be a newer build for you that fits within the small flash space. We'll have to see.
    JTD121 likes this.
  10. JTD121

    JTD121 Addicted to LI Member

    No, I know these older routers have fallen by the wayside in the update department. But since I upgraded to a 66U, and this was now an 'extra' router, I figured why not use it for this? :)
  11. JTD121

    JTD121 Addicted to LI Member

    Sorry to revive a thread. But I have re-found out this device supports WPA2, but only 31-char.

    It's currently running Shibby 121 VPN (smallest available). So, I see in the Scheduler sectoin in Shibby, there are two pre-set things, and then a bunch of Custom configs available. Do the radio on/off things work in Shibby? If so, is there a place to figure out syntax for these commands? Once I figure out this, I will fine-tune with the times I'd actually want it on.

    There is also the Access Restriction area, which, as far as I can see, does not use military time, and looks like it might have the same issues parsing what I want to do as the previous Toastman build.

    Of course, if WiFi Analyzer would work on my phone, I could test and track if it were actually turning the radio on and off.....>_>

    Thanks for any help you can provide!
    Last edited: Aug 30, 2014
  12. koitsu

    koitsu Network Guru Member

    I don't think the radio on/off problem is "specific to Shibby" in any way; the reports I read were in Toastman, and it surely isn't specific to his firmware. The problem has to do with the wireless driver itself, which is closed-source / a binary blob provided by Broadcom and nobody can reverse-engineer it. If it contains bugs, we can't do anything about it. :/

    There is no place to find out syntax for commands. The command itself is radio, and there is no other documentation, other than looking at the source code (if available). Example:

    root@gw:/tmp/home/root# radio
    Usage: radio on|off|toggle|join [N]
    Another one is wl but I strongly suggest you do not mess with that (you can run it once to see all the features, and how bad the documentation is for the syntaxes). That's the CLI interface to the wireless driver, and there is a LOT there that is finicky. I strongly advocate publicly that people not mess around with wireless driver settings or "tinker" in any way. The reason is that people tend to just start "screwing with settings" and then saying "my problem is solved!" when in fact certain setting adjustments actually reset the internals of the wireless chip and the Linux driver itself, and **that** is what actually temporarily solves the problem, not the actual setting itself, but then they show up saying "that fixes the problem!" and the Internet latches on to this misinformation. This is semi-off-topic of course, but please hear me loud and clear on that.

    As for Access Restrictions and Scheduler: well, they're in military time for me. Screenshots attached. Firmware tomato-K26USB-NVRAM64K-1.28.0506.3MIPSR2Toastman-RT-N-Ext.trx on a RT-N66U.

    I think if you use the Scheduler along with radio, you will probably find "it works", but then "randomly" will stop working (either not turn the radio off, or not turn the radio on). This is the bug that Toastman et all were discussing in the thread I linked. And we sadly can't do anything about that, re: binary blob drivers, Broadcom closed-source, etc.. But if it does work for you, consistently 100% of the time, please be sure to state that! But hear me loud and clear: please do testing over the course of multiple weeks, preferrably an entire month. No I'm not kidding. 24-hour tests are not enough for this type of thing. ANYTHING that touches the wireless driver or its subinterfaces is very very sensitive, and radio does.

    Attached Files:

  13. JTD121

    JTD121 Addicted to LI Member

    Okay, well. I just recently upgraded to Shibby 121 in the K24 line, and no military time for me; not in Access Restriction or Scheduler. Weird. Though I have grown up using the AM/PM system, though I do recognize it when I see it.

    Do you happen to know what the [N] is referring to in the radio command list? Maybe if you have more than one radio? In a WRT54G, there's only the one 2.4GHz radio, correct?

    I will try this out and let you know how it works out. Now to add some reminders in my phone......
  14. JTD121

    JTD121 Addicted to LI Member

    Okay, so my setup has gone through. And of course I didn't check this morning before leaving. But I have set these up as such:

    Reboot: Sunday 12AM
    Custom 1: Radio on 4AM, Everyday
    Custom 2: Radio off 8AM, Everyday

    I'll have to pay attention over the next few days at least, and monitor for about a month, as you've said koitsu. Hopefully the weird bug mentioned earlier doesn't manifest itself, but that's why I also put the reboot weekly in there, in case that might be part of it?

    EDIT: Just read the thread you linked to, and while it might be in all builds of Tomato, I am running an older WRT54G (not sure on version right this second), using the 2.4 kernel....Would the kernel version matter at all? Regardless, will report over time on this. Thanks for your help!
    Last edited: Sep 4, 2014
  15. Siff

    Siff Serious Server Member

    I guess that all bets are off whether this will be an issue with the drivers for the 2.4 kernel or not. The drivers are different, but they are still binary blobs provided by Broadcom and nobody knows what exactly the issue is and whether it exists in the drivers for the 2.4 kernel.
    Last edited: Sep 4, 2014
  16. JTD121

    JTD121 Addicted to LI Member

    Yes, I understood that from my conversations with koitsu.

    Also, by the by, my main phone has decided to give up the ghost, so I can't track as effectively the operation of these rules. Will still attempt to do so with my work iPhone, though I don't know if there is a similar app to WiFi Analyzer there.

    Ah, and koitsu, the hardware revision I am running is a WRT54GL :)
  17. Siff

    Siff Serious Server Member

    As far as I know there are some apps which you can use, but I think that it will be better if you run a script on the router to check the status of the wireless radio (or to try to ping something through the WiFi) before and after the rules.
  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