>>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)"
I switched to '-M do' and found that 1464 is the highest size I can ping without the "Frag needed" error. This means I should add 28 to that and set my MTU to 1492 across the network? - Grant > 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*
