kernel-panic69 DD-WRT Guru

Joined: 08 May 2018 Posts: 16758 Location: Texas, USA
|
|
Sp1derman DD-WRT User
Joined: 16 Jun 2006 Posts: 230 Location: Germany, BW
|
Posted: Mon Dec 02, 2024 1:56 Post subject: |
|
| tedm wrote: | | I'm no longer seeing the black hole that I was seeing back in 2021, and thus the 1400 probably needs to be defaulted to something else now. |
That's because you are now on TCP (proto tcp4-client), in 2021 you were on UDP.
Also because of that it makes no sense to handle with MSSfix and Fragment, that is for UDP.
With tunnel-proto TCP you have no ping black-holes or ghost packets.
Setting tunnel MTU to "0" means server and client try to find best setting by themselfes, what can work.
In your case it works, it looks like you have under Setup/Basic Setup an eth0-MTU of 1500 and for openVPN-tunnel with TCP4 thats the correct value (egc and I myself have 1492, depends on your ISP).
| Quote: | PING 172.16.1.16 (172.16.1.16) 1473(1501) bytes of data.
ping: local error: message too long, mtu=1500 |
Means to send a 1473 data-packet you need a MTU of 1501, but you only have MTU of 1500 so packet is too big.
You mix up MTU und ping-packet-size(= only the data-size).
(in your 2021 posting you know that, but you maybe forgot . )
OK, best you check your ISP-MTU with a don't-fragment ping to internet (maybe 9.9.9.9), if you can go up to 1472, your MTU 1500 is ok (for eth0 and Tunnel MTU).
I have non-fragment ping 1464 so my MTUs are both 1492.
I switched to tunnel proto TCP for the same reason, as MTU-settings with UDP are a pita.
But I'm still on an old 55 build with my site-to-site Bridge (TAP), but will update to newest build soon and then I will give UDP a new try. |
|