Unable to enable jumbo frames


#1

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 '255.255.0.0’
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


Samba4 experience
#2

some googling reveals that this was a loooong standing issue in openwrt, eventually fixed last summer.
https://lists.openwrt.org/pipermail/openwrt-devel/2016-August/042036.html
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:


#3

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


#4

… which should not be a problem


#5

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:


#6

Has anyone managed to set mtu 9000?


#7

#8

Yes, MTU 9000 on the eth ifaces and MTU 2304 on the wlan ifaces. The br iface will inherit the lowest MTU value from its enslaved devices


#9

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


#10

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

https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8

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


#11

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.