Mtu / mangle table

Hi,

On a rutx11 running v7.4.4, I have a mtu issue. MSS clamping is enabled on the WAN interface, the rules are present in the mangle table, but no packet seems to match:

Chain FORWARD (policy ACCEPT 347 packets, 53095 bytes)
pkts bytes target prot opt in out source destination
0 0 TCPMSS tcp – * eth1 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 /* !fw3: Zone wan MTU fixing / TCPMSS clamp to PMTU
0 0 TCPMSS tcp – eth1 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 /
!fw3: Zone wan MTU fixing / TCPMSS clamp to PMTU
0 0 TCPMSS tcp – * wwan0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 /
!fw3: Zone wan MTU fixing / TCPMSS clamp to PMTU
0 0 TCPMSS tcp – wwan0 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 /
!fw3: Zone wan MTU fixing */ TCPMSS clamp to PMTU

counters are always stuck to 0.

I tried with software flow offloading enabled and disabled with the same behavior.
Is there something I need to configure to make this work ?

Thanks,

Mathieu

Hello,

I recently did a clean installation of 7.4.4 on the RUTX11. A handful of rules were auto-generated, and the packets matched the rules (mostly the first rule).

Are these the only TCPMSS rules you see within your forwarding chain?

Have you tried restoring the device to factory defaults?

Kind Regards,

Hi,

I’ll do more tests, but I noticed that in v7.4, “ip link show” shows that wwan0 has an MTU of 1500, while gsmctl -A ‘AT+QMTUINFO’ says 1430.

On another router running v7.1.6, both “ip link show” and “gsmctl -A ‘AT+QMTUINFO’” show the same value.

In another thread, you mentioned that “Recent firmware updates have altered the way the MTU is determined”, could it be the reason ?

Thanks,

setting the mtu with “ip link set dev wwan0 1430” solved my issue.

it looks like you made some changes in /lib/netifd/proto/qmi.sh

I added this code that I found in v7.1

    [ -z "$mtu" ] && {                       
           mtu="$(echo "$parameters4" | grep mtu | awk -F ' ' '{print $2}' | awk -F ',' '{print $1}')"
 }

before

[ -z “$mtu” ] && mtu=1500

and now it works even after a reboot.

Is it a bug ?