I've been busy playing with the QoS and iptables stuff (which is working fine for me) and I've come across something that looks wrong while going through the code.
This commit was undoing something from the upstream 2.6.36 kernel code, and has left the fork misaligned:
Fork of earlier asuswrt-merlin router firmware. Contribute to john9527/asuswrt-merlin development by creating an account on GitHub.
github.com
The removal of the
return XT_RETURN;
means that the (hacky)
--set-return
match that is supposed to set the connection and packet mark, then return from the filter chain, isn't returning.
Which means the traditional QoS matching largely won't be working on devices using that kernel - the iptables entries will match, but then it will keep going through the mangle rules, and eventually run the final
-A QOSO -j CONNMARK --set-return 0x4/0x1ff
that sets priority to low, so making pretty much all traffic low priority, aside from the stuff like ACKs handled over in
tc
rather than
ìptables -t mangle
.
I believe the previous code had taken out the
return XT_RETURN
because the code in ip_tables.c to handle it was missing. It is now there.
HOWEVER, the equivalent code for ip6_tables.c is still missing. (It's present in the 2.6.22 kernel). And that's missing upstream too.
Do you recall what the problem you were fixing in that commit was? Maybe it was IPv6 related?
Looking at it, I suspect traditional QoS rules won't be working on 2.6.36 devices on your fork, and may be cause IPv6 problems on Merlin's version. Devices with other kernels - older or newer - will be fine. Newer kernels dropped the
--set-return
and devices using them put separate
MARK
and
RETURN
entries in their iptables.
Edit: made an upstream PR to restore the missing ip6_tables code. Restoring
return XT_RETURN
probably depends on that.
https://github.com/RMerl/asuswrt-merlin.ng/pull/794
Edit 2: This may not actually be an issue, because the rc/qos.c on devices with this kernel may already be avoiding using
--set-return
because of this kernel bug. The
manual_return
flag is controlling that. Do you think there are any devices with 2.6.36 kernels that wouldn't be setting the flag? It might be safer to remove the kernel additions altogether from 2.6.36 to ensure userspace gets an error, rather than letting them use potentially-flawed kernel code. (This kernel addition was always a hack).