[Solved] Block OpenVPN DHCP in NVRAM v24 and later..

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware
Author Message
AaronDrabeck
DD-WRT Novice


Joined: 08 Jun 2009
Posts: 6

PostPosted: Mon Jun 08, 2009 16:30    Post subject: [Solved] Block OpenVPN DHCP in NVRAM v24 and later.. Reply with quote
Hello,

I have been trying to use the following startup script to block DHCP over my router to router VPN but it is failing to run at boot. Oddly, I can telnet in and paste the code and it works perfectly. All commands execute and a 'ebtables -L' list the exceptions. However, when I go to put the code in startup commands section (nvram), at some point it fails. I think it is creating the /tmp/ebt_ip.o.gz.u64 just fine, but failing on the insmod commands.

I have tried to add lengthy sleep commands, save the insmod in the firewall section, create a custom script...but nothing works. Maybe it is a permission issue?

Does anyone have any insight on why this is failing?

Code:
echo "begin-base64 644 -" > /tmp/ebt_ip.o.gz.u64
echo "H4sIADwAAAACA5VWz28bVRD+dteON20KG9eq3BJUB21UVy1m2+RQRCO5cX5w" >> /tmp/ebt_ip.o.gz.u64
echo "yMGHHpAQcr32Eq9wHMveIFAPNSkHDq7wIb1H5R+p0gpx7J8QtaH8EBfuSGbm" >> /tmp/ebt_ip.o.gz.u64
echo "vbdh8whEHelp9ps3883Mm/ecPFhZXzUMA7EYsPEPAv5Ikc1BdUGgIt7CWSQl" >> /tmp/ebt_ip.o.gz.u64
echo "i5ejFJY8B2VntjrAecIFPByyLUM2B4cjA43RGDveN6g4HJMD7CxeH9nvo5KT" >> /tmp/ebt_ip.o.gz.u64
echo "XK9HNva9KsUxPo/fiKvyyMZ7N5hrmrgmVUxHcV0hrmm8OrK3FBfbJmC6FnyK" >> /tmp/ebt_ip.o.gz.u64
echo "M92P4At7AUuPBsRZwHMPWBq+TXUOHBN5DJzZsg8T5uM8DnfHqHi4ZMHMmpjL" >> /tmp/ebt_ip.o.gz.u64
echo "+7hWaCKNQW62CFzCy91rTgUW1VSg2gykXdZpwgae3FpDWeRap9oc6qeCPYH5" >> /tmp/ebt_ip.o.gz.u64
echo "+6LqDZQnd0qeCyqPqWI4D5+vQzXHua6rXBvqTIsqlzzffS9LfiZpORc+y8Oh" >> /tmp/ebt_ip.o.gz.u64
echo "oWYD/Dycgj90nWXqaUXkuE887B/bc1gRfGzL8YwdiBmniIf5TMU1hV+GjohZ" >> /tmp/ebt_ip.o.gz.u64
echo "QwbLgsvGgcX+sd1K2A2aCe/xtzybH76fIdsNmtPv47Rr49muTfh9NbcU9kXd" >> /tmp/ebt_ip.o.gz.u64
echo "V1W/WboLT8lvjIee6wR0ZtLOtbnOipgN4x8pBfN58L0zYl47Xh73HLbpdyR7" >> /tmp/ebt_ip.o.gz.u64
echo "dEd21N1l31e78bwpXtTmqP14RjnyUXMS+2yXve9x5beBi7Q+vGKjQL1+655s" >> /tmp/ebt_ip.o.gz.u64
echo "Oy5hF6fKx+a/bX9l8ARvIO/SuvwfXMn9gvX/+wun7LfDRtDpB4tr1XV8EfQ6" >> /tmp/ebt_ip.o.gz.u64
echo "Qbv2ZdDrh1udxZulhdK8x86l/tebUd0nHfWkbsVfvaBdioKvIvnVrEd1lPx+" >> /tmp/ebt_ip.o.gz.u64
echo "n+FG2Pl8S9q7zR5Km83A394o1f1w/iahrabYfwO5LN4aMKFwmVY10Z96wHiH" >> /tmp/ebt_ip.o.gz.u64
echo "1mQi7hMb4LFNqfiUuOvAVYVjipElOXW+OY3vJwrOKz4rwfeB0jHfC+3sY74F" >> /tmp/ebt_ip.o.gz.u64
echo "2UPXTPjlE37Mx/iOqi+WX8lvoPmxLGr1Hdj8VmR9mUR9qxpfK3W8vnjvrvo2" >> /tmp/ebt_ip.o.gz.u64
echo "E37uCXmnE72y0B8XfHYCX5KLZYaKOiB9TtWdUmczqfHRm8GnJ/DpYhyr7c9x" >> /tmp/ebt_ip.o.gz.u64
echo "cs/SoixYGk5reFLDZzQ8oeGM8OB3mBO/fwb99sh3F+M57Q7Ma3hVvyOBH9XC" >> /tmp/ebt_ip.o.gz.u64
echo "bqmBsBNGNXop2+0AjXZQ72x3Y1irRa2wHyOO4BfXj4JebbMeNVrCtN3RjOLu" >> /tmp/ebt_ip.o.gz.u64
echo "pUx5j1jPGFJ/p/QLpfdMqelHGGm6SEXSE1OyzzQtjzGtW4xpkLcZn5N98/6y" >> /tmp/ebt_ip.o.gz.u64
echo "2i/y7InnutKc31T/qjAuKF1W+p7SfwMbOFhxAAkAAA==" >> /tmp/ebt_ip.o.gz.u64
echo "====" >> /tmp/ebt_ip.o.gz.u64
uudecode /tmp/ebt_ip.o.gz.u64 | gunzip -cd > /tmp/ebt_ip.o


sleep 10
insmod ebtables
sleep 10
insmod ebtable_filter
sleep 10
insmod /tmp/ebt_ip.o
sleep 30
ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP


Thanks in advance for any help!


Last edited by AaronDrabeck on Tue Jun 09, 2009 15:20; edited 1 time in total
Sponsor
Murrkf
DD-WRT Guru


Joined: 22 Sep 2008
Posts: 11196

PostPosted: Mon Jun 08, 2009 17:57    Post subject: Reply with quote
I would not try to troubleshoot with SP1 on the router....see the top two announcements at the top of the forum.
_________________
SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor. So See this:
http://i31.tinypic.com/24mz3ms.png

LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
AaronDrabeck
DD-WRT Novice


Joined: 08 Jun 2009
Posts: 6

PostPosted: Mon Jun 08, 2009 18:28    Post subject: Reply with quote
Murrkf wrote:
I would not try to troubleshoot with SP1 on the router....see the top two announcements at the top of the forum.


Good suggestion, I am now running the 5/8/2009 build of 24-sp2.


My results are the same. ebtables fails to load with nvram but if I drop in

Code:

insmod ebtables
insmod ebtable_filter
insmod /tmp/ebt_ip.o
ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP


into telnet after boot, it works perfectly.

At what point during the boot is startup run? Is there a way to delay it to the end?

I bet there are other insmod commands running after my startup script runs which is negating my efforts and giving me "The kernel doesn't support the ebtables 'filter' table.".
phuzi0n
DD-WRT Guru


Joined: 10 Oct 2006
Posts: 10143

PostPosted: Mon Jun 08, 2009 20:26    Post subject: Reply with quote
It's likely that tap1 doesn't exist yet when the startup script is run. Also, afaik ebtables can get cleared by link state changes too, so the firewall script is where it belongs anyways.
_________________
Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
AaronDrabeck
DD-WRT Novice


Joined: 08 Jun 2009
Posts: 6

PostPosted: Mon Jun 08, 2009 21:57    Post subject: Reply with quote
phuzi0n wrote:
It's likely that tap1 doesn't exist yet when the startup script is run. Also, afaik ebtables can get cleared by link state changes too, so the firewall script is where it belongs anyways.



Okay, I have moved

Code:

sleep 10
insmod ebtables
sleep 10
insmod ebtable_filter
sleep 10
insmod /tmp/ebt_ip.o
sleep 120
ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP

to Firewall.

Leaving
Code:
echo "begin-base64 644 -" > /tmp/ebt_ip.o.gz.u64
echo "H4sIADwAAAACA5VWz28bVRD+dteON20KG9eq3BJUB21UVy1m2+RQRCO5cX5w" >> /tmp/ebt_ip.o.gz.u64
echo "yMGHHpAQcr32Eq9wHMveIFAPNSkHDq7wIb1H5R+p0gpx7J8QtaH8EBfuSGbm" >> /tmp/ebt_ip.o.gz.u64
echo "vbdh8whEHelp9ps3883Mm/ecPFhZXzUMA7EYsPEPAv5Ikc1BdUGgIt7CWSQl" >> /tmp/ebt_ip.o.gz.u64
echo "i5ejFJY8B2VntjrAecIFPByyLUM2B4cjA43RGDveN6g4HJMD7CxeH9nvo5KT" >> /tmp/ebt_ip.o.gz.u64
echo "XK9HNva9KsUxPo/fiKvyyMZ7N5hrmrgmVUxHcV0hrmm8OrK3FBfbJmC6FnyK" >> /tmp/ebt_ip.o.gz.u64
echo "M92P4At7AUuPBsRZwHMPWBq+TXUOHBN5DJzZsg8T5uM8DnfHqHi4ZMHMmpjL" >> /tmp/ebt_ip.o.gz.u64
echo "+7hWaCKNQW62CFzCy91rTgUW1VSg2gykXdZpwgae3FpDWeRap9oc6qeCPYH5" >> /tmp/ebt_ip.o.gz.u64
echo "+6LqDZQnd0qeCyqPqWI4D5+vQzXHua6rXBvqTIsqlzzffS9LfiZpORc+y8Oh" >> /tmp/ebt_ip.o.gz.u64
echo "oWYD/Dycgj90nWXqaUXkuE887B/bc1gRfGzL8YwdiBmniIf5TMU1hV+GjohZ" >> /tmp/ebt_ip.o.gz.u64
echo "QwbLgsvGgcX+sd1K2A2aCe/xtzybH76fIdsNmtPv47Rr49muTfh9NbcU9kXd" >> /tmp/ebt_ip.o.gz.u64
echo "V1W/WboLT8lvjIee6wR0ZtLOtbnOipgN4x8pBfN58L0zYl47Xh73HLbpdyR7" >> /tmp/ebt_ip.o.gz.u64
echo "dEd21N1l31e78bwpXtTmqP14RjnyUXMS+2yXve9x5beBi7Q+vGKjQL1+655s" >> /tmp/ebt_ip.o.gz.u64
echo "Oy5hF6fKx+a/bX9l8ARvIO/SuvwfXMn9gvX/+wun7LfDRtDpB4tr1XV8EfQ6" >> /tmp/ebt_ip.o.gz.u64
echo "Qbv2ZdDrh1udxZulhdK8x86l/tebUd0nHfWkbsVfvaBdioKvIvnVrEd1lPx+" >> /tmp/ebt_ip.o.gz.u64
echo "n+FG2Pl8S9q7zR5Km83A394o1f1w/iahrabYfwO5LN4aMKFwmVY10Z96wHiH" >> /tmp/ebt_ip.o.gz.u64
echo "1mQi7hMb4LFNqfiUuOvAVYVjipElOXW+OY3vJwrOKz4rwfeB0jHfC+3sY74F" >> /tmp/ebt_ip.o.gz.u64
echo "2UPXTPjlE37Mx/iOqi+WX8lvoPmxLGr1Hdj8VmR9mUR9qxpfK3W8vnjvrvo2" >> /tmp/ebt_ip.o.gz.u64
echo "E37uCXmnE72y0B8XfHYCX5KLZYaKOiB9TtWdUmczqfHRm8GnJ/DpYhyr7c9x" >> /tmp/ebt_ip.o.gz.u64
echo "cs/SoixYGk5reFLDZzQ8oeGM8OB3mBO/fwb99sh3F+M57Q7Ma3hVvyOBH9XC" >> /tmp/ebt_ip.o.gz.u64
echo "bqmBsBNGNXop2+0AjXZQ72x3Y1irRa2wHyOO4BfXj4JebbMeNVrCtN3RjOLu" >> /tmp/ebt_ip.o.gz.u64
echo "pUx5j1jPGFJ/p/QLpfdMqelHGGm6SEXSE1OyzzQtjzGtW4xpkLcZn5N98/6y" >> /tmp/ebt_ip.o.gz.u64
echo "2i/y7InnutKc31T/qjAuKF1W+p7SfwMbOFhxAAkAAA==" >> /tmp/ebt_ip.o.gz.u64
echo "====" >> /tmp/ebt_ip.o.gz.u64
uudecode /tmp/ebt_ip.o.gz.u64 | gunzip -cd > /tmp/ebt_ip.o
in the startup.

The ebtables modules now reliably load (a step int he right direction). However, my filter "ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP" still is not working because when I do a ebtables -L it is 0 for all three areas.

I added a sleep 120 to allow tap1 to connect. Also, my open VPN for tap1 is place chronologically before the ebtables section in the startup script.

I know the tap1 is working and in use because my VPN works.

Any suggestions on how I can debug this? Also, could I set a timer of some sort to re initiate my "ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP" statement every x amount of times?
phuzi0n
DD-WRT Guru


Joined: 10 Oct 2006
Posts: 10143

PostPosted: Mon Jun 08, 2009 22:51    Post subject: Reply with quote
I'm curious why you're going through the trouble of using ebtables instead of iptables because this rule would work the same with either. If you were blocking dhcp forwarding then ebtables wold be needed but for input either will do.

It can be tricky getting some things to run when needed, the last resort is always cron. Laughing

_________________
Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
AaronDrabeck
DD-WRT Novice


Joined: 08 Jun 2009
Posts: 6

PostPosted: Tue Jun 09, 2009 0:29    Post subject: Reply with quote
phuzi0n wrote:
I'm curious why you're going through the trouble of using ebtables instead of iptables because this rule would work the same with either. If you were blocking dhcp forwarding then ebtables wold be needed but for input either will do.

It can be tricky getting some things to run when needed, the last resort is always cron. Laughing



I was trying to block DHCP from traveling across the VPN. From what I have read and whats posted in this forum, you must use ebtables because DHCP cannot be blocked with iptables on the VPN bridge.

The how to is here http://dsss.be/w/make_a_dd-wrt_bridge_silently_eat_dhcp_traffic
and the thread in this forum is here http://www.dd-wrt.com/phpBB2/viewtopic.php?t=12372&highlight=ebtables

I have tried to use just iptables with no success. My two remote sites end up getting leases from each other's DHCP via the VPN.
phuzi0n
DD-WRT Guru


Joined: 10 Oct 2006
Posts: 10143

PostPosted: Tue Jun 09, 2009 1:57    Post subject: Reply with quote
Yeah I've seen that tutorial before but it's never made sense why they have an INPUT rule which is only for traffic destined to the MAC address of the router itself. I would expect it to use the FORWARD chain to block bridged traffic but maybe the tunnel has an odd effect with the bridging.
_________________
Read the forum announcements thoroughly! Be cautious if you're inexperienced.
Available for paid consulting. (Don't PM about complicated setups otherwise)
Looking for bricks and spare routers to expand my collection. (not interested in G spec models)
SNR
DD-WRT User


Joined: 27 Apr 2009
Posts: 132

PostPosted: Tue Jun 09, 2009 9:36    Post subject: Reply with quote
AaronDrabeck wrote:

Okay, I have moved

Code:

sleep 10
insmod ebtables
sleep 10
insmod ebtable_filter
sleep 10
insmod /tmp/ebt_ip.o
sleep 120
ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP

to Firewall.

Leaving
Code:
echo "begin-base64 644 -" > /tmp/ebt_ip.o.gz.u64
echo "H4sIADwAAAACA5VWz28bVRD+dteON20KG9eq3BJUB21UVy1m2+RQRCO5cX5w" >> /tmp/ebt_ip.o.gz.u64
[etc.]
echo "====" >> /tmp/ebt_ip.o.gz.u64
uudecode /tmp/ebt_ip.o.gz.u64 | gunzip -cd > /tmp/ebt_ip.o
in the startup.

The ebtables modules now reliably load (a step int he right direction). However, my filter "ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP" still is not working because when I do a ebtables -L it is 0 for all three areas.

I added a sleep 120 to allow tap1 to connect. Also, my open VPN for tap1 is place chronologically before the ebtables section in the startup script.

I know the tap1 is working and in use because my VPN works.

Any suggestions on how I can debug this?

I had a similar timing problem with a simple iptables DELETE here:

http://www.dd-wrt.com/phpBB2/viewtopic.php?p=309061#309061

It turned out in my case that every delay I inserted into my script only delayed initialization of the firewall sequence I was waiting for!

I finally figured out that I had to start a new shell and wait there for the rest of the initialization sequence to finish. In your case it would look something like this I think (trailing ampersand to push the new shell into the background):

Quote:
sleep 120 && ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP &


You can probably reduce the sleep period tenfold after you find that this fixes the problem.
AaronDrabeck
DD-WRT Novice


Joined: 08 Jun 2009
Posts: 6

PostPosted: Tue Jun 09, 2009 15:18    Post subject: [Solved] OpenVPN DHCP block router-to-router VPN Reply with quote
Thanks to everyone who helped! This is a working script to block DHCP traffic over an router-to-router openVPN bridge. You might have to change tap1 part to reflect your interface.

Startup:
Code:
echo "begin-base64 644 -" > /tmp/ebt_ip.o.gz.u64
echo "H4sIADwAAAACA5VWz28bVRD+dteON20KG9eq3BJUB21UVy1m2+RQRCO5cX5w" >> /tmp/ebt_ip.o.gz.u64
echo "yMGHHpAQcr32Eq9wHMveIFAPNSkHDq7wIb1H5R+p0gpx7J8QtaH8EBfuSGbm" >> /tmp/ebt_ip.o.gz.u64
echo "vbdh8whEHelp9ps3883Mm/ecPFhZXzUMA7EYsPEPAv5Ikc1BdUGgIt7CWSQl" >> /tmp/ebt_ip.o.gz.u64
echo "i5ejFJY8B2VntjrAecIFPByyLUM2B4cjA43RGDveN6g4HJMD7CxeH9nvo5KT" >> /tmp/ebt_ip.o.gz.u64
echo "XK9HNva9KsUxPo/fiKvyyMZ7N5hrmrgmVUxHcV0hrmm8OrK3FBfbJmC6FnyK" >> /tmp/ebt_ip.o.gz.u64
echo "M92P4At7AUuPBsRZwHMPWBq+TXUOHBN5DJzZsg8T5uM8DnfHqHi4ZMHMmpjL" >> /tmp/ebt_ip.o.gz.u64
echo "+7hWaCKNQW62CFzCy91rTgUW1VSg2gykXdZpwgae3FpDWeRap9oc6qeCPYH5" >> /tmp/ebt_ip.o.gz.u64
echo "+6LqDZQnd0qeCyqPqWI4D5+vQzXHua6rXBvqTIsqlzzffS9LfiZpORc+y8Oh" >> /tmp/ebt_ip.o.gz.u64
echo "oWYD/Dycgj90nWXqaUXkuE887B/bc1gRfGzL8YwdiBmniIf5TMU1hV+GjohZ" >> /tmp/ebt_ip.o.gz.u64
echo "QwbLgsvGgcX+sd1K2A2aCe/xtzybH76fIdsNmtPv47Rr49muTfh9NbcU9kXd" >> /tmp/ebt_ip.o.gz.u64
echo "V1W/WboLT8lvjIee6wR0ZtLOtbnOipgN4x8pBfN58L0zYl47Xh73HLbpdyR7" >> /tmp/ebt_ip.o.gz.u64
echo "dEd21N1l31e78bwpXtTmqP14RjnyUXMS+2yXve9x5beBi7Q+vGKjQL1+655s" >> /tmp/ebt_ip.o.gz.u64
echo "Oy5hF6fKx+a/bX9l8ARvIO/SuvwfXMn9gvX/+wun7LfDRtDpB4tr1XV8EfQ6" >> /tmp/ebt_ip.o.gz.u64
echo "Qbv2ZdDrh1udxZulhdK8x86l/tebUd0nHfWkbsVfvaBdioKvIvnVrEd1lPx+" >> /tmp/ebt_ip.o.gz.u64
echo "n+FG2Pl8S9q7zR5Km83A394o1f1w/iahrabYfwO5LN4aMKFwmVY10Z96wHiH" >> /tmp/ebt_ip.o.gz.u64
echo "1mQi7hMb4LFNqfiUuOvAVYVjipElOXW+OY3vJwrOKz4rwfeB0jHfC+3sY74F" >> /tmp/ebt_ip.o.gz.u64
echo "2UPXTPjlE37Mx/iOqi+WX8lvoPmxLGr1Hdj8VmR9mUR9qxpfK3W8vnjvrvo2" >> /tmp/ebt_ip.o.gz.u64
echo "E37uCXmnE72y0B8XfHYCX5KLZYaKOiB9TtWdUmczqfHRm8GnJ/DpYhyr7c9x" >> /tmp/ebt_ip.o.gz.u64
echo "cs/SoixYGk5reFLDZzQ8oeGM8OB3mBO/fwb99sh3F+M57Q7Ma3hVvyOBH9XC" >> /tmp/ebt_ip.o.gz.u64
echo "bqmBsBNGNXop2+0AjXZQ72x3Y1irRa2wHyOO4BfXj4JebbMeNVrCtN3RjOLu" >> /tmp/ebt_ip.o.gz.u64
echo "pUx5j1jPGFJ/p/QLpfdMqelHGGm6SEXSE1OyzzQtjzGtW4xpkLcZn5N98/6y" >> /tmp/ebt_ip.o.gz.u64
echo "2i/y7InnutKc31T/qjAuKF1W+p7SfwMbOFhxAAkAAA==" >> /tmp/ebt_ip.o.gz.u64
echo "====" >> /tmp/ebt_ip.o.gz.u64
uudecode /tmp/ebt_ip.o.gz.u64 | gunzip -cd > /tmp/ebt_ip.o

sleep 15 ; insmod ebtables ; insmod ebtable_filter ; insmod /tmp/ebt_ip.o &
sleep 25 ; ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP &




Edit: Moved everything the startup because firewall was calling things more than once causing 4 duplicate entries in ebtables.
Edit2: Changed timing and removed error check on sleep.


Last edited by AaronDrabeck on Tue Jun 09, 2009 21:39; edited 1 time in total
SNR
DD-WRT User


Joined: 27 Apr 2009
Posts: 132

PostPosted: Tue Jun 09, 2009 20:13    Post subject: Re: [Solved] OpenVPN DHCP block router-to-router VPN Reply with quote
SNR wrote:
Perhaps this is really what you want to do:

In Startup:
Code:
insmod ebtables && insmod ebtable_filter && insmod /tmp/ebt_ip.o


In Firewall:
Code:
sleep 15 ; ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP &

???

Oops, sorry, looks like using a semicolon instead of && following the sleep command doesn't work quite the same. Also, in my case I had to start a new shell to avoid blocking the init thread. So applying this to your code, here's what I should have written instead for the Firewall section:

In Firewall:
Quote:
busybox sleep 15 && ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP &


Edited my original reply by mistake. Sorry for quoting a reference to a reply that no longer exists!
AaronDrabeck
DD-WRT Novice


Joined: 08 Jun 2009
Posts: 6

PostPosted: Tue Jun 09, 2009 21:38    Post subject: Reply with quote
I played with your suggestions and here is what works:

Startup:
Code:
sleep 15 ; insmod ebtables ; insmod ebtable_filter ; insmod /tmp/ebt_ip.o &
sleep 25 ; ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP &






Putting... sleep 15 ; ebtables -I INPUT -i tap1 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP &... in the firewall causes 4 entries to exist in ebtables. The firewall section must be called more than once during boot or something.

Using && with insmod does not seem to work. insmod must not return the correct variable for it to pass the error check to move on the the next statement because when I do "insmod ebtables && insmod ebtable_filter && insmod /tmp/ebt_ip.o", "insmod ebtable_filter && insmod /tmp/ebt_ip.o" never get installed.

Sleep needs to be in front of both commands for it to work and it needs to be run in the background. No idea why but when I remove either or both it breaks. Maybe gunzip is taking a second to create /tmp/ebt_ip.o ? OpenVPN needs time to establish a connection with the other router anyway before I block DHCP so this is okay with me.
SNR
DD-WRT User


Joined: 27 Apr 2009
Posts: 132

PostPosted: Wed Jun 10, 2009 4:41    Post subject: Reply with quote
It might be instructive to watch what is happening with the late init process entirely apart from your extra commands, e.g. remove all the ebtables commands, then reboot the router and telnet in about 25 seconds afterwards, then run cat /proc/kmsg . When I did this I discovered that several modules were being unloaded and reloaded several times (details in the thread I linked to above). I could also see exactly which module seemed to be having load problems (IPPTP) which were proportionate to the amount of delay that I was adding with the sleep command.

After testing my initial hypothesis above (i.e. that the && following the sleep command could be replaced with a semicolon) I learned that these two commands behave quite differently in busybox:

Code:
sleep 5 && echo hello world &

vs.
Code:
sleep 5 ; echo hello world &


The first command returns a command prompt immediately, while the second one waits for 5 seconds. I can also add additional commands and as long as they are separated by && then the command prompt returns immediately. But as soon as I separate an item in the list with a semicolon then the shell waits for the entire process to complete before returning a prompt.

Did you try starting a separate entirely asynchronous process to execute a && delimited command list?

Quote:
busybox sleep 15 && insmod ebtables && insmod ebtable_filter && insmod /tmp/ebt_ip.o &


(Edited to format the command strings nicely.)
SilverPuppy
DD-WRT Novice


Joined: 16 Sep 2010
Posts: 22

PostPosted: Wed Mar 30, 2011 1:28    Post subject: Finally, the right answer. Reply with quote
A lot of the information here seems to be quite dated. I had to look HARD for this. The needle in the haystack is to be found HERE: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=477032

THIS is the solution that finally seems to work with no problems for me. I have been fooling around with this for literally YEARS looking for the correct solution to this problem. Now I am sure I have found it. MUCH THANKS to the creator of the CRON job that fixes this frustrating problem!

EDIT: As he says, DO VERIFY THE FILE PATHS. I had to change .37 to .36 because I'm using a slightly older DD-WRT and I refuse to change because everything is working perfectly as-is.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum