Hard Crash With iptable Entries AC86U 384.8 alpha

[GHammer]

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.

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)

#!/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

 

[john9527]

Might very well be this....
https://www.snbforums.com/threads/f...lts-releases-v36e9.18914/page-419#post-440451

See if your iptables-save output has the same problem.

 

[GHammer]

Might very well be this....
https://www.snbforums.com/threads/f...lts-releases-v36e9.18914/page-419#post-440451

See if your iptables-save output has the same problem.

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.

 

[john9527]

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.

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...

 

[GHammer]

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...

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..

 

[GHammer]

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.

 

[GHammer]

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.

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.

 

[ColinTaylor]

Doesn't look broken, but does not allow the router to operate.

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.

 

[john9527]

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

 

[GHammer]

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.

That makes sense then.

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

That's good news, thanks!

 

[GHammer]

@john9527
I couldn't give the test load a try as I have an 86U

 

[john9527]

@john9527
I couldn't give the test load a try as I have an 86U

That's why I deleted the post right after I made it

 

[GHammer]

That's why I deleted the post right after I made it

Ha! Trusty email update while eating dinner... I even downloaded the file before realizing it wasn't for me.

 

[john9527]

Since I got your hopes up I did and AC86 build for you

RT-AC86U_384.7_2test4-g4d6c14d7a.zip
https://1drv.ms/f/s!Ainhp1nBLzMJghJlb7j1wnqac97q

 

[GHammer]

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.

 

[GHammer]

Since I got your hopes up I did and AC86 build for you

RT-AC86U_384.7_2test4-g4d6c14d7a.zip
https://1drv.ms/f/s!Ainhp1nBLzMJghJlb7j1wnqac97q

Unfortunately, the router became unresponsive after about 3 minutes. Power cycled to flush the iptables entries.

 

[john9527]

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

 

[ColinTaylor]

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

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 , 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.)

 

[GHammer]

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:

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.

 

[GHammer]

@ColinTaylor So, you are able to run with these iptable entries on your 68U? They absolutely make my 86U unusable within a few minutes.