Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[David Haller]

Hello,

On Tue, 20 Sep 2016, Grant wrote:
[..]
>> $ ping -n -c 1 -M dont -s 1465 www.dslreports.com
>> PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
>> 1473 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=137 ms
>>
>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>> rtt min/avg/max/mdev = 137.888/137.888/137.888/0.000 ms
>>
>> ==== corresponding tcpdump -n -i eth0 icmp ====
>> 15:47:07.983484 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3595, seq 1, length 1472
>> 15:47:07.983494 IP 192.168.178.11 > 64.91.255.98: icmp
>> 15:47:08.121308 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3595, seq 1, length 1472
>> 15:47:08.121343 IP 64.91.255.98 > 192.168.178.11: icmp
>> ====
>>
>>
>> Two packets sent and received for 1493 bytes packet size / 1465 bytes
>> ping-payload.
>>
>> Try with e.g. 'ping -c 4 -M dont -s 1472 www.dslreports.com' for
>> yourself to see, that you'll send/recv 2 packets for each ping-packet
>> (and 1472 bytes is the ping-payload that just fits into the standard
>> 1500 bytes MTU).
>
>
>Strangely, I'm able to ping with that command even with a very high -s value:
>
>$ ping -c 4 -M dont -s 9999 www.dslreports.com
>PING www.dslreports.com (64.91.255.98) 9999(10027) bytes of data.
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
>time=331 ms
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
>time=329 ms
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
>time=329 ms
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
>time=329 ms
>
>4 packets transmitted, 4 received, 0% packet loss, time 3003ms
>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms

Look again! You're just looking at the _PING_ packets, not the ICMP/IP
packets actually going over the interface! You'll need to run 
'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but
there's two IP packets actually going over the interface, due to the
ping-packet being too large and being fragmented.

Start the tcpdump in another (x)term before running the "ping" ...

If you use '-M do', you should get the

    "Frag needed and DF set (mtu = NNNN)"

error from ping. "-M dont" explicitly allows fragmentation, which you
can then see with tcpdump. E.g. a with my MTU of 1492, a

==== ping -n -c 1 -M dont -s 9999 192.168.178.1 ====
PING 192.168.178.1 (192.168.178.1) 9999(10027) bytes of data.
10007 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=2.79 ms

--- 192.168.178.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.795/2.795/2.795/0.000 ms
====

results in

==== tcpdump -n -i eth0 icmp ====
17:40:11.901583 IP 192.168.178.11 > 192.168.178.1: ICMP echo request, id 11363, seq 1, length 1472
17:40:11.901597 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901599 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901600 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901602 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901603 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901605 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.903762 IP 192.168.178.1 > 192.168.178.11: ICMP echo reply, id 11363, seq 1, length 1480
17:40:11.903779 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.903984 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.903997 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.904227 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.904241 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.904338 IP 192.168.178.1 > 192.168.178.11: icmp
====

Yes, that is just the _one_ ping packet.

Read up on the links I gave you about fragmentation and IP(v4) in
general a bit ;) It's much better described there than I could ATM.

Which does not mean not to ask for stuff that's unclear.

HTH,
-dnh, who seems to have a knack for translating "techese" to normal
    language ... Actually, I guess fragmentation can be explained
    quite nicely by comparing to real-life packets ;) You'd get an
    basically unlimited supply of courier boys, but you can get just
    so many incoming and outgoing through the doors ;)

    *grepping out the appropriate sig for that*

-- 
No trees were destroyed in the sending of this message, however, a 
significant number of electrons were terribly inconvenienced.