I was also giving an example (for PPPoE purposes) - note I mentioned if an ISP makes such an accommodation. I've seen few who make their network 1508 MTU. It's normal to leave it untouched (which is probably why it wasn't noticed).
I edited the Ethernet interface (in your example eth0, on my device wan), which I confirm also doesn't change.
Definitely a bug.
It's not something that was broken in 23.05.2. It is broken for quite awhile already. I have another ISP, which accepts 1500 over pppoe (which is technically a baby jumbo) but it advertises 1492...
Not only a technical bug. It requires interface changes. One has to decide where MTU settings should be exposed - in Devices or Interfaces tab.
Well, they're needed in rare examples (which is how i'm aware). Maybe it could be removed from the web GUI, but remain a UCI config.
TBH, on my DEVICE page, the config doesn't exist, it's really just the populated MAC. That same for your eth0 (nix MAC) - it's greyed out. It's seems to display the default while no config is present.
interface You run on your PPPoE session need to have 1508 as well
like
config device
option name 'dsl0'
option macaddr 'FAKEMAC'
option mtu '1508'
If VLAN is in use it will get 1508 mtu as well
root@7362sl:~# ifconfig dsl0 |grep MTU
UP BROADCAST RUNNING MULTICAST MTU:1508 Metric:1
root@7362sl:~# ifconfig dsl0.35 |grep MTU
UP BROADCAST RUNNING MULTICAST MTU:1508 Metric:1
pppoe will use MTU1500 if parent interface present MTU 1508 . No additional configuration required.
Nope it will not. It will use the value advertised by your ISP. You can enable pppd debug and make sure.
It should be designed in such way that one excludes the other. There should be no two places in interface that allow changes of MTU for the same interface.
P.S. UCI can have both but I'd prefer UCI to have at least primitive parsing of allowed settings.
I explained that already, but I understand your point assuming you're only considering PPoE, one such connection, etc..
It is far from being only PPPoE problem. It applies to other interfaces too. Even more... there is this IPv6 thing and it has its own MTU settings...
I'll concede it's confusing for one new to networking. I agree maybe hiding the setting is cool. Feel free to make a feature request.
But I definitely understand the need for them to be fixed in a community of 1 and 10 Gbps devices are being sought more often. There are instances where they need to be lowered as well as raised. That's also broken at this time.
So I understand your view on the multiple settings, and exposing it for both the PPPoE and raw Ethernet; but they are indeed valid and need to be fixed. Albeit I concede maybe the developers should consider hiding them in LuCI - as they're not common settings.
other examples:
I'm far from being new to networking and it is still confusing 
Should I make 1 Gbit ISP screenshot too if it proves my point?
You're right with scenarios but I'm talking about exposing to user non-sensical options which in fact change nothing in any place like the one I shown in my example. Average user doesn't need to check it via ifconfig to see if settings were applied or not.
So just going back to my original issue here, I am not convinced my issue is MTU (given that I can pass a full size 1500 byte IP packet outbound. However, I am only able to receive 1492 inbound (the upstream ISP router is sending back ICMP Fragmentation Needed, presumably because the Fritzbox is not sending the increased PPP Max-Payload).
Outbound (Note the response is truncated which i think means the reply is smaller than the request)
jon@home-linux:~$ ping -s 1472 -M do 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
76 bytes from 8.8.8.8: icmp_seq=1 ttl=57 (truncated)
76 bytes from 8.8.8.8: icmp_seq=2 ttl=57 (truncated)
Inbound (51.148.244.3 is an upstream device in the ISP, possibly the LNS I am connected to)
user@remote-host:~$ ping -s 1472 -M do <wan-ip>
PING <wan-ip> (<wan-ip>) 1472(1500) bytes of data.
From 51.148.244.3 icmp_seq=1 Frag needed and DF set (mtu = 1492)
From 51.148.244.3 icmp_seq=2 Frag needed and DF set (mtu = 1492)
Thanks
Jon
I tested 23.05.3 on x86_64 VM and it worked - so I tested again on my device from UCI.
config device
option name 'eth1'
option mtu '1600'
config device
option name 'wan'
option mtu '1600'
It also worked. I believe I perhaps edited the incorrect device this morning before 
.
You would be able to.
The issue should be solved by setting the Ethernet at 1508 and the PPPoE at 1500.
Note that some routers expose LAN ports as subinterfaces of eth0, with VLANs corresponding to them. This means that eth0 should have MTU=1512. However, OpenWrt figures this out automatically.
Example from Linksys E8450:
config interface 'wan'
option proto 'pppoe'
option username '...'
option password '...'
option mtu '1508'
option ipv6 'auto'
option device '@modem'
config interface 'modem'
option proto 'static'
option ipaddr '192.168.254.2'
option netmask '255.255.255.0'
option defaultroute '0'
option delegate '0'
option device 'wan'
option mtu '1508'
Result:
# ip link
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1512 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether e8:9f:80:d4:9e:c4 brd ff:ff:ff:ff:ff:ff
...
7: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1508 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether e8:9f:80:d4:9e:c3 brd ff:ff:ff:ff:ff:ff
...
47: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc cake state UNKNOWN mode DEFAULT group default qlen 3
link/ppp
...
Please note that this depends on the ISP actually supporting PPPoE with MTU=1500 consistently on all their access concentrators.
Hi there, the ISP does support 1500 as when I use my OpenWRT based Homehub 5A it works correctly. Your suggestions are basically what I was doing (dsl0 is the physical however on this device). Looking into this more, I am seeing a message on startup:
[ 42.394461] dsl0: mtu greater than device maximum
So looks like the hardware/driver may not support this (this is a Lantiq VRX500 compared to the VRX200 on the BT HomeHub).
Thanks
Jon
Is wan working on eth1? If so which setting will prevail if you specify different MTU values in you example?
The dsl driver source suggests to me that the interface maximum MTU is set to the default ethernet value of 1500 during interface setup even though the driver core functions support larger MTUs (certainly at least 1508), so I think a patch to increase the maximum MTU (as was done for the xrx200 devices) is feasible.
Which setting will prevail?
I'm not sure why you're implying an idea where one setting overriding the other or something. Since the premise of the question seems odd, I'm unsure how to respond. 
Maybe the "over Ethernet" (1508) part of the "PPP" (1500) is being forgotten?
I just wanted to acknowledge your response.
In any case, the OP has a DSL interface and not pure Ethernet.