Ag71xx Gigabit (e.g. Archer c7 v5) eth raising MTU problem/regression

stragies · September 6, 2019, 12:53pm

Hi all,

I'd like to raise the MTU of ethX to at least 1532, ideally 2304, to encapsulate BATMAN, etc.
Some of the VLANs on ethX will then get a lower MTU.

On ArcherC7v5 (trunk-snapshot) this works, but only up to MTU 1516.
On RB2011 (1907-snapshot) no raising above 1500 is possible.

For the ag71xx there is an ancient bug report about not being able to reach higher than 4070 , whereas I'm only aiming for 2304 .

I'm aiming for 2304, because that is the MTU of the other BATMAN hard_if backhaul. But, I'd be happy with anything >1536, so that i can encapsulate BatmanWithVLAN packets without fragmentation. Else the performance on BATMAN mesh is really bad.

For the RB2011 the official docs quote a max MTU of 4074 on the GE interface and switch. The official firmware by default runs the ports in MTU 1598.

The Archer c7 v5 is running an ath79 trunk-snaphot from today, the RB2011 the latest ar71xx 1907-snapshot.

This is setup in /etc/config/network:

config device 'eth0_dev'
    option ifname 'eth0'
    option mtu '2308'    # 1516 is the max value, that works here

config device 'bhi_eth0_4_dev'
    option name 'eth0.4'
    option mtu '2304'  # Attempting to set MTU on VLAN to "eth0 - 4"
    option macaddr '98:da:c4:33:44:55'

config device 'some_dev'
    option name 'eth0.5'
    option mtu '1500' # Attempting to set MTU on VLAN 5 to normal 1500
    option macaddr '98:da:c4:33:44:77'

So, could somebody please indicate, how to set MTU@eth0 to 2308, or higher than 1516(1500) on ArcherC7v5/RB2011v5

Thank you

Note: Edited/detailed/cleaned/updated with new info, and will now delete my older replies to this thread.

trendy · September 6, 2019, 3:46pm

To the best of my knowledge per VLAN MTU setting has effect only on VTP advertisments of the particular VLAN. Not exactly what you want to achieve.
Try to change it only downwards first, for example from 1500 to 1492.
Then try your way up.
This is my output:

network.wan=interface
network.wan.proto='pppoe'
network.wan.ifname='eth1'
network.wan.mtu='1492'

stragies · September 6, 2019, 4:24pm

Downward never was the problem. E.g. manually with

ifconfig eth0 mtu 1460

Upward this only works until 1516. But, both the AR8337 switch, and the ag71xx SGMII Ethernet interface in the archer c7 v5 are Jumbo-frames capable! There is a bug report about not being able to reach higher than 4070, whereas I'm only aiming for 2304.

On the other hand, there is at least ONE person in the OpenWrt community, who has managed an MTU of 4070!

So, we just have to find this person

If this affects several/all ar71xx/ath79 devices, it will basically rule out those devices, if you are hoping to use a Gigabit ethernet backhaul for BATMAN, or other mesh.

trendy · September 6, 2019, 4:31pm

Looks like it doesn't have too much attention from developers
On the other hand I can understand it, as it is not some huge bug that causes stability or functionality issues.
Even if you find him, what will change? It is seen in the ticket that he raised the MTU value with ifconfig command.

trendy · September 6, 2019, 7:00pm

Even if you find him, what will change? It is seen in the ticket that he raised the MTU value with ifconfig command.

stragies · September 6, 2019, 7:23pm

He might remember something he did to make it go over 1516? Or when about that stopped working. To track down the regression, to see, if it can be re-enabled?

drandyhaas · September 7, 2020, 5:28pm

I think I've sort of figured this out. On the 19.07.3 branch, I modified this:

diff --git a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index b4ffa1154f..93c0deacd0 100644
--- a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++ b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -1416,7 +1416,8 @@ static int ag71xx_probe(struct platform_device *pdev)
            !of_device_is_compatible(np, "qca,qca9560-eth"))
                max_frame_len = ag->desc_pktlen_mask;
        else
-               max_frame_len = 1540;
+               max_frame_len = 1540 + 100;//ACH
+               printk("ACH max_frame_len = %d\n",max_frame_len);//ACH
 
        dev->min_mtu = 68;
        dev->max_mtu = max_frame_len - ag71xx_max_frame_len(0);

The code was setting the max_frame_len to 1540 for qca9550-eth and qca9560-eth, which the archer c7 seems to be. I don't know why. But with this change, I'm able to set the mtu for eth0 and/or eth1 to 1560 with no problems:

root@OpenWrt:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether ec:08:6b:ae:b0:e0 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1560 qdisc fq_codel state UP qlen 1000
    link/ether ec:08:6b:ae:b0:df brd ff:ff:ff:ff:ff:ff
7: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether ec:08:6b:ae:b0:df brd ff:ff:ff:ff:ff:ff
8: eth1.1@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1560 qdisc noqueue master br-lan state UP qlen 1000
    link/ether ec:08:6b:ae:b0:df brd ff:ff:ff:ff:ff:ff
10: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether ec:08:6b:ae:b0:e0 brd ff:ff:ff:ff:ff:ff
11: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UNKNOWN qlen 1000
    link/ether a2:f0:6e:20:6e:0e brd ff:ff:ff:ff:ff:ff
12: eth1.3@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1560 qdisc noqueue master bat0 state UP qlen 1000
    link/ether ec:08:6b:ae:b0:df brd ff:ff:ff:ff:ff:ff
13: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether ec:08:6b:ae:b0:df brd ff:ff:ff:ff:ff:ff
14: mesh0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2304 qdisc noqueue master bat0 state UP qlen 1000
    link/ether ec:08:6b:ae:b0:de brd ff:ff:ff:ff:ff:ff
15: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether ee:08:6b:ae:b0:de brd ff:ff:ff:ff:ff:ff

And batman is now happily sending/receiving packets on eth1.3, at up to ~250 Mb/s. It's not setting the world on fire, but at least it is ethernet backhaul!

stragies · September 20, 2020, 3:54pm

Thank you, this looks very promising!

why did you pick "adding 100", why not a different (higher) number, e.g. "1000"?

I just modified this locally in my sources to 2540, and am recompiling now.

regularfry · September 26, 2020, 6:30pm

Just for completeness (and since I've got one handy), it's possible that something's changed since that bug was written. Today, you can't ifconfig the mtu higher, the 4070 command fails with:

root@OpenWrt:~# ifconfig eth0 mtu 4070
ifconfig: SIOCSIFMTU: Invalid argument

I've just been bitten by this too. It's not as critical for me, but it's an odd limitation, and I'd really hope it's accidental.

systemcrash · May 31, 2021, 8:27pm

Can sort of confirm - was bitten by this on my TP-Link Archer C7 v2 - only seems to go up to ~4070

Arch = Qualcomm Atheros QCA9558 ver 1 rev 0

I read somewhere it was a limitation of the underlying switch chipset (that it can't handle 9K).