TomatoUSB

this script was working fine on build 114 but after upgrading to 116 the router appears to crash at the first ebtables rule

insmod ebtables 
insmod ebtable_filter 
insmod ebt_ip

ebtables -I INPUT -i tap21 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I OUTPUT -i tap21 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I FORWARD -i tap21 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I INPUT -o tap21 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I OUTPUT -o tap21 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I FORWARD -o tap21 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP

and here is a list of bridges if it's of any use

bridge name    bridge id            STP enabled    interfaces
br0            8000.74d02b40eee0    no             vlan1
                                                   eth1
                                                   eth2
                                                   tap21
br1            8000.76d02b40eee4    no             wl0.2
br2            8000.00ff7e4ab144    no             vlan3
                                                   wl0.1
                                                   tap0

Ah, this looks familiar to me. Trying to block DHCP over the vpn interface.
Shibby may have updated the driver in this verison.
http://linksysinfo.org/index.php?threads/tomato-raf-with-included-bittorrent-client-beta-testing.33858/page-27#post-240070
If so, I suspect that may be running things afoul.

If you don't get any other responses here, you may want to ask in his thread that I linked.

I'm experiencing this same problem.

I've upgraded my Asus RT-N16 last week to the RT-AC66U. Coincidently also around the time v116 of the Shibby mod got released.
My router kept rebooting and rebooting, so it seamed. I thought it was bricked until I was able to clear the nvram.

After some tinkering it was indeed this DHCP filter script which uses ebtables that causes the issue.

Lance.. how do you figure a driver update causes the ebtable call to crash the router?

It's only a guess. PM shibby and/or create a thread at linksysinfo.org. He will see it for sure there, developers don't frequent here much.

I shall make a bug post at Shibby's site. I'm quite sure he checks it regularly.

I've been diving in the ebtables a bit and it seems the mentioned script is somewhat wrong and it could be optimized. (depending on the situation).

For instance, you have to know which tap interface to block the DHCP requests from. Which is fine of course if this is a static situation (of which I'm totally unsure!)
Are we truely sure which tap interfaces OpenVPN makes? I know there are normally defined in a config file, but we have no real userfriendly way of doing this in Tomato.
However, if you would be sure to block all the DHCP traffic for ALL tap interfaces, one would use "ebtables ..bla bla .. -i/o tap+ ..bla bla", effectively replacing the interface number with a wildcard.

The faults are quite simple.
There is a ebtables OUTPUT rule for the input interface, and vise versa.
ebtables will warn you about it and will ignore these rules.

This is what I made of it. Feel free to critisize.

insmod ebtables 
insmod ebtable_filter 
insmod ebt_ip

ebtables -I INPUT -i tap+ -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I FORWARD -i tap+ -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I OUTPUT -o tap+ -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -I FORWARD -o tap+ -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP