Menu
What's new
By:
Filters Better Search

Hard Crash With iptable Entries AC86U 384.8 alpha

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

GHammer

GHammer

Very Senior Member
I created a firewall-start script with two statements, uploaded it to the proper location, restarted the firewall and all was well. I then rebooted the router and it never came up fully.
Eventually, I caught a brief window and was able to delete the firewall-start script file and the router has continued to function normally.

The router accepted the iptables entries on a firewall restart, so why have unrecoverable issues after a reboot?

I'll post a snippet of the syslog and the entire firewall-start script.
If interested, I have the entire syslog saved.


Code: 
Oct 27 23:16:28 kernel: CPU: 1 PID: 210 Comm: bcmsw_rx Tainted: P        W  O    4.1.27 #2
Oct 27 23:16:28 kernel: Hardware name: Broadcom-v8A (DT)
Oct 27 23:16:28 kernel: Call trace:
Oct 27 23:16:28 kernel: [<ffffffc0000876d8>] dump_backtrace+0x0/0x150
Oct 27 23:16:28 kernel: [<ffffffc00008783c>] show_stack+0x14/0x20
Oct 27 23:16:28 kernel: [<ffffffc00050389c>] dump_stack+0x90/0xb0
Oct 27 23:16:28 kernel: [<ffffffc000094070>] warn_slowpath_common+0x98/0xd0
Oct 27 23:16:28 kernel: [<ffffffc000094150>] warn_slowpath_null+0x18/0x20
Oct 27 23:16:28 kernel: [<ffffffc0003c2d20>] dst_release+0x68/0x70
Oct 27 23:16:28 kernel: [<ffffffbffcaa42c8>] route.isra.0+0x78/0x118 [ipt_ROUTE]
Oct 27 23:16:28 kernel: [<ffffffbffcaa4410>] ipt_route_target+0xa8/0x4b0 [ipt_ROUTE]
Oct 27 23:16:28 kernel: [<ffffffc00047c658>] ipt_do_table+0x2b0/0x400
Oct 27 23:16:28 kernel: [<ffffffc00047f418>] iptable_mangle_hook+0x38/0x108
Oct 27 23:16:28 kernel: [<ffffffc0003ffc74>] nf_iterate+0x94/0xa8
Oct 27 23:16:28 kernel: [<ffffffc0003ffd38>] nf_hook_slow+0xb0/0x160
Oct 27 23:16:28 kernel: [<ffffffc00042c2ac>] ip_output+0x12c/0x170
Oct 27 23:16:28 kernel: [<ffffffc000427734>] ip_forward_finish+0x6c/0x90
Oct 27 23:16:28 kernel: [<ffffffc000427b04>] ip_forward+0x3ac/0x468
Oct 27 23:16:28 kernel: [<ffffffc000425dbc>] ip_rcv_finish+0x134/0x328
Oct 27 23:16:28 kernel: [<ffffffc000426490>] ip_rcv+0x2d8/0x3b8
Oct 27 23:16:28 kernel: [<ffffffc0003b6690>] __netif_receive_skb_core+0x628/0xa40
Oct 27 23:16:28 kernel: [<ffffffc0003b969c>] __netif_receive_skb+0x2c/0x88
Oct 27 23:16:28 kernel: [<ffffffc0003b9738>] netif_receive_skb_internal+0x40/0xc0
Oct 27 23:16:28 kernel: [<ffffffc0003b97c8>] netif_receive_skb_sk+0x10/0x18
Oct 27 23:16:28 kernel: [<ffffffbffc3689e4>] bcm63xx_enet_rx_thread+0x7b4/0xce0 [bcm_enet]
Oct 27 23:16:28 kernel: [<ffffffc0000af6b0>] kthread+0xd8/0xf0
Oct 27 23:16:28 kernel: ---[ end trace dd9a2b1a17d798ee ]---
Oct 27 23:16:28 kernel: ------------[ cut here ]------------
Oct 27 23:16:30 kernel: WARNING: CPU: 1 PID: 210 at net/core/dst.c:288 dst_release+0x68/0x70()
Oct 27 23:16:30 kernel: Modules linked in: ipt_ROUTE init_addr(          (null) -           (null)), core_addr(ffffffbffcaa4000 - ffffffbffcaa4838)

Code: 
#!/bin/sh
iptables -t mangle -A PREROUTING  -s 10.10.100.121 -j ROUTE --tee --gw 10.10.100.115
iptables -t mangle -A POSTROUTING -d 10.10.100.121 -j ROUTE --tee --gw 10.10.100.115
 
GHammer said:
Yes, that is my mangle statement. So it sounds like this has been present for some time and I'll just have to wait until it is fixed. This is on an 86U that doesn't support your fork.
Click to expand...
I wasn't sure if the same problem existed in the iptables version used by the AC86.

Just for completeness, the iptables-save is missing a space.....
...-j ROUTE--gw...

instead of
...-j ROUTE --gw...
 
john9527 said:
I wasn't sure if the same problem existed in the iptables version used by the AC86.

Just for completeness, the iptables-save is missing a space.....
...-j ROUTE--gw...

instead of
...-j ROUTE --gw...
Click to expand...

Must have been the save/load that caused it as when I originally manually input the statements all was fine. It failed on reboot when the script is called..
 
Any idea if this issue is being looked at/corrected or is it at the Asus level?
I guess I can manually enter the statements and monitor for restart so I can manually enter them again meantime.
 
Well, this issue exists in manual entry of the routes as well as via script.
I just tried this on alpha2 and 384.7.2 first the GUI is unresponsive then ssh gets slower than a 300 baud tty.
Luckily, power cycling takes care of this as the iptables entries are wiped on reboot.
Code: 
ASUSWRT-Merlin RT-AC86U 384.7-2 Sun Oct 21 17:20:37 UTC 2018
admin@RT-AC86U-6828:/tmp/home/root# iptables -t mangle -A PREROUTING  -s 10.10.1
00.121 -j ROUTE --tee --gw 10.10.100.115
admin@RT-AC86U-6828:/tmp/home/root# iptables -t mangle -A POSTROUTING -d 10.10.1
00.121 -j ROUTE --tee --gw 10.10.100.115
admin@RT-AC86U-6828:/tmp/home/root# iptables -t mangle -L -n | grep 115
ROUTE      all  --  10.10.100.121        0.0.0.0/0           ROUTE gw:10.10.100.115 tee
ROUTE      all  --  0.0.0.0/0            10.10.100.121       ROUTE gw:10.10.100.115 tee

Doesn't look broken, but does not allow the router to operate.
 
GHammer said:
Doesn't look broken, but does not allow the router to operate.
Click to expand...
The problem is not obvious when using that command unless you compare the alignment with the rest of the commands. Look at the output of iptables-save and the problem becomes apparent.
 
We'll find out soon enough. Merlin picked up the iptables-save ROUTE fix yesterday, so it should be in his next build.
 
ColinTaylor said:
he problem is not obvious when using that command unless you compare the alignment with the rest of the commands. Look at the output of iptables-save and the problem becomes apparent.
Click to expand...

That makes sense then.

john9527 said:
We'll find out soon enough. Merlin picked up the iptables-save ROUTE fix yesterday, so it should be in his next build.
Click to expand...

That's good news, thanks!
 
@john9527
I couldn't give the test load a try as I have an 86U
 
john9527 said:
That's why I deleted the post right after I made it :)
Click to expand...
Ha! Trusty email update while eating dinner... I even downloaded the file before realizing it wasn't for me.
 
So far, so good. iptables applied. Router still accessible. I'll see if the traffic I need is appearing on 115. No reason to think otherwise.

Gosh, it's like Christmas! Thanks John.
 
john9527 said:
If what you are trying to do is mirror all traffic from one address to another, make both commands PREROUTING. Otherwise I think you may be creating a loop.

a ref for you
https://forum.level1techs.com/t/por...-chain-target-match-by-that-name-error/128870
Click to expand...
It should work the way he has it. I suspect he might be referring back to this post I made ;). I've just double-checked it and it does work.

Putting the -d command in the PREROUTING chain doesn't work. If you follow your link back through to its original source it was using POSTROUTING for that. I think the mistake then got repeated in subsequent posts (like most things on the internet) but nobody noticed because it was still mirroring traffic in one direction.

(Don't ask me to explain why -d works in POSTROUTING and not PREROUTING because I have no idea :D, I'm just looking at the Wireshark output. EDIT: Actually I think I get it now, it's because the destination is on the LAN not the WAN.)
 
Last edited:
Well, I'd like to mirror the traffic, but perhaps I should just redirect the traffic and use the target server to then send the data along to its original destination. Like this:

Code: 
iptables -t nat -A PREROUTING -d rtupdate.wunderground.com -p tcp –dport 80 -j DNAT –to-destination 10.10.100.115:81

Of course this won't really work as it is an AWS target so has multiple IPs and can/will change. Also has the troublesome -d in PREROUTING.
 
@ColinTaylor So, you are able to run with these iptable entries on your 68U? They absolutely make my 86U unusable within a few minutes.
 
You must log in or register to reply here.

Similar threads

GHammer
(Solved) iptables Entry Not Applied 86U 384.8
Replies
3
Views
2K
Jack Yaz
Jack Yaz
D
Kernel panic on rt-ac86u running 384.11
Replies
1
Views
2K
davidlee93
D
Similar threads
Thread starter Title Forum Replies Date
D Soft Reboot (fail) vs Hard Reboot Asuswrt-Merlin 17
heysoundude Why aren't the directions to hard reset stickied? Asuswrt-Merlin 4
O RT-AC86U - 386.12 : OpenVPN server crash when applying other network changes Asuswrt-Merlin 5
A Turning on AIMesh node (RT_AC86U) cause main router (RT_AC88U) to repeatedly crash Asuswrt-Merlin 3
A Starting OpenVPN with TAP Client seems to crash RT-AX86U Asuswrt-Merlin 22
U IPtable entries not saving? Asuswrt-Merlin 9

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Total: 877 (members: 13, guests: 864)
Top