Hi there, was wondering if anybody has managed to get Baby Jumbo frames working on the Fritzbox with VDSL2 (G.993.2). Am in the UK and used to use a BT Homehub 5A which worked fine by moidifying the MTU of the "'wan" and "wan_dsl0_dev" interfaces to 1508 and everthing just worked. In PPP debug, I used to see "[PPP-max-payload 05 dc]" being sent and it all just worked.
I have moved to a Fritzbox 7530 (as I had it from my ISP and it is better spec-wise) and cannot get this working correctly in both directions. Even if i add "option pppd_options 'mtu 1500 mru 1500'" to my WAN interface, I always see it negotiate an MRU of 1492 (I didn't see this on the previous Homehub). Weirdly, I can send maximum payload frames outbound (i.e. an ICMP request with don't fragment and 1472 payload). However sending the same from externally inbound to my router, I can only send up to 1464 bytes without my upstream ISP routed sending an ICMP Fragmentation needed message.
Not sure where to go from here to debug further, guess it could be that the VRX500 driver doesn't support these options.
Config as follows:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd9f:09b1:6010::/48'
config atm-bridge 'atm'
option vpi '1'
option vci '32'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
config dsl 'dsl'
option annex 'b'
option tone 'a'
option ds_snr_offset '0'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr 'x.x.x.22'
option netmask '255.255.255.248'
option ip6assign '60'
config device
option name 'dsl0'
option macaddr '3C:AB:BC:09:CC:B5'
option mtu '1508'
config interface 'wan'
option device 'dsl0.101'
option proto 'pppoe'
option username 'user@isp'
option password 'password'
option ipv6 'auto'
option mtu '1508'
option pppd_options 'mtu 1500 mru 1500'
config device 'wan_dsl0_dev'
option name 'dsl0'
option macaddr '84:ab:12:34:4f:fb'
option mtu '1508'
config interface 'wan6'
option device '@wan'
option proto 'dhcpv6'
config device
option name 'pppoe-wan'
option mtu '1508'
I had similar problem but with regular pppoe connection. And I believe that MTU settings are broken. There are two places, where you can specify MTU for an interface. One in "Interfaces Tab" -> WAN -> Override MTU. But it doesn't work for me. On the hand, there is MTU setting in Device -> pppoe-wan, which works... Why they are two? I have no idea. But IMO it is confusing and doesn't work (at least half of it).
Which settings will apply if one in Interfaces tab says 'X' and another one in Devices tab says 'Y'? I'm confused how it supposed to work in my example.
WAN would exist as the raw Ethernet PHY/interface (e.g. users with Ethernet ISP connectivity, no PPPoE), this MUST parameter can be set under Network > Interfaces > Devices > WAN (it seems broken in 23.05.3)
Second would be your PPPoE interface, which you noted works when setting
You can see the PHY MTU setting:
ifconfig wan
Please recall you have a PPPoE connection on a normal Ethernet interface. Both should have a [working] MTU setting.
(I didn't wanna note without verifying in your instance, but usually if an ISP sets up Jumbo Frames for PPPoE, the Ethernet becomes 1508 and PPPoE would be 1500 - hence you experience a full 1500 MTU Internet connection. Again, this is if the ISP made their network jumbo to accommodate full 1500 MTU PPPoE connections.)
The one doesn't work should not be even shown in interface.
There is no such interface if you set up PPPoE, it is pppoe-wan. But you can try it youself and make sure that only Devices MTU will apply onto pppoe-wan.
It a bug and it exists for a long time. I had the same task on using baby jumbo frames for about 2 years ago and discovered that only one of two settings work. What is the point of having Override MTU in WAN interface settings if it doesn't work... - I have no idea. IMO it is a bug.
I'm giving an example. My ISP advertises 1480 which is too conservative and in fact 1492 works totally fine. DF packets up to this size can go without troubles,
