Open hloeung opened 2 years ago
Is MTU still relevant? Back in the old days MTU was often lower for latency issues. (My first cable-modem talked to the PC through a serial link at 115200.) Nowadays 1500 seems to be used almost everywhere. There was a period when gigabit ethernet cards would support jumbo frames, but nowadays also that has gone.
Anyway... Patch welcome. :-)
Yeah, it's still relevant. We still have clients connected to the Internet via PPPoE (so usually an 8-byte PPP header taking the MTU to 1492). Also traffic via IPsec or OpenVPN which adds it's own headers. Sure, we have jumbo these days, but at what size? 9216 or 9000 or others?
Sure, I'll have a go at a patch implementing something similar to ping's -M (setting sockopt with IP_PMTUDISC_DO, IP_PMTUDISC_DONT, or IP_PMTUDISC_WANT).
MTR probably makes the packet (including header) itself. So setting flags on transmission socket may not do much.
A good reference on what bits to set can be found in the book "tcpip illustrated" by R. Stevens. If you haven't, read the book. (It is a lot of fun for a "textbook" kind of book).
Hi,
traceroute and ping supports don't fragment. For traceroute, that's:
-F, --dont-fragment Do not fragment probe packets. (For IPv4 it also sets DF bit, which tells intermediate routers not to fragment remotely as well).
For ping:
-M pmtudisc_opt Select Path MTU Discovery strategy. pmtudisc_option may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag).
Can we add support in mtr as well? This will be helpful fo MTU mismatch debugging. Maybe even extend mtr to have an option to detect MTU (path MTU discovery) similar to tracepath's --mtu option.