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

Access Restriction problem [Shibby tomato-ND-1.28.5x-110-VPN]

Discussion in 'Tomato Firmware' started by bunk3m, Jun 29, 2013.

  1. bunk3m

    bunk3m Networkin' Nut Member

    Hi. {Newbie alert - I did do a Google and Search of forum but no luck finding solution}

    I flashed my WRT54GLv1 from Tomato 1.28 to Shibby tomato-ND-1.28.5x-110-VPN yesterday. The original Tomato was having some problems and I wanted to update with all the improvements.

    In the original I had access restriction (1) that would not allow any internet access between 22:00 and mid-night 0:00. Error msg in logs see below.

    Then I have (2) a complete shutdown of radio from 0:00 to 6:30. {I have kids who wouldn't sleep if the router was active .... long story.} No error message.

    (3) I also have a rule to restrict internet access for 3 MAC address between 15:30 and 18:00. No error msg.

    Rule (1) gives following error on both original Tomato and newly installed Shibby Tomato.

    Code:
    user.err rcheck: Iptables: activating chain "rdev05" failed. Retrying in 15 minutes.
    This error is only for stopping internet access for 3 MAC addresses between 22:00 and 0:00.

    The other rule works without problem.

    How can I fix this?

    Could it be that the problem is that there is an overlap of the times?
    Could it be that there is a problem because the rule ends at mid-night or 0:00?

    Thanks.
     
  2. Planiwa

    Planiwa LI Guru Member

    Might it be that multiple changes at the same time are not queued properly?
    Might ending one rule at 0000 and starting the next at 0001 work?
     
  3. bunk3m

    bunk3m Networkin' Nut Member

    Perhaps. Idont't think there is an option to set time at the minute, only 00/15/30/45 minutes.

    Is there a way to set 1 minute intervals?
     
  4. Planiwa

    Planiwa LI Guru Member

    You're right of course. So make it 00:15, or whatever suits you. It's easy for you to do and it *might* solve your problem, so why not "Just do it"? :)
     
  5. bunk3m

    bunk3m Networkin' Nut Member

    Hi again.

    I tried your suggestion and moved the later block by 15 minutes. However this hasn't fixed the problem. I think there is something wrong with the rule that is being created.

    I created a third rule - Block 3 MAC addresses from all internet access between 15:30 and 18:30 on Monday, Tues, Wed. and Thurs.

    This rule has the same error except it says "rdev 02" instead of "rdev 05".

    Any other suggestions as to why I'm getting errors?

    Is there a way to see the exact access restriction rule that is being created?
     
  6. bunk3m

    bunk3m Networkin' Nut Member

    Wondering if someone might be able to suggest how tomdo this?

    Is there a way to see the exact access restriction rule that is being created? Maybe I can debug if I see what is created.
     
  7. bunk3m

    bunk3m Networkin' Nut Member

    I'm still not able to get any time of day blocking of internet by mac address. I can't figure out what is going wrong and am beginning to think that it just doesn't work properly (or it's a PEBKAC?).

    Does this actually work for anyone?
     
  8. Monk E. Boy

    Monk E. Boy Network Guru Member

    When switching between firmwares, did you perform a long erase of NVRAM?

    Note that this will wipe out every setting you have currently configured, so be sure to write/copy them down before erasing.
     
  9. koitsu

    koitsu Network Guru Member

    With the 2200-0000 access restriction rule in place (but not working/returning an error), can you please provide output from the following commands (Tools / System / Command):

    Code:
    ls -l /etc/iptables*
    cat /etc/iptables
    iptables -L -n -v
    
    This should allow us to see all the proposed firewall rules (which includes access restriction rules) and figure out which one is causing the issue for you.

    Please do not fiddle around with anything in the meantime. The troubleshooting you've done so far (which is okay, don't get me wrong!) has caused the iptables chain name to change names once already, and if this recurs all it will do is make troubleshooting harder for those of us here who are trying to help.

    Thanks.
     
  10. bunk3m

    bunk3m Networkin' Nut Member

    Thanks for your help in debugging this.

    To Monk, I did a NVRAM erase on the update. But I downloaded the configuration and after flashing, I read the cfg file back in. Perhaps this was wrong??

    To koitsu, I deleted the 2 problem rules a week back. I haven't changed anything else. So I've recreated the rules and will post back info after they fire. I didn't know I could access a command line. Very cool!

    The rebuilt Access Restriction rules are:
    1) Normal Access Restriction: Block all internet access for 3 MAC addresses between 16:00 and 20:00 on Mon, Tue, Wed, Thur [ID:02]
    2) Norma Access Restriction: Block all internet access for 3 MAC addresses between 22:00 and 24:00 every day [ID:01]

    I also have one rule that always worked. It is
    3) Disable all wireless between 24:00 and 06:30. [ID:04]

    What I don't see in the rules below are rules to block (1) or (2). I would have expected to see those somewhere

    In the mean time here are the results from the commands:
    Code:
    ls -l /etc/iptables*
    ----
    -rw-r--r--    1 root    root          1454 Aug  7 09:23 /etc/iptables 
    Code:
    cat /etc/iptables
    ---
    *mangle
    :PREROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    COMMIT
    *nat
    :PREROUTING ACCEPT [0:0]
    :POSTROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    :WANPREROUTING - [0:0]
    -A PREROUTING -i vlan1 -d 192.168.2.2/255.255.255.0 -j DROP
    -A POSTROUTING  -o vlan1 -j MASQUERADE
    COMMIT
    *filter
    :INPUT DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    :logdrop - [0:0]
    -A logdrop -m state --state NEW -m limit --limit 20/m -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
    -A logdrop -j DROP
    :logreject - [0:0]
    -A logreject -m limit --limit 20/m -j LOG --log-prefix "REJECT " --log-tcp-sequence --log-tcp-options --log-ip-options
    -A logreject -p tcp -j REJECT --reject-with tcp-reset
    :logaccept - [0:0]
    -A logaccept -m state --state NEW -m limit --limit 20/m -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
    -A logaccept -j ACCEPT
    -A INPUT -m state --state INVALID -j DROP
    -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -i br0 -j ACCEPT
    -A INPUT -j logdrop
    :FORWARD DROP [0:0]
    -A FORWARD -m account --aaddr 192.168.2.0/255.255.255.0 --aname lan
    -A FORWARD -i br0 -o br0 -j ACCEPT
    -A FORWARD -m state --state INVALID -j DROP
    -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
    :wanin - [0:0]
    :wanout - [0:0]
    -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i vlan1 -j wanin
    -A FORWARD -o vlan1 -j wanout
    -A FORWARD -i br0 -j logaccept
    COMMIT 
    and
    Code:
    iptables -L -n -v
    ---
    Chain INPUT (policy DROP 0 packets, 0 bytes)
    pkts bytes target    prot opt in    out    source              destination         
        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID 
      115 20508 ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED 
        0    0 ACCEPT    all  --  lo    *      0.0.0.0/0            0.0.0.0/0           
      12  768 ACCEPT    all  --  br0    *      0.0.0.0/0            0.0.0.0/0           
        0    0 logdrop    all  --  *      *      0.0.0.0/0            0.0.0.0/0           
     
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts bytes target    prot opt in    out    source              destination         
        3  228            all  --  *      *      0.0.0.0/0            0.0.0.0/0          account: network/netmask: 192.168.2.0/255.255.255.0 name: lan 
        3  228 ACCEPT    all  --  br0    br0    0.0.0.0/0            0.0.0.0/0           
        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID 
        0    0 TCPMSS    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp flags:0x06/0x02 TCPMSS clamp to PMTU 
        0    0 ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED 
        0    0 wanin      all  --  vlan1  *      0.0.0.0/0            0.0.0.0/0           
        0    0 wanout    all  --  *      vlan1  0.0.0.0/0            0.0.0.0/0           
        0    0 logaccept  all  --  br0    *      0.0.0.0/0            0.0.0.0/0           
     
    Chain OUTPUT (policy ACCEPT 111 packets, 22825 bytes)
    pkts bytes target    prot opt in    out    source              destination         
     
    Chain logaccept (1 references)
    pkts bytes target    prot opt in    out    source              destination         
        0    0 LOG        all  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW limit: avg 20/min burst 5 LOG flags 7 level 4 prefix `ACCEPT ' 
        0    0 ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0           
     
    Chain logdrop (1 references)
    pkts bytes target    prot opt in    out    source              destination         
        0    0 LOG        all  --  *      *      0.0.0.0/0            0.0.0.0/0          state NEW limit: avg 20/min burst 5 LOG flags 7 level 4 prefix `DROP ' 
        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0           
     
    Chain logreject (0 references)
    pkts bytes target    prot opt in    out    source              destination         
        0    0 LOG        all  --  *      *      0.0.0.0/0            0.0.0.0/0          limit: avg 20/min burst 5 LOG flags 7 level 4 prefix `REJECT ' 
        0    0 REJECT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          reject-with tcp-reset 
     
    Chain wanin (1 references)
    pkts bytes target    prot opt in    out    source              destination         
     
    Chain wanout (1 references)
    pkts bytes target    prot opt in    out    source              destination          
    Thanks for your help everyone.
     
  11. bunk3m

    bunk3m Networkin' Nut Member

    Koitsu

    Sorry I forgot to add.

    I was expecting to see something like in the iptables:

    Code:
    iptables -A FORWARD -m mac --mac-source AA:BB:CC:DD:EE:FF -m -m time --timestart 16:00 --timestop 22:00 -j DROP
    Shouldn't something like this be in the output of the files I posted above?
     
  12. koitsu

    koitsu Network Guru Member

    Couple things:

    1. Yes, there is a full CLI available (via the GUI or via telnet, or SSH if you set it up). The firmware is Linux-based.

    2. Using Administration / Configuration / Backup Configuration and Restore Configuration are known to re-introduce NVRAM variables which may not be compatible (syntax-wise) with later firmwares. I.e. you use Backup Configuration with firmware 123, upgrade to 124, then upon doing that clear NVRAM (thorough or normal, doesn't matter), then proceed to use Restore Configuration with the file generated from firmware 123, which re-introduces NVRAM variables that may be deprecated and/or may have syntactical differences in their values. There is no technical solution to this dilemma at this time.

    I explain elsewhere how to rectify this problem, by keeping a text file laying around that describes all of the settings you change/etc. and when changing firmwares doing a thorough NVRAM clear followed by manually re-applying all the settings via the GUI. At this time this is the only way to ensure compatibility.

    Whether or not this is the root cause of your problem is unknown, but it's very possible.

    3. Re: access rules in /etc/iptables: this was my assumption as well, and it was a bad assumption on my part -- reality dictates something very different. The responsible source code for this is release/src/router/rc/restrict.c (note: looking at Toastman version, if there is a difference). The rcheck_main() routine clearly generates the rules based on NVRAM variables and issues the iptables commands separately/manually. They are not added to /etc/iptables (which is what I was incorrectly assuming).

    The error message is not helpful in any way, because all it's doing is pulling a return value from the routine called eval(). All this means is that the iptables command did not return an exit code of 0, which means something did not work. What did not work, as I said, is difficult to discern because the error message is not helpful.

    All I can think of to provide would be output from this:

    Code:
    nvram show | egrep "^(rrule|rdev|rres)"
    
    This will show all the relevant Access Restrictions bits/pieces that may be causing problems (maybe :p). From that myself or a developer has to manually parse the results, and manually generate the applicable iptables commands, and then have you run those via telnet/SSH (not via the GUI please) to see what sort of error you get back.

    The only other solution I can think of would be to enable eval() debug logging through NVRAM variable debug_logeval (i.e. nvram set debug_logeval=1 ; nvram commit), which should cause every single eval() call to get written to the kernel message log when adding a rule and clicking Save.

    Warning: an absolutely insane number of calls to this function are used throughout the firmware in all sorts of ways/methods. Expect a very, very large number of lines to appear if you turn this on, e.g. more than just things related to Access Restrictions. If you go this route, when done, you should delete the NVRAM variable (i.e. nvram unset debug_logeval ; nvram commit).

    The subsequent ipt_restrictions() routine looks like it does write things to /etc/iptables (it's not apparent to a generic end-user but the ip46t_write() calls used in that routine imply such). This function is called when the WAN comes up, so I imagine the rcheck_main() validator is not passing in advance of that.

    The entire Access Restrictions features/etc. is one gigantic clusterf*** of code. There is nothing elegant about it in any way/shape/form. When it breaks/causes problems for someone, it's often a serious time sink to figure out why. It really helps when the person who is experiencing issues can debug it themselves (looking at code, etc.) on their own router.

    It would probably also be helpful to get output from this:

    Code:
    cru l
    
    (That's a lowercase ELL, by the way)

    4. The example iptables command you gave is wrong syntactically in multiple ways. Your thought process/assumption is valid, but no, the command and way all of this works is very, very different than what you think. For example, there is absolutely no way in hell the kernel (netfilter/iptable/firewalling layer) itself would be responsible for keeping track of what time something should start/end (time of day) -- this is accomplished via cron (specifically the cru command alongside the cron daemon), not within the kernel itself. The kernel is not the place for such things. :)
     
  13. Monk E. Boy

    Monk E. Boy Network Guru Member

    Yeah, sorry, that's wrong. The config file is basically a dump of all your NVRAM, so wiping it put everything back to square one, but restoring the config put you right back to where you started, problems and all. If you keep spinning your wheels wiping the firmware and setting it up by hand is a good diagnostic step to try, and if it doesn't start working you can always restore your config...

    I just go through the firmware, page by page, and copy down (into a text file) whatever settings I changed, copying & pasting to avoid typing as much as possible, and then wipe NVRAM and start over from scratch.

    e.g.
    Basic
    (tab)Network
    (tab)(tab)WAN / Internet
    (tab)(tab)(tab)Type DHCP
    (tab)(tab)LAN
    (tab)(tab)(tab)Router IP Address 10.42.42.1
    (tab)(tab)(tab)Static DNS 208.67.222.220
    etc.

    On screen it should be visually very easy to follow along when you're setting everything back up. Notepad++ (an open source text editor) is probably easier to work with than Notepad or Wordpad.
     
  14. bunk3m

    bunk3m Networkin' Nut Member

    Hi! Thanks for all the help so far. I think I understand what you're saying.

    I think I'll provide the output from koitsu in the last post below and if you guys can't find anything specific I can check/change/test, then I'll copy all the settings into a plain text file and start from scratch (ie. flash, NVRAM erase and rebuild from the text file). I think it'll take a bit of work to document everything....

    Here is the output from
    Code:
    nvram show | egrep "^(rrule|rdev|rres)"
    Note that rrule0 is the default. I kept it as an example and never deleted it. It isn't enabled.

    Code:
    rrule0=0|1320|300|31|||word text ^begins-with.domain. .ends-with.net$ ^www.exact-domain.net$|0|example
    rrule1=1|1320|0|127|AA:BB:CC:DD:EE:FF>AA:BB:CC:DD:EE:F1>AA:BB:CC:DD:EE:F2|||0|Kids block from 22:00 to 24:00
    rrule2=1|960|1200|30|AA:BB:CC:DD:EE:FF>AA:BB:CC:DD:EE:F1>AA:BB:CC:DD:EE:F2|||0|Kids block after school
    rrule3=
    rrule4=1|0|390|127|~||||0|Block everything 24:00 to 6:30
    rrule5=
    rruleN=1
    rrules_activated=0
    rrules_radio=0
    rrules_timewarn=1
    rrulewp=80,8080 
    Here is the result from
    Code:
    cru l
    Code:
    0 */1 * * * logger -p syslog.info -- -- MARK -- #syslogdmark#
    41 1,13 * * * ntpsync --cron #ntpsync#
    32 */12 * * * /usr/sbin/tomatoanon #tomatoanon#
    */15 * * * * rcheck --cron #rcheck# 
    I'm a old guy newbie and can't see how this works. Hopefully you can see something that is getting screwed up.

    Could you elaborate about the iptable command? While I know this isn't the correct format for Tomato, I thought I would see something similar on Tomato. I think I understand how this is working on Tomato although I can't figure out the syntax. Yes, I also think I know what you mean it should be a cron job. But a cron job would be a bit ugly. What I read in the iptables man page (iptables v1.3.5) led me in the direction that the iptables command should be able to handle it. OOphs.

    Having said that, I think this command would be correct for Centos systems running iptables?? I tried to get this to work on my home Centos server (v5.x) with kernel 2.6.18 and iptables v1.3.5 and it also doesn't like the command even though -m time is included in the man pages. If I could get it working on Tomato, I wouldn't worry about the home server. Or vice versa.

    Actually the root cause of all this futzing around is my kids who don't seem to be able to shut off their devices when they're supposed to go to bed. :)
     
  15. Monk E. Boy

    Monk E. Boy Network Guru Member

    You really don't need to re-flash the firmware onto the device, unless there's evidence of a bug with the version you used, or evidence of corruption during the flash (which typically manifests as far more severe problems than you're seeing).

    I do think the advice you've been given is on the right track, I make sure access restrictions, scheduled tasks, etc. always occur before/after other events and never run simultaneously.

    Edit: Well of course they can't shut down their devices -- other kids aren't shutting theirs off, they don't want to be excluded from all the reindeer games.
     
  16. koitsu

    koitsu Network Guru Member

    1. I think I see the problem, but I will review the rules as best as I can and try to work out what I can. I will respond when I have time, which could be hours, days, weeks, or months. I cannot promise a response. You're welcome to review the code (I linked it) and see how the variables are parsed and work out the iptables commands that way if you wish.

    2. The iptables command you "invented" is for a different type of Linux distribution with iptables/netfilter modules that we do not have. It is not relevant to Tomato-based firmwares. Furthermore, it has an extraneous -m in it with no module name specified, thus would fail/be invalid.

    3a. cron is how "periodic tasks" are accomplished. The rcheck --cron entry you see in the crontab (that's effectively what you're listing off using cru l; run cru and see for yourself!) is what "periodically runs" -- every 15 minutes -- to see if a rule needs to be disabled/deleted (i.e. stopped) or needs to be added (i.e. started). This same code runs when you click Save (to cause what's necessary to take effect immediately if applicable). The output you're seeing here:

    Code:
    user.err rcheck: Iptables: activating chain "rdev05" failed. Retrying in 15 minutes.
    
    ...except with this in mind...

    ...is an indication that the relevant iptables command failed for the rrule02 NVRAM variable. Why it's failing is probably due to syntax/etc., hence Item #1 above, hence why I said all of what I said in my previous post. :) But that rule number/index may have changed, I really don't know.

    I would suggest doing what Monk E. Boy and myself have mentioned, which is erasing NVRAM and re-entering the necessary bits in by hand in the GUI, and not using Restore Configuration. If the problem persists after doing that, then that's definitely a bug/quirk that needs to get worked out/fixed in the firmware code! It's that simple. :)

    3b. Again I will repeat myself: time-based "things", as in "start at X hour, end at X hour", are not supposed to be done within kernel space. They are to be done within userland by things like a cron daemon or an at daemon. This is how they are implemented in Tomato, and this is how they are done within UNIX in general. The kernel is not the place for "scheduling tasks at a specific time of day"; whoever invented the iptables/netfilter module time should be taken out back and shot a thousand times over. :)

    4. Respectfully, not judgementally: this is not a CentOS support forum; please refer to their help forum/ticketing system/etc. if you have concerns there. This board is for Tomato-based firmwares only. Please stay focused.
     
  17. bunk3m

    bunk3m Networkin' Nut Member

    Thank you very much for your help.

    I understand about the Centos iptables. My apologies. I've been learning about Linux stuff for a long time and tend to forget quickly. Old guy syndrome. So I try too learn stuff by building on various experiences ... As misguided as it can sometimes be.

    I'll reflash and rebuild manually over the weekend and post my result. Then I'll try to understand the code stuff. But I know that is already quiet a stretch for me. Is One of those links a newbie explanation?

    BTW you have a great way of explaining and teaching. Thanks again for your help.

    B
     
  18. bunk3m

    bunk3m Networkin' Nut Member

    Just a quick note. I haven't given up just ran out of time. I report back when I've done reflash and new setup. Sorry for the delay.
     
  19. bunk3m

    bunk3m Networkin' Nut Member

    Finished the re-flash, clear NVRAM and new setup. I can't tell from the logs if it is actually doing any of the blocks.

    At the start of block at 22:00 I get:
    Code:
    Aug 16 22:00:01 unknown syslog.info root: -- MARK --
    
    So I can't tell if this blocked the 3 MAC addresses.

    Is there a way to get a more detailed log reports? I couldn't find a setting so far.

    When I set for the radio to shut off at mid-night I get the same message as above. So far so good??

    But when the radio is supposed to come back on at 06:30 I get this:
    Code:
    Aug 17 06:30:02 unknown user.notice kernel: __alloc_pages: 0-order allocation failed (gfp=0x20/0)
    
    This goes one for 3 seconds.

    I've read that this is something to do with fragmented memory but I can't see how that could happen on a fresh install and setup. Or is this something else?

    Do I need to do a manual reboot after doing the new flash and setup?
     
  20. bunk3m

    bunk3m Networkin' Nut Member

    It looks like it still doesn't work. Here is the log from last night.

    Code:
    Aug 18 22:00:01 unknown cron.info crond[6452]: crond: USER root pid 8029 cmd logger -p syslog.info -- -- MARK --
    Aug 18 22:00:01 unknown cron.info crond[6452]: crond: USER root pid 8030 cmd rcheck --cron
    Aug 18 22:00:01 unknown user.info rcheck[8032]: Activating rule 1
    Aug 18 22:00:01 unknown syslog.info root: -- MARK --
    Aug 18 22:00:01 unknown user.err rcheck[8032]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 18 22:06:06 unknown daemon.info dnsmasq-dhcp[6444]: DHCPREQUEST(br0) 192.168.x.y aa:bb:cc:dd:ee:ff
    Aug 18 22:06:06 unknown daemon.info dnsmasq-dhcp[6444]: DHCPACK(br0) 192.168.x.y f0:aa:bb:cc:dd:ee:ff block-me
    Aug 18 22:06:06 unknown daemon.info dnsmasq-dhcp[6444]: DHCPREQUEST(br0) 192.168.x.y aa:bb:cc:dd:ee:ff
    Aug 18 22:06:06 unknown daemon.info dnsmasq-dhcp[6444]: DHCPACK(br0) 192.168.x.y aa:bb:cc:dd:ee:ff block-me
    Aug 18 22:15:02 unknown cron.info crond[6452]: crond: USER root pid 8035 cmd rcheck --cron
    Aug 18 22:15:02 unknown user.info rcheck[8036]: Activating rule 1
    Aug 18 22:15:02 unknown user.err rcheck[8036]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 18 22:26:05 unknown daemon.info dnsmasq-dhcp[6444]: DHCPREQUEST(br0) 192.168.y.z bb:cc:dd:ee:ff:gg
    Aug 18 22:26:05 unknown daemon.info dnsmasq-dhcp[6444]: DHCPACK(br0) 192.168.y.z bb:cc:dd:ee:ff:gg DONT-BLOCK
    Aug 18 22:27:57 unknown daemon.info dnsmasq-dhcp[6444]: DHCPREQUEST(br0) 192.168.y.z bb:cc:dd:ee:ff:gg
    Aug 18 22:27:57 unknown daemon.info dnsmasq-dhcp[6444]: DHCPACK(br0) 192.168.y.z bb:cc:dd:ee:ff:gg DONT-BLOCK
    Aug 18 22:29:35 unknown daemon.info dnsmasq-dhcp[6444]: DHCPREQUEST(br0) 192.168.y.z bb:cc:dd:ee:ff:gg
    Aug 18 22:29:35 unknown daemon.info dnsmasq-dhcp[6444]: DHCPACK(br0) 192.168.y.z bb:cc:dd:ee:ff:gg DONT-BLOCK
    Aug 18 22:30:01 unknown cron.info crond[6452]: crond: USER root pid 8039 cmd rcheck --cron
    Aug 18 22:30:01 unknown user.info rcheck[8040]: Activating rule 1
    Aug 18 22:30:01 unknown user.err rcheck[8040]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 18 22:31:32 unknown daemon.info dnsmasq-dhcp[6444]: DHCPREQUEST(br0) 192.168.z.a cc:dd:ee:ff:gg:hh:ii
    Aug 18 22:31:32 unknown daemon.info dnsmasq-dhcp[6444]: DHCPACK(br0) 192.168.z.a cc:dd:ee:ff:gg:hh:ii
    Aug 18 22:45:01 unknown cron.info crond[6452]: crond: USER root pid 8043 cmd rcheck --cron
    Aug 18 22:45:01 unknown user.info rcheck[8044]: Activating rule 1
    Aug 18 22:45:01 unknown user.err rcheck[8044]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 18 22:46:01 unknown cron.info crond[6452]: crond: USER root pid 8047 cmd ntpsync --cron
    Aug 18 22:46:00 unknown user.info ntpc[8048]: Time Updated: Sun, 18 Aug 2013 22:46:00 -0400 [-1s]
    Aug 18 22:46:00 unknown user.info rcheck[8049]: Activating rule 1
    Aug 18 22:46:00 unknown user.err rcheck[8049]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 18 22:57:17 unknown daemon.info dnsmasq-dhcp[6444]: DHCPREQUEST(br0) 192.168.z.a cc:dd:ee:ff:gg:hh:ii
    Aug 18 22:57:17 unknown daemon.info dnsmasq-dhcp[6444]: DHCPACK(br0) 192.168.z.a cc:dd:ee:ff:gg:hh:ii
    Aug 18 23:00:01 unknown cron.info crond[6452]: crond: USER root pid 8062 cmd logger -p syslog.info -- -- MARK --
    Aug 18 23:00:01 unknown cron.info crond[6452]: crond: USER root pid 8063 cmd rcheck --cron
    Aug 18 23:00:01 unknown syslog.info root: -- MARK --
    Aug 18 23:00:01 unknown user.info rcheck[8065]: Activating rule 1
    Aug 18 23:00:01 unknown user.err rcheck[8065]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 18 23:15:01 unknown cron.info crond[6452]: crond: USER root pid 8068 cmd rcheck --cron
    Aug 18 23:15:01 unknown user.info rcheck[8069]: Activating rule 1
    Aug 18 23:15:01 unknown user.err rcheck[8069]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 18 23:30:01 unknown cron.info crond[6452]: crond: USER root pid 8072 cmd rcheck --cron
    Aug 18 23:30:01 unknown user.info rcheck[8073]: Activating rule 1
    Aug 18 23:30:01 unknown user.err rcheck[8073]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 18 23:45:01 unknown cron.info crond[6452]: crond: USER root pid 8076 cmd rcheck --cron
    Aug 18 23:45:02 unknown user.info rcheck[8077]: Activating rule 1
    Aug 18 23:45:02 unknown user.err rcheck[8077]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 19 00:00:01 unknown cron.info crond[6452]: crond: USER root pid 8080 cmd logger -p syslog.info -- -- MARK --
    Aug 19 00:00:01 unknown cron.info crond[6452]: crond: USER root pid 8081 cmd rcheck --cron
    Aug 19 00:00:01 unknown syslog.info root: -- MARK --
    Aug 19 00:00:01 unknown user.info rcheck[8083]: Activating rule 2
    
    Since I did a re-flash and reset everything from scratch, the rule numbers have changed.

    rdev01 is the rule to block 3 MAC addresses between 22:00 and 0:00.

    rdev02 is turn off wireless between 0:00 and 06:30. rdev02 works.
     
  21. bunk3m

    bunk3m Networkin' Nut Member

    Here is the result of
    Code:
    nvram show | egrep "^(rrule|rdev|rres)"
    Code:
    rrule0=0|1320|300|31|||word text ^begins-with.domain. .ends-with.net$ ^www.exact-domain.net$|0|example
    rrule1=1|1320|0|127|AA:BB:CC:DD:EE:FF>BB:CC:DD:EE:FF:GG>CC:DD:EE:FF:GG:HH|||0|Block Kids after 10pm
    rrule2=1|0|390|127|~||||0|Block everything after midnight
    rruleN=2
    rrules_activated=0
    rrules_radio=0
    rrules_timewarn=1
    rrulewp=80,8080 
    and

    Code:
    cru l
    Code:
    46 14,18,22,2,6,10 * * * ntpsync --cron #ntpsync#
    0 */1 * * * logger -p syslog.info -- -- MARK -- #syslogdmark#
    16 */6 * * * /usr/sbin/tomatoanon #tomatoanon#
    */15 * * * * rcheck --cron #rcheck# 
     
  22. koitsu

    koitsu Network Guru Member

    Please telnet/SSH into the router and issue the following command:

    nvram set debug_logeval=1 ; nvram commit ; tail -f /var/log/messages

    This command will not end (you will need to press Control-C to get back to the prompt), but will instead be viewing the log file in real-time.

    Hit Enter a few times, to make some "fake blank lines" in your terminal, allowing you to know/see/reference where the log file was before new changes arrived in it.

    Then, wait 15 minutes (or thereabouts) for the rcheck cron job to run. It will fail like before and will emit the same error in the log. However, this time there should be a *ton* of logging data (this would be the eval() logging I mentioned earlier). I need to see those log messages. This makes my task a lot easier.

    After you get some of that, you can press Control-C to get back to the shell prompt, and then should issue this command:

    nvram unset debug_logeval ; nvram commit

    And then you can log out.
     
  23. bunk3m

    bunk3m Networkin' Nut Member

    Hi. I have tried this eval() as per the instructions. I'm not getting a "ton" of logging data. Here is from a few minutes before 22:00 when rrule01 should fire and block 3 mac addresses.
    Code:
    Aug 19 22:00:01 unknown cron.info crond[6452]: crond: USER root pid 9703 cmd logger -p syslog.info -- -- MARK --
    Aug 19 22:00:01 unknown cron.info crond[6452]: crond: USER root pid 9704 cmd rcheck --cron
    Aug 19 22:00:01 unknown syslog.info root: -- MARK --
    Aug 19 22:00:01 unknown user.info rcheck[9706]: Activating rule 1
    Aug 19 22:00:01 unknown user.err rcheck[9706]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    
    I'll wait for a while and see if anything else happens in the next couple of 15 minute intervals. Then I'll post the additional information.
     
  24. koitsu

    koitsu Network Guru Member

    Hrm, I'm not sure why the eval() logging stuff isn't working, I must have missed something in my code review.

    I will have to find the time to manually decode the rrule01 syntax and work it into whatever would be run via eval("iptables", ...).
     
  25. koitsu

    koitsu Network Guru Member

    In the meantime can you provide a screenshot of the Access Restriction section with all the relevant info put in? I should note that you repeatedly hiding/changing the MAC addresses before posting here gains you absolutely nothing security-wise, so I'd appreciate it if you could leave those verbatim.

    I have a feeling I know what the cause is, but I need to review the code.
     
  26. bunk3m

    bunk3m Networkin' Nut Member

    OK will do.

    Here is the rest of the log info:

    Code:
    Aug 19 22:15:01 unknown cron.info crond[6452]: crond: USER root pid 9752 cmd rcheck --cron
    Aug 19 22:15:01 unknown user.info rcheck[9753]: Activating rule 1
    Aug 19 22:15:01 unknown user.err rcheck[9753]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 19 22:30:01 unknown cron.info crond[6452]: crond: USER root pid 9756 cmd rcheck --cron
    Aug 19 22:30:01 unknown user.info rcheck[9757]: Activating rule 1
    Aug 19 22:30:01 unknown user.err rcheck[9757]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 19 22:45:01 unknown cron.info crond[6452]: crond: USER root pid 9760 cmd rcheck --cron
    Aug 19 22:45:01 unknown user.info rcheck[9761]: Activating rule 1
    Aug 19 22:45:01 unknown user.err rcheck[9761]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 19 22:46:01 unknown cron.info crond[6452]: crond: USER root pid 9764 cmd ntpsync --cron
    Aug 19 22:46:01 unknown user.info ntpc[9765]: Time: Mon, 19 Aug 2013 22:46:01 -0400, no change was needed.
    Aug 19 22:46:01 unknown user.info rcheck[9766]: Activating rule 1
    Aug 19 22:46:01 unknown user.err rcheck[9766]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 19 23:00:01 unknown cron.info crond[6452]: crond: USER root pid 9779 cmd logger -p syslog.info -- -- MARK --
    Aug 19 23:00:01 unknown cron.info crond[6452]: crond: USER root pid 9780 cmd rcheck --cron
    Aug 19 23:00:01 unknown syslog.info root: -- MARK --
    Aug 19 23:00:01 unknown user.info rcheck[9782]: Activating rule 1
    Aug 19 23:00:01 unknown user.err rcheck[9782]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    Aug 19 23:11:49 unknown daemon.info dnsmasq-dhcp[6444]: DHCPDISCOVER(br0) 28:37:37:e0:08:c5
    Aug 19 23:11:49 unknown daemon.info dnsmasq-dhcp[6444]: DHCPOFFER(br0) 192.168.2.102 28:37:37:e0:08:c5
    Aug 19 23:11:51 unknown daemon.info dnsmasq-dhcp[6444]: DHCPREQUEST(br0) 192.168.2.102 28:37:37:e0:08:c5
    Aug 19 23:11:51 unknown daemon.info dnsmasq-dhcp[6444]: DHCPNAK(br0) 192.168.2.102 28:37:37:e0:08:c5 wrong server-ID
    Aug 19 23:15:01 unknown cron.info crond[6452]: crond: USER root pid 9785 cmd rcheck --cron
    Aug 19 23:15:01 unknown user.info rcheck[9786]: Activating rule 1
    Aug 19 23:15:01 unknown user.err rcheck[9786]: Iptables: activating chain "rdev01" failed. Retrying in 15 minutes.
    
    Looks the same as the earlier one.

    I'll get to the screenshot next. I may be changing the MAC and IP addresses but they are being changed consistently so that you can trace each. Having said that, I'll post the screenshot unaltered.
     
  27. bunk3m

    bunk3m Networkin' Nut Member

    Screen shot as requested. For rule 1.
     
    Last edited: Dec 1, 2013
  28. koitsu

    koitsu Network Guru Member

    Thank you, I will attempt to reproduce this so that I can troubleshoot it from my end.
     
  29. bunk3m

    bunk3m Networkin' Nut Member

    Thanks for your help.

    Please let me know what you do so I might learn how to debug problems better. And maybe I can be helpful to others sometime in the future.

    Appreciate very much that you take time to help!
     
  30. koitsu

    koitsu Network Guru Member

    NOTE: Sorry about the formatting in the code blocks -- the forum screws up the spacing/formatting when you do a Preview or an Edit. It's not my fault, it's a bug that's existed for some time.

    Anyway....

    I cannot reproduce the problem using tomato-K26USB-1.28.0502.8MIPSR2Toastman-RT-N-Ext.trx on my Asus RT-N16.

    Proof is below, in screenshots and snippets. Note that I changed the timeframe for the access block to my present time (it's 0730 here right now) to see the rule get activated.

    Code:
    root@gw:/tmp/home/root# nvram show | egrep "^(rrule|rdev|rres)"
    root@gw:/proc/net# nvram show | egrep "^(rrule|rdev|rres)"
    rrule0=0|1320|300|31|||word text ^begins-with.domain. .ends-with.net$ ^www.exact-domain.net$|0|example
    rrule1=1|420|480|127|DE:AD:BE:EF:F0:0D>B0:0B:BA:BE:DE:AD|||0|Block Kids after 10pm
    rruleN=1
    rrules_activated=2
    rrules_radio=-1
    rrulewp=80,8080
    
    Here I show the relevant iptables portions, which clearly show packet counters going through, and you can see the restrict chain in use:

    Code:
    root@gw:/proc/net# iptables -L -n -v --line-numbers
    ...
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    num  pkts bytes target  prot opt in  out  source  destination
    1  0  0 ACCEPT  all  --  br0  br0  0.0.0.0/0  0.0.0.0/0
    2  0  0 DROP  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state INVALID
    3  2  116 TCPMSS  tcp  --  *  *  0.0.0.0/0  0.0.0.0/0  tcp flags:0x06/0x02 TCPMSS clamp to PMTU
    4  730 53051 restrict  all  --  *  vlan2  0.0.0.0/0  0.0.0.0/0
    5  1440  117K ACCEPT  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
    6  0  0 wanin  all  --  vlan2  *  0.0.0.0/0  0.0.0.0/0
    7  15  960 wanout  all  --  *  vlan2  0.0.0.0/0  0.0.0.0/0
    8  15  960 ACCEPT  all  --  br0  *  0.0.0.0/0  0.0.0.0/0
    9  0  0 upnp  all  --  vlan2  *  0.0.0.0/0  0.0.0.0/0
    ...
    Chain rdev01 (1 references)
    num  pkts bytes target  prot opt in  out  source  destination
    1  0  0 DROP  all  --  *  *  0.0.0.0/0  0.0.0.0/0  MAC DE:AD:BE:EF:F0:0D
    2  0  0 DROP  all  --  *  *  0.0.0.0/0  0.0.0.0/0  MAC B0:0B:BA:BE:DE:AD
    
    Chain restrict (1 references)
    num  pkts bytes target  prot opt in  out  source  destination
    1  729 52987 rdev01  all  --  *  *  0.0.0.0/0  0.0.0.0/0
    ...
    
    Here is what's in my /etc/iptables (relevant parts):

    Code:
    :restrict - [0:0]
    -A FORWARD -o vlan2 -j restrict
    :rres01 - [0:0]
    -X rres01
    :rdev01 - [0:0]
    -A rdev01 -m mac --mac-source DE:AD:BE:EF:F0:0D -j DROP
    -A rdev01 -m mac --mac-source B0:0B:BA:BE:DE:AD -j DROP
    
    I'll note that you might expect to see an entry in the restrict chain that references rdev01 (since that's how it works and is working via the above iptables) -- that's what the cronjob does: it puts that "connection" into place when needed (at certain times of the day).

    And finally the cronjob:

    Code:
    root@gw:/proc/net# cru l
    40 8,10,12,14,16,18,20,22,0,2,4,6 * * * ntpsync --cron #ntpsync#
    */15 * * * * rcheck --cron #rcheck#
    
    I do not have anything in my messages log for rcheck, because I did not enable logging of Access Restrictions. But it doesn't matter -- you can clearly see the rules are working/are in place in iptables.

    TL;DR -- I cannot reproduce this issue. It looks like it may be a bug in Shibby's builds. I recommend trying another firmware, like Toastman, and see if the problem exists for you there. Be sure after switching to do a thorough NVRAM clear (via the GUI) and after that re-set all the settings manually (via the GUI).

    If this turns out to be a Shibby build bug, I am certain he will comment here and assist. He's very active here on the forums and is always very helpful. :)
     

    Attached Files:

  31. bunk3m

    bunk3m Networkin' Nut Member

    Hmmm. Interesting. I've been comparing your output to mine with the re-flash, reset NVRAM and new setup.

    Code:
    /proc/net# nvram show | egrep "^(rrule|rdev|rres)"
    rrule0=0|1320|300|31|||word text ^begins-with.domain. .ends-with.net$ ^www.exact-domain.net$|0|example
    rrule1=1|1320|0|127|D4:9A:20:25:45:E1>F0:B4:79:6D:97:6E>E4:25:E7:A9:DE:5B|||0|Block Kids after 10pm
    rrule2=1|0|390|127|~||||0|Block everything after midnight
    rruleN=1
    rrules_activated=0
    rrules_radio=0
    rrules_timewarn=1
    rrulewp=80,8080
    
    You will note that on my WRT54GL
    Code:
    rrules_activated=0
    rrules_radio=0
    rrules_timewarn=1
    
    vs your N16
    Code:
    rrules_activated=2
    rrules_radio=-1
    Both of the rules on my WRT54GL are "enabled" in the GUI, but it looks from the output that they are not activated??

    Could you try with three IP addresses just in case that two works but 3 doesn't? I created a 2 MAC address rule to see if this works and will report back later.

    I checked and have NO "chain rdev01" and NO "chain restrict" in the iptables -L

    Also I've checked the /etc/iptables and there are NO "restrict" there either.

    I almost think that it isn't setting the blocks even though they are enabled via the GUI.

    I'm wondering if this might be a problem with the kernel. I'm running the k24 and I see you are running k26??
     
  32. bunk3m

    bunk3m Networkin' Nut Member

    Just a quick note re test using 2 MAC addresses. This rule identical to those above failed with 2 MAC addresses. So it's got to be something else.
     
  33. bunk3m

    bunk3m Networkin' Nut Member

    Just noticed something else. I tried to delete the test rule with 2 MAC addresses and this version of Shibby won't delete the rule from the GUI. :( Or it might be the Firefox 23 problem that you mention in another post

    Now I don't know how to get rid of the test rule.
     
    Last edited: Aug 20, 2013
  34. bunk3m

    bunk3m Networkin' Nut Member

    Hi again. I flashed to Toastman version
    Code:
    Tomato Firmware v1.28.7633 .3-Toastman-VLAN-IPT-ND ND VPN
    We'll have to see if that fixes things. If yes, then I'm assuming the Shibby version has a bug(??).
     
  35. bunk3m

    bunk3m Networkin' Nut Member

    OK created a test block and it doesn't work.

    Code:
    user.info rcheck[1006]: Activating rule 3
    
    user.err rcheck[1006]: Iptables: activating chain "rdev03" failed. Retrying in 15 minutes.
    Damn! Looks like it's not going to work with Toastman's build either. Oh WTF?? This is getting frustrating.
     
  36. bunk3m

    bunk3m Networkin' Nut Member

    BTW, I've been using the latest Chrome browser and it won't allow deleting of rules either.
     
  37. Monk E. Boy

    Monk E. Boy Network Guru Member

    Try not using Chrome, reset the router to defaults, set it back up, and see if the problems still occur.
     
  38. bunk3m

    bunk3m Networkin' Nut Member

    Awe, I just set up the router two hours ago fresh flash, clean NVRAM, clean set-up from scratch. All to test if I could get the access restrictions to work. Now I can't delete the test restriction.

    Even rebooted the router.

    The delete doesn't work with either Firefox 23.0.1 or Chrome. Press on the Delete button and nothing happens except for the button disappearing.

    Just tested with Safari. VoilĂ  it works! What makes Safari different to use with Toastman Tomato?
     
  39. Monk E. Boy

    Monk E. Boy Network Guru Member

    Delete works fine from here in Firefox, but Chrome has been known to create problems where none actually exist. Setting up the router in Chrome could yield problems later, even when using different browsers.

    Edit: Well would you look at that, Firefox 23.x is broken too now, it won't let you delete rules anymore. Just freakin' wonderful. Its bad enough Mozilla is updating every other night, now they're breaking stuff. It's like they're in a competition with Google to see how many websites they can break the fastest.
     
    Last edited: Aug 21, 2013
  40. koitsu

    koitsu Network Guru Member

    The inability to delete an Access Restriction rule is indeed some kind of Javascript-or-whatever bug/quirk (and obviously needs to be fixed in Tomato, period); for now you should use a browser like Internet Explorer to delete rules (I've only tested using IE8; I run XP so I do not have IE9). I started a separate thread about that:

    http://www.linksysinfo.org/index.ph...-bug-with-firefox-23-cant-delete-rules.68914/

    Let's keep this one focused on the issue of the Access Restriction entries not working.

    As for all the other babble in this post (sorry I just woke up and can't be bothered to think of a more eloquent word right now):

    * You won't see the "restrict" or "rdev01" rules in iptables -L because the eval() function that runs/calls the iptables command (to create those rules/chains) fails. I think this is the third time I've told you this. :)
    * /etc/iptables won't show relevant bits in it either, for the same reason as I just mentioned.

    Since I can't reproduce the issue on the hardware I have, I don't know what else I can do.

    Comparing the relevant NVRAM variables (mine vs. yours):

    Code:
    rrule1=1|420|480|127|DE:AD:BE:EF:F0:0D>B0:0B:BA:BE:DE:AD|||0|Block Kids after 10pm
    
    Code:
    rrule1=1|1320|0|127|D4:9A:20:25:45:E1>F0:B4:79:6D:97:6E>E4:25:E7:A9:DE:5B|||0|Block Kids after 10pm
    
    Decoding the syntax (pipe ("|") delimited):

    Argument 0: rule status: 1 = enabled, 0 = disabled
    Argument 1: Time (in minutes) of when the rule should be enabled (ex. 420 means 420/60 = 7, a.k.a. 0700); 0 means 0000 hours
    Argument 2: Time (in minutes) of when the rule should be disabled
    Argument 3: Unsure at this time, but I'm guessing it's a bitfield relating to Schedule (All Day/Every Day/which days)
    Argument 4: List of MACs or IPs which should have rules made for them (one iptables rule per MAC or IP). Multiple MACs and IPs are supported using the ">" delimiter between them.
    Argument 5: Unknown
    Argument 6: If specified, is a pseudo-regex list of strings/words to block (domain names/website names, words in web pages, etc.)
    Argument 7: Unknown
    Argument 8: Description/comment of the Access Restriction rule

    The only differences between your rule and my rule:

    - Mine starts @ 0700 / ends @ 0800. Yours starts @ 2200 / ends @ 0000
    - Mine has 2 MAC addresses. Yours has 3. But you already tried a smaller number of MACs (to see if the parser was breaking somehow) and there was no difference, so the number of MACs isn't the issue

    I do not necessarily think "the issue is in the kernel", but rather that the issue may be related to iptables/netfilter modules not loading (maybe not enough RAM on the WRT54GLv1 to load them, etc.). And yes of course I run K26.

    At this point I'm going to just say it: unless someone can send me a WRT54GLv1 (I used to have one but sold it!) where I can try to reproduce this on and figure out what's going on, troubleshooting/diagnosing this online is going to take up man hours to the point where I feel I would need to be paid for it. I can get things done in person with the hardware a LOT quicker. If someone wants to ship me a WRT54GLv1 which I can bang away on, I'll be happy to do the work, otherwise someone else who is familiar with troubleshooting these kinds of problems (familiar with C, looking at the Tomato code, familiar with iptables/netfilter and Linux from a sysadmin perspective) would need to help.

    I'll have more to say in my next post (some commands/etc. to try out).
     
    Last edited: Aug 21, 2013
  41. koitsu

    koitsu Network Guru Member

    I took the time tonight to work out how to do this by hand. Here are my instructions for trying to reproduce this from the CLI manually, so that we can see what the error is that is happening (hopefully -- no guarantees), and also how to "clean up" after doing this.

    Please read everything I have written slowly and thoroughly. Go slowly. If you mess something up, you can always reboot the router from the GUI or power-cycle it without any repercussions (the below tests are temporary!).

    1. Make sure that Access Restrictions has no rules in it that are enabled (either leave the rules you wrote but mark them as disabled, or delete them entirely). The "example" rule you can leave.

    2. Telnet/SSH into the router

    3. Find out what the WAN interface name is for your setup by running the command nvram get wan_iface. It should be return like vlan2 or vlan1.

    4. Below are a series of commands I'm going to have you execute at the CLI. Replace the string #WAN# with the interface name you got back from step #3. The instant there are problems/errors (iptables will tell you) please IMMEDIATELY STOP doing any more commands/further steps in the 4x list.

    4a.

    Code:
    iptables -N rdevtest
    iptables -A rdevtest -m mac --mac-source 11:22:33:44:55:66 -j DROP
    iptables -A rdevtest -m mac --mac-source 77:88:99:aa:bb:cc -j DROP
    
    If any part of this fails, to "roll back", execute: iptables -F rdevtest ; iptables -X rdevtest

    4b.

    Code:
    iptables -N restricttest
    iptables -A restricttest -j rdevtest
    
    If any part of this fails, to "roll back", execute: iptables -F restricttest ; iptables -X restricttest ; iptables -F rdevtest ; iptables -X rdevtest

    4c.

    Code:
    iptables -I FORWARD 4 -o #WAN# -j restricttest
    
    If any part of this fails, to "roll back", execute: iptables -F restricttest ; iptables -X restricttest ; iptables -F rdevtest ; iptables -X rdevtest

    If all of the commands above worked (including (4c)), then I'm baffled. In that case, rolling back would be accomplished by doing this (be very careful here!): iptables -D FORWARD 4 ; iptables -F restricttest ; iptables-X restricttest ; iptables -F rdevtest ; iptables -X rdevtest

    5. In the case of any errors, I need to see the full output (from the beginning to end -- do not omit anything!) so I can see what's going on.
     
    Last edited: Aug 21, 2013
    bunk3m likes this.
  42. bunk3m

    bunk3m Networkin' Nut Member

    Hello koitsu.

    Even though I'm subscribed to this thread, I never saw your final update. I have to apologize for not checking back. Got too busy and gave up until today when frustration built up again.

    I tried everyone of your steps above and didn't get an error. I wish I could understand what these commands do so I could participate better in figuring out what the heck is wrong. Is there a list somewhere of these commands or a glossary?

    Here is the output of all the steps.

    Please note that there was no errors.

    I included all the output but only split it up to coincide with the sequence of questions. I'm still scratching my head why this doesn't want to work.

    Code:
    Disabled both rules.

    Code:
    ssh -l root 192.168.2.2
    root@192.168.2.2's password:
    Tomato v1.28.7633 .3-Toastman-VLAN-IPT-ND ND VPN
    Code:
    /tmp/home/root# nvram get wan_iface
    vlan1
    Code:
    /tmp/home/root# iptables -N rdevtest
    /tmp/home/root# iptables -A rdevtest -m mac --mac-source 11:22:33:44:55:66 -j DROP
    /tmp/home/root# iptables -A rdevtest -m mac --mac-source 77:88:99:aa:bb:cc -j DROP
    
    Code:
    /tmp/home/root# iptables -N restricttest
    /tmp/home/root# iptables -A restricttest -j rdevtest
    
    Code:
    /tmp/home/root# iptables -I FORWARD 4 -o vlan1 -j restricttest
    Code:
    /tmp/home/root# iptables -D FORWARD 4
    /tmp/home/root# iptables -F restricttest
    /tmp/home/root# iptables-X restricttest
    -sh: iptables-X: not found
    /tmp/home/root# iptables -X restricttest
    /tmp/home/root# iptables -F rdevtest
    /tmp/home/root# iptables -X rdevtest
    
    Other than one typo on the "iptables-X" there was no other output.

    Thanks again for your help and patients. And, sorry for not posting back for so long.

    I'll try to setup the subscription again so maybe I'll get update notices.
     
  43. Marcel Tunks

    Marcel Tunks Networkin' Nut Member

    I seem to recall someone having a similar problem with Toastman, Shibby, and original Tomato that was solved in recent Victek builds. Make sure you do long NVRAM erase after switching firmware versions, and enter new settings by hand or cut and paste from a text file (paste as plain text).
     
  44. bunk3m

    bunk3m Networkin' Nut Member

    Thanks @Marcel Tunks, I'll look into this.

    I've never used the Victek builds but I'm quite happy to try something new. Now to find them...
     
  45. Elfew

    Elfew Addicted to LI Member

    Tomatoraf.com
     
  46. bunk3m

    bunk3m Networkin' Nut Member

    Thanks, found the site!!

    But it looks like the most recent version for the WRT54GL is Tomato_RAF_1.25.8515.2-ND.trx
    Unzipping the file shows a date of July 23, 2009 (?huh?)

    It looks like 1.28.9013 isn't available for WRT54GL? :-(

    Or I'm not capable of finding it.
     
  47. bunk3m

    bunk3m Networkin' Nut Member

    [off topic]
    By the by @Elfew. How did you get the cat to sit there so nicely while you took the picture with helmet. ha ha So sweet!
    [/off topic]
     
  48. Elfew

    Elfew Addicted to LI Member

    just contact @Victek and ask him
     
  49. bunk3m

    bunk3m Networkin' Nut Member

    Will do! Thanks again!
     
  50. mstombs

    mstombs Network Guru Member

    I'm sure there was a later version for WRT54GL, Victek gave us a Christmas present in 2010 that allegedly could achieve 80Mbps throughput (121006, 6th December 2010), but looks like he concentrates on more modern mipsr2 hardware and K2.6 kernel these days.
     
  51. Victek

    Victek Network Guru Member

    Yes .. I already answered @bunk3m PM... Tomato RAF as it's today can't fit in 4MB Flash routers... but who knows, let's wait Christmas again.... ;)
     
  52. bunk3m

    bunk3m Networkin' Nut Member

    @koitsu,

    Is there a way to check the version of IPTABLES that is installed and check that the --time option is actually enabled in this version?

    I seem to remember reading that with kernel 2.4 the --time option wasn't available or had to be specifically compiled in.

    If that is the case, then the --mac & --time won't work??

    Thanks again.
     
  53. koitsu

    koitsu Network Guru Member

    I'm sorry I didn't get back to you sooner; a very close/intimate friend of mine who I'd known for 2 years passed away on Tuesday, and I have been grieving + on bereavement leave from work since.

    Easiest way I know to do that is to use iptables -m time --help and look through the usage syntax.

    If the time module is statically compiled into the netfilter layer of the kernel, or is available as a dynamically-loaded netfilter module, then you'll get something at the bottom (ideally) showing how to use --time and what syntaxes it supports. Example:

    Code:
    root@gw:/tmp/home/root# iptables -m time --help
    ...
    TIME v1.3.8 options:
    [ --timestart value ] [ --timestop value] [ --days listofdays ] [ --datestart value ] [ --datestop value ]
      timestart value : HH:MM (default 00:00)
      timestop  value : HH:MM (default 23:59)
      Note: daylight savings time changes are not tracked
      listofdays value: a list of days to apply
      from Mon,Tue,Wed,Thu,Fri,Sat,Sun
      Coma speparated, no space, case sensitive.
      Defaults to all days.
      datestart value : YYYY[:MM[:DD[:hh[:mm[:ss]]]]]
      If any of month, day, hour, minute or second is
      not specified, then defaults to their smallest
      1900 <= YYYY < 2037
      1 <= MM <= 12
      1 <= DD <= 31
      0 <= hh <= 23
      0 <= mm <= 59
      0 <= ss <= 59
      datestop  value : YYYY[:MM[:DD[:hh[:mm[:ss]]]]]
      If the whole option is ommited, default to never stop
      If any of month, day, hour, minute or second is
      not specified, then default to their smallest
    
    Otherwise if it's not available, you'll see something like this:
    Code:
    root@gw:/tmp/home/root# iptables -m time --help
    iptables v1.3.8: Couldn't load match `time':File not found
    
    Try `iptables -h' or 'iptables --help' for more information.
    
    The same methodology applies for the mac module, or any netfilter module for that matter.
     
  54. bunk3m

    bunk3m Networkin' Nut Member

    Sorry to hear about your loss.

    I appreciate all your help so don't worry about timing to reply.

    I've tried both of the commands and both show that these commands --timestart etc. and --macsource have help.

    Since I can't get this to work via the GUI could I solve this problem by running a script?

    Code:
    iptables -A FORWARD -i vlan1 -m mac --mac-source MACADDRESS -m time --timestart 22:00:00 --timestop 06:30:00 
    Perhaps I would be using
    Code:
    -i eth1
    instead?

    Or perhaps there is a possibility to create a local iptables file that won't get updated from the gui but still would be run upon a restart or refresh to load the local rules? I'd put the same rule as above in that file? Does something like that exist?

    PS I seem to have some problems getting emails that the thread has been updated so it's taken me a bit longer to test things and to respond. Thanks for your patients.
     
  55. koitsu

    koitsu Network Guru Member

    Is the problem that the command works from the CLI (telnet/SSH) but not from the GUI?
     
  56. bunk3m

    bunk3m Networkin' Nut Member

    I don't know. I've never tried to use the IPTABLES command from the CLI.

    I always thought it needed to look like
    Code:
    rrule1=1|420|480|127|DE:AD:BE:EF:F0:0D>B0:0B:BA:BE:DE:AD|||0|Block Kids after 10pm
    so I never tried.

    If IPTABLES command works, I'll give it a whirl and see if it does what it's supposed to do. That would be cool! :)
     
  57. bunk3m

    bunk3m Networkin' Nut Member

    Following doesn't work.
    Code:
    iptables -A FORWARD -i vlan1 -m mac --mac-source MACADDRESS -m tim
    e --timestart 15:00 --timestop 18:30 -j DROP
    I get error:
    Code:
    iptables: No chain/target/match by that name
    Not sure what that is supposed to mean.
     
  58. koitsu

    koitsu Network Guru Member

    I spent some time on this. The fault is not yours. iptables is known for being extremely stupid/bad/broken when it comes to behaviour and argument parsing. This is one of the many reasons I really don't like iptables and prefer OpenBSD/FreeBSD pf (though it lacks features like this; usually this is left to cronjobs).

    The time module appears to be one of the modules which cannot be automatically loaded by iptables dynamically on-the-fly and must be loaded manually beforehand. I consider this a bug (and this is not the first time this has come up in recent days, by the way -- some modules work fine with it, others do not).

    You need to issue the following command (and only once per reboot) before issuing your iptables commands:

    modprobe ipt_time

    You can verify the module loaded by using lsmod and looking for yourself. After it's loaded, you should be able to use -m time and its related arguments without that error. I have verified myself.

    If when using -m mac you also receive a similar error (I didn't test this one), try modprobe ipt_mac beforehand.
     
  59. mstombs

    mstombs Network Guru Member

    I don't think this is specifically an iptables problem - it is a Tomato firmware issue, a design decision rather than a bug I think. There are many explicit modprobes for modules used in here, for example

    http://repo.or.cz/w/tomato.git/blob...699616:/release/src/router/rc/firewall.c#l549

    IIRC it is possible to build the kernel in a way which allows modules to autoload, depmod and system.map are related, but Tomato seems happy to do it manually at runtime. This does lead to apparently inconsistent behaviour - because things works as long as something has loaded the module.

    When messing with xt_string it was clear the iptables function had hand carved makefile, had to manually sync with kernel module, guess this allows things to be compiled and mixed/matched later.
     
  60. bunk3m

    bunk3m Networkin' Nut Member

    Thanks @koitsu

    I was able to load the time module and put in the iptable commands. If this works, then I'll have to learn how to write scripts so these rules run every time the router reboots.

    And, I'll have to remember these rules so I can properly delete them as blocking times need to be modified.

    I'll let you know if this works!

    Thanks again.
     
  61. bunk3m

    bunk3m Networkin' Nut Member

    I built some test iptables rules and so far I don't have any error msgs in the log. I'm crossing my fingers that this will work.

    I've added all my rules into the Scripts:Firewall tab.

    I wonder if the reason this didn't work properly from the GUI is because of the modprobe ipt_time not working until I manually added it at the CLI??

    I'll report back later to report on the progress. :)
     
  62. bunk3m

    bunk3m Networkin' Nut Member

    Just reporting back.

    This hasn't worked. I've tried it but nothing is getting blocked. There are no errors but I'm not sure what could be wrong now.

    I did try to add a rule from the GUI to test if the time module wasn't being added. It didn't work either. I did get this error
    Code:
    user.info rcheck[4668]: Activating rule 0
    user.err rcheck[4668]: Iptables: activating chain "rdev00" failed. Retrying in 15 minutes.
    
    The only other thing I can think of is that vlan1 isn't the right thing to put into the iptables command. I see br0, vlan1 and eth1. I need to do some reading on what is actually controlling the wifi to wired network connection. Perhaps I've written the iptables command using the wrong network id.

    One other thing.
    I have a list of "Permit only the following clients" by MAC addresses in Basic: Wireless Filter.

    Could it be that this overrides the Access Restrictions or iptables?
     
  63. bunk3m

    bunk3m Networkin' Nut Member

    Hi.

    I tried with vlan1 and it didn't work. From the attached diagram, I think I know why notl.

    Presently trying eth1 as eth1 looks to be the wireless radio link.

    WRT54_sw2_internal_architecture.png

    eth1 = radio
    br0 = LAN to wireless bridge
    vlan1 = WAN port?
    vlan0 = LAN ports?
    rdev01 = ? (from earlier posts above)

    Given this should I be putting the iptables block on br0?
     
  64. bunk3m

    bunk3m Networkin' Nut Member

    Frustration is reaching a new high.

    The rule with -i eth1 doesn't work. So I decided to force static IPs and try blocking using IP address:
    Code:
    iptables -A FORWARD -s 192.168.2.106 -m time --timestart 19:30 --timestop 21:00 --days Mon,Tue,Wed,Thu,Sun -j DROP
    iptables -A FORWARD -d 192.168.2.106 -m time --timestart 19:30 --timestop 21:00 --days Mon,Tue,Wed,Thu,Sun -j DROP
    
    This feels like using a hammer but none of the iptables rules are actually blocking anything. They show up in the iptables -vnL listing but don't drop connection to the internet.

    What am I doing wrong?

    Result of the above is:
    Code:
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    num  pkts bytes target    prot opt in    out    source              destination      
    ....
    15      0    0 DROP      all  --  *      *      192.168.2.106        0.0.0.0/0          TIME from 19:30 to 21:0 on Sun,Mon,Tue,Wed,Thu
    16      0    0 DROP      all  --  *      *      0.0.0.0/0            192.168.2.106      TIME from 19:30 to 21:0 on Sun,Mon,Tue,Wed,Thu
    
    Is it possible that the "Basic: Wireless Client Filter: Permit Only the Following" is overriding all my iptable rules?
     
    Last edited: Dec 3, 2013
  65. koitsu

    koitsu Network Guru Member

    It doesn't appear to me you're doing anything wrong per se -- it looks more, to me, that your rules are inserted into the wrong area/part of the FORWARD chain.

    Look carefully at my post here: http://www.linksysinfo.org/index.ph...-tomato-nd-1-28-5x-110-vpn.68723/#post-232588

    You'll notice the Access Restrictions rules are part of the custom-created restrict chain (which then subsequently refers to more chains like rdev01 and so on), but the reference to the restrict chain is placed at a very specific location (the 4th rule in this case) -- and needs to be. The number 4 is not magical, and it will probably vary depending on other features/etc. you have enabled and so on. You have to read the rules in linear order, and think "okay, as a packet comes in, it'll hit number 1; if it doesn't match, then it goes on to number 2; if it doesn't match, onto 3, etc..."

    iptables -A appends rules to a chain, i.e. they get appended to the end, and it's very likely one of the preceding rules is responsible for your traffic getting passed/allowed through (i.e. a preceding rule is matching), thus rules 15 and 16 never get hit/used. So you cannot just blindly use iptables -A FORWARD and expect your rules to get used. You'll know if the rules are getting matched based on their packet counters or byte counters.

    I would recommend you simply insert a rule at a specific location (ex. iptables -I 5 FORWARD {rule} to insert at the 5th line in the FORWARD chain) that references a chain you yourself have chosen to create. This is how the Access Restrictions as well as other existing Tomato chains (ex. wanin and wanout) work, and it allows for much cleaner/easier management for yourself.

    An example would be iptables -N testrule to create the new chain called testrule, then insert a reference to that chain using iptables -I 4 FORWARD -j testrule to insert the reference to the testrule chain into the FORWARD chain but at "line 4" / rule #4. Subsequently this allows you to to manipulate rules within the testrule chain as you need using iptables -A testrule {rule} -- no need to screw with FORWARD past that point (or until a reboot). You can even flush (not delete) the entire testrule chain if you need to start over fresh. You can watch packet counters in each appropriate chain and knows what's hitting what.
     
  66. bunk3m

    bunk3m Networkin' Nut Member

    Thanks, I think I'm understanding this much better now.

    Interestingly, I don't have any restrict rules/chain.

    I'll try the testrule idea and put it before the ACCEPT all (rule 5 below) rules. I have a slightly different set of FORWARD rules. You don't have the same number 1. I have my WRT54GL on segment 192.168.2.x, so I believe this is why.
    Code:
    1      421 31996            all  --  *      *      0.0.0.0/0            0.0.0.0/0          account: network/netmask: 192.168.2.0/255.255.255.0 name: lan
    2      421 31996 ACCEPT    all  --  br0    br0    0.0.0.0/0            0.0.0.0/0         
    3        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID
    4        0    0 TCPMSS    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp flags:0x06/0x02 TCPMSS clamp to PMTU
    5        0    0 ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
    6        0    0 wanin      all  --  vlan1  *      0.0.0.0/0            0.0.0.0/0         
    7        0    0 wanout    all  --  *      vlan1  0.0.0.0/0            0.0.0.0/0         
    8        0    0 ACCEPT    all  --  br0    *      0.0.0.0/0            0.0.0.0/0         
    
    I'll let you know how this works.

    Thanks again!
     
  67. bunk3m

    bunk3m Networkin' Nut Member

    My testrules doesn't seem to be working. I tried to block my tablet using MAC address but I'm still able to surf the web.

    Here is my /etc/iptables again:
    Code:
    cat /etc/iptables
    *mangle
    :PREROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    COMMIT
    *nat
    :PREROUTING ACCEPT [0:0]
    :POSTROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    :WANPREROUTING - [0:0]
    -A PREROUTING -i vlan1 -d 192.168.2.2/255.255.255.0 -j DROP
    -A POSTROUTING  -o vlan1 -j MASQUERADE
    -A POSTROUTING -o br0 -s 192.168.2.2/255.255.255.0 -d 192.168.2.2/255.255.255.0 -j SNAT --to-source 192.168.2.2
    COMMIT
    *filter
    :INPUT DROP [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -m state --state INVALID -j DROP
    -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
    -N shlimit
    -A shlimit -m recent --set --name shlimit
    -A shlimit -m recent --update --hitcount 4 --seconds 60 --name shlimit -j DROP
    -A INPUT -p tcp --dport 22 -m state --state NEW -j shlimit
    -A INPUT -i lo -j ACCEPT
    -A INPUT -i br0 -j ACCEPT
    :FORWARD DROP [0:0]
    -A FORWARD -m account --aaddr 192.168.2.0/255.255.255.0 --aname lan
    -A FORWARD -i br0 -o br0 -j ACCEPT
    -A FORWARD -m state --state INVALID -j DROP
    -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
    :wanin - [0:0]
    :wanout - [0:0]
    -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i vlan1 -j wanin
    -A FORWARD -o vlan1 -j wanout
    -A FORWARD -i br0 -j ACCEPT
    COMMIT
    
    You will see that none of my testrules are included. I assumed they should be??

    Here is my present iptables -L -n -v --line-numbers
    Code:
    iptables -L -n -v --line-numbers
    Chain INPUT (policy DROP 0 packets, 0 bytes)
    num  pkts bytes target    prot opt in    out    source              destination       
    1        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID
    2      276 31002 ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
    3        0    0 shlimit    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp dpt:22 state NEW
    4        0    0 ACCEPT    all  --  lo    *      0.0.0.0/0            0.0.0.0/0         
    5      14  2362 ACCEPT    all  --  br0    *      0.0.0.0/0            0.0.0.0/0         
    
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    num  pkts bytes target    prot opt in    out    source              destination       
    1        0    0            all  --  *      *      0.0.0.0/0            0.0.0.0/0          account: network/netmask: 192.168.2.0/255.255.255.0 name: lan
    2        0    0 ACCEPT    all  --  br0    br0    0.0.0.0/0            0.0.0.0/0         
    3        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          state INVALID
    4        0    0 TCPMSS    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0          tcp flags:0x06/0x02 TCPMSS clamp to PMTU
    5        0    0 testrules  all  --  *      *      0.0.0.0/0            0.0.0.0/0         
    6        0    0 ACCEPT    all  --  *      *      0.0.0.0/0            0.0.0.0/0          state RELATED,ESTABLISHED
    7        0    0 wanin      all  --  vlan1  *      0.0.0.0/0            0.0.0.0/0         
    8        0    0 wanout    all  --  *      vlan1  0.0.0.0/0            0.0.0.0/0         
    9        0    0 ACCEPT    all  --  br0    *      0.0.0.0/0            0.0.0.0/0         
    
    Chain OUTPUT (policy ACCEPT 20 packets, 3376 bytes)
    num  pkts bytes target    prot opt in    out    source              destination       
    
    Chain shlimit (1 references)
    num  pkts bytes target    prot opt in    out    source              destination       
    1        0    0            all  --  *      *      0.0.0.0/0            0.0.0.0/0          recent: SET name: shlimit side: source
    2        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          recent: UPDATE seconds: 60 hit_count: 4 name: shlimit side: source
    
    Chain testrules (1 references)
    num  pkts bytes target    prot opt in    out    source              destination       
    1        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          MAC AA:BB:CC:DD:EE:FF TIME from 15:30 to 18:30 on Sun,Mon,Tue,Wed,Thu
    2        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          MAC ZZ:YY:XX:WW:VV TIME from 15:30 to 18:30 on Sun,Mon,Tue,Wed,Thu
    3        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          MAC AA:BB:CC:DD:EE:FF TIME from 19:30 to 21:0 on Sun,Mon,Tue,Wed,Thu
    4        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          MAC ZZ:YY:XX:WW:VV TIME from 19:30 to 21:0 on Sun,Mon,Tue,Wed,Thu
    5        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          MAC AA:BB:CC:DD:EE:FF TIME from 22:0 to 7:30 on all days
    6        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          MAC ZZ:YY:XX:WW:VV TIME from 22:0 to 7:30 on all days
    7        0    0 DROP      all  --  *      *      0.0.0.0/0            0.0.0.0/0          MAC LL:MM:NN:OO:PP TIME from 22:0 to 7:30 on all days
    
    Chain wanin (1 references)
    num  pkts bytes target    prot opt in    out    source              destination       
    
    Chain wanout (1 references)
    num  pkts bytes target    prot opt in    out    source              destination  
    Is there something I'm missing?

    Thanks again for leading me by the hand. I appreciate your patients.
     
  68. koitsu

    koitsu Network Guru Member

    Anything you manually enter with the iptables command will not make it into /etc/iptables -- ever. You can modify that file if you want (such as using iptables-save) but upon reboot all your changes will be lost.

    The reason is that /etc is a symlink to /tmp/etc. /tmp is a RAM-based filesystem, hence contents are lost on reboot. The way /tmp gets populated is during boot-up, where data is read out of flash and other places and certain things created there.

    That's why there are so many NVRAM variables for things that "tweak" stuff after-the-fact.

    Once you figure out what the necessary iptables commands are for doing what you need, you add those to your Administration / Scripts / Firewall section. The data written there gets stored in NVRAM variables (for Firewall, the data ends up in NVRAM variable script_fire), which upon boot-up the router reads from + executes as if you were entering the commands via the CLI.

    If this bothers you and you want to treat your flash as a filesystem, i.e. treat it like an actual PC Linux box, then you need to run OpenWRT or some other firmware.
     
  69. bunk3m

    bunk3m Networkin' Nut Member

    Thanks for the explanation. I didn't know that. Not interested in doing OpenWRT. Kind of like Tomato.

    I couldn't get it to work with the testrules.

    As an experiment I tried blocking these IP addresses on our gateway server. I really didn't want to do it this way but I started to wonder why none of these rules work on the WRT54GL. The server puts the rules first in the FORWARD list. Not sure why this happens but it does work.

    Curious .... Is there a problem if I insert my DROP rules as first line of FORWARD?

    If it doesn't work, I'll have to save for an RT-N16.
     
  70. mstombs

    mstombs Network Guru Member

    Only potential problem with using -I to insert rules at top is inefficiency, but you are unlikely to notice that unless maxing out the CPU, certainly no problem just testing.

    But do be aware that the FORWARD table has no effect on packets going to the router itself (for web interface for example), or things that are between PCs on your LAN (switch can handle without Linux kernel noticing). You don't have any traffic being forwarded at all in that example above.
     
  71. bunk3m

    bunk3m Networkin' Nut Member

    Oh you'll love this @koitsu et al!

    I went out and bought an RT-N16 yesterday because I just couldn't waste anymore time trying to figure out how to fix the WRT-54GL to properly block access to the internet within our network.

    Because EasyTomato looked so drop-dead easy to setup, I thought I'd try using that first.

    Well it has exactly the same problems. It won't block the internet and errors out on activating the rules.

    So I used the advanced tab and set various access restriction rules because EasyTomato didn't show my active wireless clients, only the LAN connection to the server/router.

    To test I set to block a device I have access to and was crossing my fingers that it would work properly now that I have other hardware.

    Here is the result:
    Code:
    Dec  7 10:32:20 RT-XXXXXX user.info rcheck[15169]: Activating rule 3
    Dec  7 10:32:20 RT-XXXXXX user.err rcheck[15169]: Iptables: activating chain "rdev03" failed. Retrying in 15 minutes.
    Looks like the WRT-54GL errors using Toastman!

    So there is a bug somewhere. (??) Or perhaps my setup doesn't allow the rules to work?

    I'm scratching my head as to why this doesn't work. I wonder if it is because this is running in Access Point mode and not connected directly to the internet but via our server.
    ie. internet <-> server <-eth1-> wired network (192.168.1.x)
    internet <-> server <-eth2-> <RT-N16> wireless network (192.168.2.x)

    Any suggestions on how to figure this out are greatly appreciated.
     
    Last edited: Dec 8, 2013
  72. Elfew

    Elfew Addicted to LI Member

    Try victek fw latest beta
     
  73. mstombs

    mstombs Network Guru Member

    Then no surprise access control not working, you are not using routing through the router out the WAN port (which incidentally is vlan2 on an RT-N16, not vlan1 on WRT54GL). Wireless on/off at defined times should work.
     
  74. bunk3m

    bunk3m Networkin' Nut Member

    @mstombs If Access Control only works through WAN port then if I enable the WAN port as a LAN port would it work?

    I presume there is a reason why Access Restrictions don't work via wired connection on a LAN port to wifi radio, but the IPTABLES rules that I created were for FORWARD and OUTPUT any (0.0.0.0/0) to specific IP addresses and specific IP addresses to any (0.0.0.0/0). I think these type of rules typically blocks those IP addresses from any connectivity. (??)

    I also tried iptables to block eth1 to vlan0 (WRT-54GL) without success.

    @Elfew I'll try victek's latest beta. Is
    Code:
    tomato-RT-N16-1.28.9013MIPSR2-RAF-V1.2.trx
    of Aug 30, 2013 the right version to test? It looks like there was an announcement of v1.3 but I can't find that version for the RT-N16.
     
  75. bunk3m

    bunk3m Networkin' Nut Member

    @Elfew I've flashed Victek's latest beta ( ) but this has the same problems.

    Error msg:
    Code:
    Dec  8 15:18:32 unknown cron.info crond[7512]: crond: crond (busybox 1.21.1) started, log level 8
    Dec  8 15:18:32 unknown user.info rcheck[7536]: Activating rule 2
    Dec  8 15:18:32 unknown user.err rcheck[7536]: Iptables: activating chain "rdev02" failed. Retrying in 15 minutes.
    I'm beginning to think that @mstombs has called it right.

    However, if you use the router as an access point, it still should block internet access if Access Restriction is set.

    Perhaps I have to run the WAN port as my connection to the server.
     
  76. mstombs

    mstombs Network Guru Member

    The Ethernet ports are joined to the wireless port in a bridge, iptables rules can't touch them, the combined lan bridge br0 is seen by the iptables rules. It is theoretically possible to employ bridge filters and/or segregate the input channels with vlans. I think the option to use wan port as lan does use iptables to join those interfaces.
    You should be able to configure the router as a 'router' not a 'gateway', and make the access rules work without adding nat translation - BUT when I last tried that it didn't work when configured via GUI. probably could work via scripts, but it seems that a lot of core Tomato functionality assumes 'gateway' mode - port forwarding/QOS and even the concept of firewall/wan-up scripts.

    So I have a slave router in similar config as an access point as the OP, it does have default gateway set, so time is correct, and wireless can turn off overnight - but everything else is left to a primary router to handle.
     
  77. bunk3m

    bunk3m Networkin' Nut Member

    Thanks for the explanation, @mstombs .

    I think this kind of functionality should exist in the router. Not sure if it is easy or hard to do or if even possible because of your statement
    .

    Is there a place to post functionality requests/enhancements?
     
  78. koitsu

    koitsu Network Guru Member

    You're looking for ebtables, which is what controls "Ethernet bridging rules". This is hard to explain and I'm not going to try to explain it tersely here. ebtables comes with TomatoUSB (at least Toastman builds). You can find posts on this forum discussing ebtables; I do not use it/cannot help you with it.

    You can say "this kind of functionality should exist in the router" all you like, but what you'd end up with is a router with an insanely high CPU load as the kernel has to look at every single packet coming in/out of the Ethernet switch itself to hosts on its own physical network segments. Switching fabrics (ICs) do not normally work like this, especially in consumer products.

    Routers route packets, e.g. entirely based on IP addresses. Switches forward Ethernet frames/packets, e.g. entirely based on MAC address (unless the switch has layer 3 support, in which case it may be able to do filtering/etc. at a lower level). IP packets = layer 3, Ethernet frames = layer 2. Please Google "OSI layer" for how all this works.

    VLAN'ing on these routers is accomplished via proprietary drivers that interface the kernel (software) with the Broadcom Ethernet switch IC (hardware), so that's how the VLAN stuff is done fast/quickly -- it literally has to be done within the switching IC. Without that, it'd be slow as molasses.

    If this is really the kind of thing you want, then you need to stop using consumer-grade hardware and start buying stuff from Cisco, Juniper, etc. or start complaining at Broadcom and other IC manufacturers to provide the features you want (warning: it will fall on deaf ears).
     

Share This Page