Unable to enable jumbo frames

Hi all,

jumbo frames are supported by Omnia hardware, but I’m unable to set MTU to 9k. I want jumbo frames for LAN enabled. I have set via LUCI 9000 MTU on br-lan interface.

root@someturris:~# grep -B8 9000 /etc/config/network
config interface 'lan’
option ifname 'eth0 eth2’
option force_link '1’
option type 'bridge’
option proto 'static’
option netmask '’
option ip6assign '60’
option ipaddr 'x.x.x.x’
option mtu ‘9000’

However MTU is at default across all interfaces, physical, or virtual. I have tried to set up larger MTU on eth0/eth2 by ifconfig, but I cant do it for br-lan interface and thus Im stuck on 1500 MTU. Rising MTU to 9000 for eth2 will disconnect everything (LAN/WiFi) and because I dont have console cable, I cant tell You why this happens.

root@someturris:~# ip a | grep 1500
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 532
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 532
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 532

14: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

some googling reveals that this was a loooong standing issue in openwrt, eventually fixed last summer.
it was suggested, you may have to remove the brige, set mtu manually and recreate the bridge.

might be easier to just remove the bridge and move on :wink:

It should be further noted that there’s a catch when enabling jumbo frames on the Omnia, since it’s based on an Armada 385 SoC: hardware checksumming isn’t supported with an MTU above 1600[1].

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/ethernet/marvell/mvneta.c?id=b65657fc240ae6c1d2a1e62db9a0e61ac9631d7a

1 Like

… which should not be a problem

Thank You all for replies.
I dont have a spare time now to play with the router as mentioned by fuller, try removing and adding bridge etc. I have to try suggested in a near future. Meanwhile I have bought an already needed gigabit switch with jumbo frame support and reconnected all clients from turris to the switch. Turris is not routing this heavy traffic outside, so this problem dont affect me anymore and speeds during file transfers went up.
Once again, thanks for sharing :wink:

Has anyone managed to set mtu 9000?

Yes, MTU 9000 on the eth ifaces and MTU 2304 on the wlan ifaces.

Since the switch chip in the omnia is not capable to add WLAN ports to the VLAN it requires bridging thus and as the bridge inherits the lowest MTU value from its its enslaved devices, here the WLAN iface with max. MTU 2304, the exercise of jumbo frames on the LAN ports is rather futile.

Interesting is, that OpenVPN’s tun0 has 1500, and wireguard’s wg iface has 1420 by default.

These are in-app values that do not touch upon the device values. 1500 used to be the eth standard in the old days.


MTU — if not specified, the MTU is automatically determined from the endpoint addresses or the system default route, which is usually a sane choice.

1 Like

probably because in practice you want a packetsize<1492 (or less) to make it work across most pppoe-links (dsl) without fragmentation from the tunnel hurting performance.

1 Like

So if I am connected to LAN0 port and then I apply the command

ifconfig lan0 mtu 9000

will set the ethernet port to MTU 9000 even the port is bridged (and bridge has MTU 1500 as max value)?

more convenient perhaps via /etc/config/network

config device
	option name 'lan0'
	option mtu '8500'

Use ubus -v call network reload from ssh cli after changes made.

The software bridge that is enslaving lan0 will inherit the MTU value from the slave - but it will inherit always the lowest MTU value amongst all of its slaves, meaning if you add a 2.4/5 GHz WLan (mac80211) interface to the software bridge with its limit of max 2304 bytes the bridge will inherit that value.
802.11ad extends the maximum MSDU size for DMG (freq > 40Ghz) networks to 7920 bytes