dhcp dies with firewall-start. Merlin said to do this.

[133794m3r]

#!/bin/bash
iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG --log-prefix "INPUT:DROP: " --log-level 6
iptables -A LOG_DROP -j DROP
iptables -A INPUT -s x.y.z.a -j DROP

causes the thing to get stuck at the "waiting for an ip address" status message from the ethernet cnnected computer and the laptop's wireless. I don't get how this could happen but for some reason it does. It is _not_ any localhost ip addresses nor the other reserved ones for interenal networking. It happens everytime I add that rule to the script and restart the router. After that, it never lets anyone connect.

Since apparently filing a bug report when the thing crashes and dies isn't the proper way to do this. I'll just repost my thread all over again since that's _clearly_ going to do more. It's _obviously_ not a bug in the system that makes it literally die.

 

[ColinTaylor]

That script won't work because /bin/bash doesn't exist on the router, use #!/bin/sh instead.

 

[133794m3r]

why the hell does the router lock up then? and merlin claims this _isn't_ a damned bug. Like hello, it should only do an error to the log not lock up the damned thing.

 

[mstombs]

Enter the commands one at a time using an ssh console session, also check on line endings in your saved script file. Your script will also not work (shouldn't crash though) because you are Adding to the INPUT chain, below any other accepts. Also you are not using the LOG_DROP chain you create (it it just convention not to use capitals?), not that's its really necessary since Asuswrt-Merlin already has a logdrop chain.

 

[133794m3r]

that's probably a typo in me pasting it onto the forums as I didn't keep a local copy of the script and had to redo it from memory to post on here. I didn't realize it already had a logdrop chain I can remove that first line. It should've been LOG_DROP so that's a typo in the thing. It locks up dhcp doesn't give out any ips yet merlin in his greatness seems to not understand how it's a bug that a script that should do nothing except throw an error crashes the whole systems dhcp system and refuses to let anything connect to it and hand out any ips.

 

[Jack Yaz]

that's probably a typo in me pasting it onto the forums as I didn't keep a local copy of the script and had to redo it from memory to post on here. I didn't realize it already had a logdrop chain I can remove that first line. It should've been LOG_DROP so that's a typo in the thing. It locks up dhcp doesn't give out any ips yet merlin in his greatness seems to not understand how it's a bug that a script that should do nothing except throw an error crashes the whole systems dhcp system and refuses to let anything connect to it and hand out any ips.

Please post the actual script then, if the initial post is a from memory copy

 

[133794m3r]

Please post the actual script then, if the initial post is a from memory copy

Incase you didn't read the whole post, the router had to be factory reset to get it to let me connect to it. It was moreorless that.

here's the literal thing that I had used except for the ips part, which I'd have to relook up again and hunt down. But none were 192.168.0.0/16, 10.0.0.0/8, 127.0.0.0/8, or 0.0.0.0/8(which linux sees as all possible routes)

I put the following in a shell script with the destined ip-address. which as I said are not used by any of the reserved addresses that is something I made sure of.

iptables -A LOG_DROP -j LOG --log-prefix "INPUT:DROP: " --log-level 6
iptables -A LOG_DROP -j DROP
iptables -A -s x.y.z.a -j LOG_DROP

 

[RMerlin]

That's the x.y.z.a IP? If it's your ISP's IP, then you will prevent your router from potentially obtaining a DHCP lease. Likewise, if that IP is actually an invalid IP and a subnet (for example if you used 10.10.10.0 with a mask of 255.255.255.0 - that means the whole subnet, not just a specific IP).

Kinda hard to properly troubleshoot this without the exact content (especially if bits are from memory).

 

[133794m3r]

150.70.0.0/16
216.104.0.0/19

iptables -A -s 150.70.0.0/16 -j LOG_DROP
iptables -A -s 216.104.0.0/19 -j LOG_DROP

my ISPs external ips are not in that range at all. I was also going to block other blocks if that worked but haven't gotten around to it yet because those two killed the thing so there you go. That was teh two ranges(i relooked it up) and that's the ones I did. I was going to do it bit by bit and see wherein I ever had any issues.

Their external are in the 216 range but not anywhere in that block. They are in the 216.145.x.y range so there's no way it'd die. And if it'd affect getting external ip-addresses from the isps dhcp server then I should've been able to still connect to the router just not the outside world.

I was moreorless using this site after those two ranges.

http://ipinfo.io/AS16880

which I got from here.
https://www.belle-aurore.com/mike/2012/01/trend-micros-botnet-and-how-to-ban-it/

 

[RMerlin]

Your rules are missing the chain.

iptables -A INPUT -s 150.70.0.0/16 -j LOG_DROP
iptables -A INPUT -s 216.104.0.0/19 -j LOG_DROP

 

[133794m3r]

that was the ips that you wanted. the full thing would be.

#!/bin/bash
iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG --log-prefix "INPUT:DROP: " --log-level 6
iptables -A LOG_DROP -j DROP
iptables -A INPUT -s 150.70.0.0/16 -j LOG_DROP
iptables -A INPUT -s 216.104.0.0/19 -j LOG_DROP

 

[ColinTaylor]

that was the ips that you wanted. the full thing would be.

#!/bin/bash
iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG --log-prefix "INPUT:DROP: " --log-level 6
iptables -A LOG_DROP -j DROP
iptables -A INPUT -s 150.70.0.0/16 -j LOG_DROP
iptables -A INPUT -s 216.104.0.0/19 -j LOG_DROP

As I said before:

That script won't work because /bin/bash doesn't exist on the router, use #!/bin/sh instead.

It's probably worth doing the following just to make sure everything's OK:

dos2unix /jffs/scripts/firewall-start
chmod 777 /jffs/scripts/firewall-start

Also, you haven't mentioned your router model or firmware version.

 

[133794m3r]

As I said before:
It's probably worth doing the following just to make sure everything's OK:

dos2unix /jffs/scripts/firewall-start
chmod 777 /jffs/scripts/firewall-start

Also, you haven't mentioned your router model or firmware version.

that shouldn't crash teh router. If it doesn't work big deal, biggest deal right now is that the crashes the damned thing. and it's rt-ac87u latest merlinwrt as far as I can remember I just updated it a bit before I did this.

Plus I'm on linux already and sshing into the router and writing the shellscript from that folder wherein they lie.