then tracepath -b www.google.com
you will get something like:
root@turris:~# tracepath -b www.google.com
1?: [LOCALHOST] 27.000ms pmtu 1492
1: 2a02:3001::11e (2a02:3001::11e) 938.011ms
1: 2a02:3001::11e (2a02:3001::11e) 418.068ms
2: 2a02:3001::1b7 (2a02:3001::1b7) 974.011ms
3: no reply
4: 2001:4860:1:1::ff0 (2001:4860:1:1::ff0) 476.011ms asymm 3
5: no reply
6: no reply
7: no reply
8: no reply
9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
Too many hops: pmtu 1492
Resume: pmtu 1492
Use the final pmtu value to configure the MTU for the specific interface, if you feel adventurous and expect a hidden IPv4 over IPv6 tunnel run both: tracepath -b4 www.google.com and tracepath -b6 www.google.com and pick the smaller of the two reported values, but under normal conditins both should return the same value...
Sure you can do this manually via the don't fragment flag and trying different packet sizes, but IMHO tracepath makes all of this more convenient...
so I tried your command on xda-developers website at (set in wan interface) both MTU value 1452 and unsetting the MTU and both times it gives me different answers. MTU set at 1452 resulted in pmtu 1444, and unsetting it resulted in pmtu 1492 (which also is -8 from 1500). And weirdly enough the xda-developers site now loads with MTU unset. So now my course of action just going to be leaving it unset with the value 1452 as backup.
Well, if you force the MTU to 1452 on an ethernet interface carrying PPPoE the additional PPoE overhead will make the apparent internet MTU 8 bytes smaller, and 1444+8 = 1452...
Really only set the MTU for the pppoe-wan interface to 1492 to solve your issue.
What puzzles me a bit is that OpenWrt typically does that automatically...
I've checked before I changed any MTU, the value was indeed 1492 (it was the faded one if you don't put in any value, not sure if it's accurate.
Now that you mentioned it, I also did try MSS clamping option before changing the MTU in 'lan' interface (thanks for mentioning that btw!), but it didn't work, and I just forgot, left it there and changed MTU to 1452. Maybe that's the real reason? But then why didn't it work out the first time with the MTU option unset...
I perused the thread and I did not see where it was suggested to change the MTU on the lan.
Did I miss that?
I am asking because I'd need to refresh my understanding of where to change MTU if LAN is included.
No, that was confusing on my part. What I meant was there was a checkbox that named "MSS clamping" on the LAN ->WAN in firewall. as far as I know, it's for clamping down the packet coming from lan to fit wan interface MTU, but I could be wrong.
So in my experience the OpenWrt defaults work, IFF the ISP does its part as well. That is OpenWrt does MSS clamping only in one direction on the wan zone expecting the ISP to do the same. If you ISP screws this up then MSS clamping on the LAN side can be a viable work-around.
No, please do not intermix MTU (maximum transfer unit) with TCP's MSS (maximum segment size) these are not the same. Here is a decent overview of MSS clamping. In essence this will manipulate the negotiation during the connection establishment in that the router will change the MSS value the remote side offers to the local machine. It will not change the idea of MTU the remote side has towards the local end point, it is just that TCP packets will not exceed the MSS size and given that the headers are (typically) constant (or are accounted as part of the MSS) that means they will never exceed the MTU and hence will neither be lost or fragmented. But that means that a UDP flow that does not use MSS negotiation will not profit from MSS clamping.
Yes, MTU and MSS are related; yet no, they are not identical but subtly different.
You cited a response that was muddling MTU and MSS-clamping, and that is what I responded to. No offence intended, I just think that in the long run it pays off for the forum to supply correct and useful information and not add to the organic confusion this topic invites.
