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

Need Help to solve Dissappearing Access Restrictions

Discussion in 'Tomato Firmware' started by Sean Rhodes, Sep 8, 2014.

  1. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    I cannot figure this one out since there is nothing in the syslog and it only affects the access restrictions, and has been occurring since Shibby build 108.

    Scenario:
    • I manually add rules in the gui, then save.
    • I check the rules and they all appear to be saved correctly
    • When I next check my router the rules have disappeared from the gui
    • when I ssh into the router and take a look, they are gone
    Code:
    root@Tomato:/tmp/home/root# 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=
    rrule2=
    rrule3=
    rrule4=
    rrule5=
    rruleN=1
    rrules_activated=0
    rrules_radio=-1
    rrulewp=80,8080
    
    It's so bad that I actually have a script that inserts them again (assuming they actually work)
    Code:
    #!/bin/sh
    
    nvram unset rrule1
    nvram unset rrule2
    nvram unset rrule3
    nvram unset rrule4
    nvram unset rrule5
    nvram set rrule1="1|-1|-1|127|xx:xx:xx:xx:xx:xx>10.0.1.241||minecraft.net$   riotgames.com$   leagueoflegends.com$   movies.apple.com   trailers.apple.com   doubleclick.net$   creeperrepo.net$   creeperhost.net$   skype.com$   youtube.com$  www-cdn.jtvnw.net$  secure.logmein.com$  bibi.hamachi.cc$|0|Site Blocking"
    nvram set rrule2="1|1260|960|31|xx:xx:xx:xx:xx:xx|||0|Evan Rule 1"
    nvram set rrule3="1|1425|840|96|xx:xx:xx:xx:xx:xx|||0|Evan Rule 2"
    nvram set rrule4="0|-1|-1|127|xx:xx:xx:xx:xx:xx|||0|Wifi"
    nvram set rrule5="1|1260|240|127||-2<a<<0<skypeout<2<10.0.1.241||0|Skype Block"
    ifconfig eth1 down
    ifconfig eth2 down
    sleep 3
    ifconfig eth1 up
    ifconfig eth2 up
    
    Is there any way I can troubleshoot to find out when and why they just disappear?

    Thanks
     
  2. Monk E. Boy

    Monk E. Boy Network Guru Member

    Have you tried using a different web browser to "save" the rules?

    I know Tomato has had issues in the past with Chrome and certain pages, and it's possible the problem has cropped up again, possibly with other browsers.
     
  3. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Thanks,

    I will try that, but if I'm directly entering the rules via ssh and a script I would have thought that the browser type would not make any difference.
     
  4. mstombs

    mstombs Network Guru Member

    Your script doesn't have a 'nvram commit', so rules exist only in ram, and if router reboots before something else commits to flash they will be lost.

    Writing to flash often is not recommended so Tomato includes an option in Administration->Debugging to "Avoid performing an NVRAM commit" - do you have this checked?
     
    koitsu likes this.
  5. shibby20

    shibby20 Network Guru Member

    1) run command "nvram commit" after set any variable of nvram.
    2) check you NVRAM space. Maybe you don`t have free space in nvram.
     
    koitsu likes this.
  6. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Thanks Guys.
    I was purposely not adding "nvram commit", since we try to avoid that and I assume that the gui doesn't perform nvram commit when the rules are saved in it.

    Is there a command to see how much free mem there is?
     
  7. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Found it!
    Code:
    nvram show |grep entries
    1315 entries, 40300 bytes used, 21140 byes free
     
  8. koitsu

    koitsu Network Guru Member

    GUI does in fact use nvram commit. nvram set just allows you to "adjust values in NVRAM" but the values are not actually written (permanently) to NVRAM until nvram commit is issued.

    There's a general methodology/guideline to using NVRAM: when making lots of changes (i.e. you know you're going to be changing lots of things in NVRAM, not just one single variable), you want to "queue up" all of those changes and finally commit them (write them to NVRAM permanently) in one swoop. You do not want to do nvram commit for every change.

    Rephrased with actual lines:

    Good:

    Code:
    nvram set foo=bar
    nvram set something=else
    nvram set i=likerice
    nvram set interface=snakes
    nvram commit
    
    Bad:

    Code:
    nvram set foo=bar
    nvram commit
    nvram set something=else
    nvram commit
    nvram set i=likerice
    nvram commit
    nvram set interface=snakes
    nvram commit
    
    In cases where you're only adjusting one variable (like manually from the command-line, etc.) and that's truly all you plan on doing, a single set+commit is perfectly fine. The point here is that you don't want to "wear out" NVRAM by doing excessive numbers of commits -- instead you should try to queue up as many sets as you can before doing the commit.
     
  9. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Thanks Koistu, I try to avoid doing commits if possible. If this issue continues, I think I will try to add them into my wanup script that's called by my mount.autorun
     
  10. koitsu

    koitsu Network Guru Member

    That would be acceptable/work fine. Just be aware that there will be a window where the rules wouldn't be in effect (the window where the network and firewall layer has loaded + Internet link is up, but disks/filesystems have not been mounted yet -- sometimes this can take up to 30 seconds on TomatoUSB).
     
  11. mstombs

    mstombs Network Guru Member

    Note that just adding rules to nvram vars will not immediately make them active. Some code must read them and act. There is a 15 minute scheduled task to change active rules, but maybe 'service firewall restart' would be needed after manually insertions?
     
  12. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Would the iptables --list show when they are active?
     
  13. koitsu

    koitsu Network Guru Member

    Yup, iptables -L -n -v would show them. Access Restriction rules get their own chain names (something like rchainXX or rruleXX or something like that -- you'll see them, trust me).

    Like @mstombs I also cannot remember what the exact necessary step is to get the underlying code to re-read the NVRAM variables + recreate /etc/iptables for Access Rules recreation. I'd (or better yet, you!) need to look at the TomatoUSB source code to figure that out; start with the Access Restriction GUI, particularly when clicking Save, and work your way back through the code.
     
  14. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Thanks guys.

    It looks like this works:
    Code:
    #!/bin/sh
    
    nvram unset rrule1
    nvram unset rrule2
    nvram unset rrule3
    nvram unset rrule4
    nvram unset rrule5
    nvram set rrule1="1|-1|-1|127|34:23:87:5E:71:95>20:64:32:15:43:50>10.0.1.130||minecraft.net$   riotgames.com$   leagueoflegends.com$   movies.apple.com   trailers.apple.com   doubleclick.net$   creeperrepo.net$   creeperhost.net$   skype.com$   youtube.com$  www-cdn.jtvnw.net$  secure.logmein.com$  bibi.hamachi.cc$|0|Site Blocking"
    nvram set rrule2="1|1260|960|31|34:23:87:5E:71:95|||0|Rule 1"
    nvram set rrule3="1|1425|840|96|34:23:87:5E:71:95|||0|Rule 2"
    nvram set rrule4="0|-1|-1|127|34:23:87:5E:71:95|||0|Wifi"
    nvram set rrule5="1|1260|240|127||-2<a<<0<skypeout<2<10.0.1.130||0|Skype Block"
    nvram commit
    sleep 3
    service firewall restart
    I can see the rules in place at least:
    Code:
    root@Tomato:/tmp/home/root# iptables -L -n -v
    Chain INPUT (policy DROP 6 packets, 900 bytes)
    pkts bytes target     prot opt in     out     source               destination       
       17  1206 restrict   udp  --  !lo    *       0.0.0.0/0            0.0.0.0/0           udp dpt:53
        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
       73 18360 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
        0     0 shlimit    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state NEW
        0     0 shlimit    tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:2222 state NEW
        0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0         
       40  5094 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0         
        1   329 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8088
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:2222
    
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts bytes target     prot opt in     out     source               destination       
      107  8131            all  --  *      *       0.0.0.0/0            0.0.0.0/0           account: network/netmask: 10.0.1.0/255.255.255.0 name: lan
        0     0 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
       10   600 TCPMSS     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
       61  4320 restrict   all  --  *      vlan2   0.0.0.0/0            0.0.0.0/0         
       46  3811 L7in       all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0         
       61  4320 monitor    all  --  *      vlan2   0.0.0.0/0            0.0.0.0/0         
      101  7755 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
        0     0 wanin      all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0         
        6   376 wanout     all  --  *      vlan2   0.0.0.0/0            0.0.0.0/0         
        6   376 ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0         
        0     0 upnp       all  --  vlan2  *       0.0.0.0/0            0.0.0.0/0         
    
    Chain OUTPUT (policy ACCEPT 115 packets, 71009 bytes)
    pkts bytes target     prot opt in     out     source               destination       
    
    Chain L7in (1 references)
    pkts bytes target     prot opt in     out     source               destination       
        0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           LAYER7 l7proto skypeout
    
    Chain monitor (1 references)
    pkts bytes target     prot opt in     out     source               destination       
        0     0 RETURN     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           WEBMON --max_domains 2000 --max_searches 2000
    
    Chain rdev01 (1 references)
    pkts bytes target     prot opt in     out     source               destination       
        0     0 rres01     all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto] MAC 34:23:87:5E:71:95
        0     0 rres01     all  --  *      *       0.0.0.0/0            0.0.0.0/0           [goto] MAC 20:64:32:15:43:50
        0     0 rres01     all  --  *      *       10.0.1.130           0.0.0.0/0           [goto]
    
    Chain rdev02 (0 references)
    pkts bytes target     prot opt in     out     source               destination       
        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MAC 34:23:87:5E:71:95
    
    Chain rdev03 (0 references)
    pkts bytes target     prot opt in     out     source               destination       
        0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MAC 34:23:87:5E:71:95
    
    Chain restrict (2 references)
    pkts bytes target     prot opt in     out     source               destination       
       78  5526 rdev01     all  --  *      *       0.0.0.0/0            0.0.0.0/0         
       78  5526 rres05     all  --  *      *       0.0.0.0/0            0.0.0.0/0         
    
    Chain rres01 (3 references)
    pkts bytes target     prot opt in     out     source               destination       
        0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           web --hore "minecraft.net$ riotgames.com$ leagueoflegends.com$ movies.apple.com trailers.apple.com doubleclick.net$ creeperrepo.net$ creeperhost.net$ skype.com$ youtube.com$ www-cdn.jtvnw.net$ secure.logmein.com$ bibi.hamachi.cc$" reject-with tcp-reset
    
    Chain rres05 (1 references)
    pkts bytes target     prot opt in     out     source               destination       
        0     0 DROP       all  --  *      *       10.0.1.130           0.0.0.0/0           LAYER7 l7proto skypeout
    
    Chain shlimit (2 references)
    pkts bytes target     prot opt in     out     source               destination       
        0     0            all  --  *      *       0.0.0.0/0            0.0.0.0/0           recent: SET name: shlimit side: source
        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 upnp (1 references)
    pkts bytes target     prot opt in     out     source               destination       
    
    Chain wanin (1 references)
    pkts bytes target     prot opt in     out     source               destination       
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.40           tcp dpt:22
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.60           tcp dpt:22
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.30           tcp dpt:5905
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            10.0.1.30           udp dpt:5905
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.4            tcp dpt:5005
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            10.0.1.4            udp dpt:5005
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.4            tcp dpt:5001
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.4            tcp dpt:5000
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.4            tcp dpt:80
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            10.0.1.4            udp dpt:80
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.4            tcp dpt:22
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.4            tcp dpt:8800
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.4            tcp dpt:6690
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.4            tcp dpt:7000
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.4            tcp dpt:9007
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.70           tcp multiport dports 5806,5906
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.70           tcp dpt:3283
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.70           tcp dpt:5900
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.20           tcp multiport dports 21,22
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.50           tcp dpt:443
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.20           tcp dpt:9091
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.50           tcp dpt:8080
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.40           tcp dpt:8085
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.198          tcp multiport dports 5802,5902
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.173          tcp multiport dports 5812,5912
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.5            tcp dpt:9100
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.30           tcp multiport dports 5808,5908
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.2            tcp dpt:22
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.2            tcp dpt:80
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.20           tcp dpt:80
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            10.0.1.20           udp dpt:80
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.20           tcp dpt:443
        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            10.0.1.20           udp dpt:443
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.100          tcp multiport dports 5807,5907
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.2            tcp dpt:8089
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.80           tcp dpt:3283
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.80           tcp dpt:5900
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.80           tcp multiport dports 5809,5909
        0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.0.1.80           tcp dpt:22
    
    Chain wanout (1 references)
    pkts bytes target     prot opt in     out     source               destination       
    root@Tomato:/tmp/home/root# 
     
  15. koitsu

    koitsu Network Guru Member

    Ah there they are, rdevXX, rresXX, and restrict. (restrict references the former two, and FORWARD references restrict)

    One thing: your wanin chain has multiple entries (and with different destinations) for TCP/UDP port 80. Not sure what's going on there, but you may want to review your rules.

    If you need me to look to see what the actual TomatoUSB code does when you click "Save" in the GUI when adding/changing/removing an Access Restriction, I can do so, you just need to ask me.
     
  16. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Thanks Koitsu, I would appreciate you looking into the access restriction saving. I actually saved them and committed them to nvram earlier today, but on writing this post, I checked and they are no longer there, evan after a nvram commit, so something is definately going on.

    I also see some local master contentions in the syslog from the WD NAS if that's of relevance:
    Code:
    Sep 14 00:20:33 Tomato daemon.err nmbd[1076]: process_local_master_announce: Server NFS at IP 10.0.1.50 is announcing itself as a local master browser for workgroup WORKGROUP and we think we are master. Forcing election.
    Sep 14 00:20:33 Tomato daemon.err nmbd[1076]: Samba name server TOMATO has stopped being a local master browser for workgroup WORKGROUP on subnet 10.0.1.1
    Sep 14 00:20:52 Tomato daemon.err nmbd[1076]: Samba name server TOMATO is now a local master browser for workgroup WORKGROUP on subnet 10.0.1.1
    I don't know if there is any relevance to it, but sometimes I will check them from windows using firefox, os x using safari, or from an ipad (just wondering if a browser could be doing something crazy on exit) as well as via ssh.

    As for the port 80's, I have a WD NAS, A synology NAS, OpenELEC on an old atv, all with different external ports, but forwarded to port 80 for their gui's, in addition to the router gui and an old WRT54 in bridge mode, so I can access them externally. If you can think of any improvements on this, I'm definately open to suggestions.
     
    Last edited: Sep 14, 2014
  17. koitsu

    koitsu Network Guru Member

    The nmbd messages you're seeing pertain to Samba -- more specifically, SMB and browser elections (browser is not referring to a web browser).

    This is completely unrelated to Access Restrictions / this subject. Access Restrictions do not have anything to do with this. TCP port 80 also has nothing to do with this.

    If you have two SMB/CIFS servers on your LAN (and it sounds like you do: Samba on your router (NetBIOS name "TOMATO"), and whatever the SMB/CIFS server called "NFS" is (and I don't know why it's named that -- SMB/CIFS is not related to the NFS protocol! How confusing!)), then they are going to fight over who is the master browser (here's a better resource). Windows sharing/SMB is an extremely complex thing.

    There are ways to deal with this by configuring Samba a certain way (this guy ran into something similar) / with certain settings (so assuming TomatoUSB lets you adjust the smb.conf in the GUI, you could do it there -- otherwise you'll need your mount.autorun script to adjust settings manually, which is gonna be a pain because smb.conf is "sectionalised"), but gut feeling the "NFS" device probably will not let you fine-tune things (vendor black-box products often don't allow this), but you might be able to get TomatoUSB to shut up about it.

    Anyway, like I said in my 2nd paragraph: this is completely unrelated to Access Restrictions or TCP port 80. This is a completely separate/different "problem" (and it's not really a problem from what the logs show).

    P.S. -- In your script, you do not need nvram unset. You should just be able to say nvram set and override whatever the previous value is. Proof:
    Code:
    root@gw:/tmp/home/root# nvram set foo=bar
    root@gw:/tmp/home/root# nvram get foo
    bar
    root@gw:/tmp/home/root# nvram set foo=snakes
    root@gw:/tmp/home/root# nvram get foo
    snakes
    
    So literally you just need your nvram set followed by nvram commit. This is not the cause of your NVRAM variables getting erased/lost, however. I have a gut feeling I know what's going on there and it's due to how you've configured them, but it'd be a lot easier if I could just see a screenshot of one of them in the GUI pre-configured.

    P.P.S -- Your shell script parts need to use single-quotes (apostrophes) around the values you're passing the nvram set, not double-quotes. You're using $ in some of your Access Restriction strings, which the shell may be trying to interpret as variables (that happens when using double-quotes, but not single). No idea if the shell is doing that, but it's still a good safety net. So for example:

    Code:
    nvram set rrule1="1|-1|-1|127|34:23:87:5E:71:95>20:64:32:15:43:50>10.0.1.130||minecraft.net$   riotgames.com$   leagueoflegends.com$   movies.apple.com   trailers.apple.com   doubleclick.net$   creeperrepo.net$   creeperhost.net$   skype.com$   youtube.com$  www-cdn.jtvnw.net$  secure.logmein.com$  bibi.hamachi.cc$|0|Site Blocking"
    
    Needs to become:

    Code:
    nvram set rrule1='1|-1|-1|127|34:23:87:5E:71:95>20:64:32:15:43:50>10.0.1.130||minecraft.net$   riotgames.com$   leagueoflegends.com$   movies.apple.com   trailers.apple.com   doubleclick.net$   creeperrepo.net$   creeperhost.net$   skype.com$   youtube.com$  www-cdn.jtvnw.net$  secure.logmein.com$  bibi.hamachi.cc$|0|Site Blocking'
    
    And I would suggest doing the same for the other lines as well.
     
    Last edited: Sep 14, 2014
  18. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Thanks Koitsu, I took your advisement and removed the unsets an changed to single quotes in my script and everything loaded fine.

    As an fyi, here is the rule in the gui with the $ signs:
    Access RestrictCapture.png
     
  19. koitsu

    koitsu Network Guru Member

    For what it's worth: I'm trying to reproduce this (specifically the NVRAM rrulesX variables becoming empty / reverting back to factory defaults). I will report back in 24-48 hours with the results. I am using your literal/exact Access Restrictions rules (I literally copy-pasted the nvram set commands in, went into the GUI and chose Save, and am letting things sit).

    I have reviewed Toastman RT-N code (which is not the version of firmware you're using but it's the one I have more familiarity with), specifically everything under release/src/router, looking for any calls to nvram_unset() which do not refer to a literal string (ex. nvram_unset("foo")), to see if any might have bugs that affect the rrulesX variables. I have found absolutely no bugs in regards to these variables (in fact some of the code I did find is even commented out or #if 0'd completely).

    rcheck, the program which is what parses the rrulesX entries (amongst other things), does not call nvram_unset() ANYWHERE in its code. Meaning: rcheck is not deleting anything from NVRAM. Therefore, whatever is doing this is not being caused by rcheck. It is either somewhere else in the TomatoUSB code, you have some kind of shell script that is doing something very wrong/broken (such as somehow restoring to factory defaults periodically), someone is screwing with you, or you have a router that is malfunctioning in an extremely uncomfortable way (rebooting (such as a crash, etc.) would not cause this -- note very carefully: you are not losing the contents of all NVRAM, because rrule0 (the stock default rule) is still in place -- if NVRAM was being lost/jacked up, that rule probably would be gone)).

    My gut feeling, given what I have seen from you in the past, is that you have a shell script or something else going on that is causing this for you. But that's purely 100% speculative on my part, zero evidence to back it up.

    Regarding how to properly load these rules: service firewall restart is overkill (that does a lot more than what's needed here). Instead, this should be sufficient (I THINK -- I'm not 100% sure, but rcheck does add/modify/maintain tons of iptables rules):

    Code:
    rcheck
    
    Now you need to be aware of something. You are trumping very many things that TomatoUSB does itself under the hood and may be causing yourself greater problems by doing this. For example, calling rcheck manually does a bunch of things -- including adding a cronjob to the system (cru a rcheck '*/15 * * * * rcheck --cron). By you not using the GUI and instead doing everything by hand, you may be creating situations where TomatoUSB does not behave how you would think it does, simply because you aren't doing everything that it would be doing normally via the GUI.

    You should only be calling that one time when the router boots. Once and once alone. Subsequent calls might add multiple cronjobs for the same thing -- I don't know for sure -- but I do see places where, for example, the NTP client in TomatoUSB calls eval("rcheck"); in certain situations.

    The Access Restrictions code is both "simple" and "complex", mainly because of all the NVRAM variables it goes querying and refers to -- and almost none of this code is commented.

    One thing I should note: NVRAM defaults for TomatoUSB Access Restrictions are hard-coded. They are in release/src/router/nvram/defaults.c as these:

    rruleN=0
    rrule0=0|1320|300|31|||word text\n^begins-with.domain.\n.ends-with.net$\n^www.exact-d omain.net$|0|example (the "\n"s are turned into actual newlines, just not here on the forum)
    rrulewp=80,8080

    That's it. Note that rruleN gets set to 0. When your system rules "disappear" -- see your first post -- rruleN is still 1.

    I have yet to figure out what exact piece of code is changing the rruleN NVRAM variable. I believe it is modified, somehow (this is where the code becomes ridiculously/insanely complex and convoluted, due to all the Javascript involved) indirectly through the restrict.asp web GUI portion, but I'm not entirely sure of that.

    I think I've made myself clear repeatedly now that when I say "I'm not entirely sure" or "I'm not 100% certain", it should give you some idea of how complex and rat's nest the TomatoUSB code is, all greatly lacking comments. I am having to skim (and sometimes fully read) code and make educated guesses.

    In general the way this whole Access Restrictions thing is done/is managed is a disgrace. I wouldn't have done it this way at all -- but then again, I also don't write Javascript or do UIs like this, I mainly do the server-side stuff. I probably would have used at jobs, rather than cronjobs, because with at jobs you don't say "run something at X interval", you say "run something at hour/minute X:Y".

    If you are out of ideas and aren't sure where to turn, then it's very simple: reset your router to factory defaults (full NVRAM erase through the GUI), let it reboot, and then write down all the things you change in the GUI (type then in, write them down, whatever) and make only minimal changes. Do not mount Entware or anything else. Then set the Access Restrictions like you would (THROUGH THE GUI PLEASE), then wait 24-48 hours and see if your problem recurs. If it doesn't, then you know it's something you're doing after-the-fact somewhere/somehow that's tickling a bug or something else. It's all about narrowing down exactly what is doing this.

    This is exactly why KISS principle wins out every time and why I like minimal router setups/configurations / why I avoid topics involving people throwing tons of softwwre on their routers and scripts and all sorts of nonsense. The more complex an environment you have, the more problematic debugging and troubleshooting is. People for some reason always think they can just keep throwing crap onto stuff and "it'll all just work" -- but people like myself assume out of the box that something is broken/won't work/will misbehave. I avoid features like the plague. This is also why I like Toastman's firmware -- he wants to change and add as few things as possible, because the original author of the firmware, who wrote all this code, is alive-yet-MIA and provides no support. So we're on our own.
     
  20. koitsu

    koitsu Network Guru Member

    I put the rules into place yesterday at about 0930 Pacific. It's now 2045 Pacific the following day, so that's about 35 hours later. Results:

    Code:
    root@gw:/tmp/home/root# nvram show | grep rrule
    rrule0=0|1320|300|31|||word text  ^begins-with.domain.  .ends-with.net$  ^www.exact-domain.net$|0|example
    rrule1=1|-1|-1|127|34:23:87:5E:71:95>20:64:32:15:43:50>10.0.1.130||minecraft.net$ riotgames.com$|0|Site Blocking
    rrule2=1|1260|960|31|34:23:87:5E:71:95|||0|Rule 1
    rrule3=1|1425|840|96|34:23:87:5E:71:95|||0|Rule 2
    rrule4=0|-1|-1|127|34:23:87:5E:71:95|||0|Wifi
    rrule5=1|1260|240|127||-2<a<<0<skypeout<2<10.0.1.130||0|Skype Block
    rruleN=0
    rrules_activated=2
    rrules_radio=-1
    rrulewp=80,8080
    
    root@gw:/tmp/home/root# cru l
    30 10,12,14,16,18,20,22,0,2,4,6,8 * * * ntpsync --cron #ntpsync#
    46 12 17 9 * ddns-update 0 force #ddnsf0#
    */15 * * * * rcheck --cron #rcheck#
    
    Everything's still in place -- no rule removal. GUI reflects what's in NVRAM as well (as it should). So at least on Toastman RT-N, specifically tomato-K26USB-NVRAM64K-1.28.0506.3MIPSR2Toastman-RT-N-Ext.trx on an RT-N66U, I can't reproduce this.

    Not sure what else to tell you.

    One thing you could try setting would be under Administration / Logging, checking the Access Restriction and Cron checkboxes. Your log (or /var/log/messages on the system, which rotates by default when it hits 40KBytes, so you may find messages also in /var/log/messages.0 -- all depends on the settings you have there) will show lines like this:

    Code:
    Sep 15 10:00:01 gw cron.info crond[10603]: crond: USER root pid 11172 cmd rcheck --cron
    
    This is the periodic cron check that runs every 15 minutes saying "okay, what do I do with the access restriction rules? Do I enable/disable something?" (not REMOVE a rule, but enable/disable it, i.e. put iptables stuff into place, remove those iptables rules, etc.).

    You might also see lines like this:

    Code:
    Sep 15 21:00:01 gw user.info rcheck[11410]: Activating rule 2
    Sep 15 21:00:01 gw user.info rcheck[11410]: Activating rule 5
    
    This informs you that the rcheck binary (and code) is actually doing what a rule says to do, e.g. putting iptables rules into place. The rule numbers correlate with the X in the rruleX number, I think (or they might be offset by 1).

    Code:
    Sep 16 04:00:01 gw user.info rcheck[11546]: Deactivating rule 5
    Sep 16 16:00:01 gw user.info rcheck[11782]: Deactivating rule 2
    
    Same, but for deactivation of rules, e.g. removing the relevant iptables chain reference, removing an iptables rule, etc.. The NVRAM variables don't get modified here (well, okay, rrules_activated might change, I forget, but rruleX will not).

    But that's about as much debugging as you'll get out of it. It's not good, I know. Like I said, welcome to the beast.

    But in the above case/examples, you can clearly see that a couple rules became active at 2100 that night, then the following day at 0400 and 1600 respectively got disabled. The NVRAM vars still exist. So in about 5 minutes or so (it's almost 2100 here), rule 2 and 5 should become active again, etc...

    The activation/deactivation of rules, in case I wasn't clear, is done by that cron job running rcheck --cron every 15 minutes.

    P.S. -- The spacing mistakes/etc. in rrule0 (the host/regexs) are due to my copy-pasting from the forum and so on. This doesn't matter though -- what we're focused on is why entire NVRAM variable contents are disappearing.
     
    Last edited: Sep 17, 2014
  21. Sean Rhodes

    Sean Rhodes Networkin' Nut Member

    Thanks Koitsu, I'm down in Sacramento on business at the moment but I will definitely follow your advice and start with a clean slate, no port forwards or anything enabled for a couple of days then do changes one at a time and wait 24 ours in between. If nothing then I will enable entware without any scripts and finally the scripts one at a time. Hopefully I can find a something quickly. If nothing turns up then I will look at the cron jobs
     

Share This Page