icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]

Mike Tancsa mike at sentex.net
Thu Nov 11 19:01:35 UTC 2010


On 11/11/2010 12:26 AM, Kevin Oberman wrote:
>> Date: Thu, 11 Nov 2010 13:01:26 +0800
>> From: "Wilkinson, Alex" <alex.wilkinson at dsto.defence.gov.au>
>> Sender: owner-freebsd-stable at freebsd.org
>>
>>
>>     0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: 
>>
>>     >All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes.
>>     >
>>     >On stable 7.2 the same hardware works as expected:
>>     ># ping -s 1500 192.168.64.99
>>     >PING 192.168.64.99 (192.168.64.99): 1500 data bytes
>>     >1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms
>>     >1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms
>>     >
>>     >Here is the dump on em interface
>>     >15:06:31.452043 IP 192.168.66.65 > *****: ICMP echo request, id 28729, seq 5, length 1480
>>     >15:06:31.452047 IP 192.168.66.65 > ****: icmp
>>     >15:06:31.452069 IP **** > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480
>>     >15:06:31.452071 IP *** > 192.168.66.65: icmp
>>     > 
>>     >Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable
>>     >#pciconf -lv
>>     >em0 at pci0:3:4:0:	class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00
>>     >    vendor     = 'Intel Corporation'
>>     >    device     = 'Dual Port Gigabit Ethernet Controller (82546EB)'
>>     >    class      = network
>>     >    subclass   = ethernet
>>     >
>>     ># ping -s 1472 192.168.64.200
>>     >PING 192.168.64.200 (192.168.64.200): 1472 data bytes
>>     >1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms
>>     >^C
>>     >
>>     ># ping -s 1473 192.168.64.200
>>     >PING 192.168.64.200 (192.168.64.200): 1473 data bytes
>>     >^C
>>     >--- 192.168.64.200 ping statistics ---
>>     >4 packets transmitted, 0 packets received, 100.0% packet loss
>>
>> works fine for me:
>>
>> FreeBSD 8.1-STABLE #0 r213395
>>
>> em0 at pci0:0:25:0:class=0x020000 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = 'Intel Gigabit network connection (82567LM-3 )'
>>     class      = network
>>     subclass   = ethernet
>>
>> #ping -s 1473 host
>> PING host(192.168.1.1): 1473 data bytes
>> 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms
>> 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms
>> 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms
>> ^C
> 
> The reason the '-s 1500' worked was that the packets were fragmented. If
> I add the '-D' option, '-s 1473' fails on v7 and v8. Are the V8 systems
> where you see if failing without the '-D' on the same network segment?
> If not, it is likely that an intervening device is refusing to fragment
> the packet. (Some routers deliberately don't fragment ICMP Echos Request
> packets.) 


I am not sure I follow. If you do a
ping -s 1473 -D
on an interface that has the default MTU of 1500, it wont work, as the
entire packet is going to be 1501 (note the data bytes)

eg.
# ping  -q -s 1472 -c 1 192.168.43.219
PING 192.168.43.219 (192.168.43.219): 1472 data bytes

--- 192.168.43.219 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.714/1.714/1.714/0.000 ms
on 192.168.43.219, I see

and on .43.219, I see

0(ich10)# tcpdump -vvvni em2 icmp
tcpdump: listening on em2, link-type EN10MB (Ethernet), capture size 96
bytes
13:49:17.564482 IP (tos 0x0, ttl 63, id 53656, offset 0, flags [none],
proto ICMP (1), length 1500)
    192.168.42.11 > 192.168.43.219: ICMP echo request, id 23315, seq 0,
length 1480
13:49:17.564499 IP (tos 0x0, ttl 64, id 14346, offset 0, flags [none],
proto ICMP (1), length 1500)
    192.168.43.219 > 192.168.42.11: ICMP echo reply, id 23315, seq 0,
length 1480


Note the length is 1500 of the packet.

That being said, if its failing on the em nic where you dont specify the
-D flag on the ping, then there is a bug somewhere.  On certain em nics,
I found doing
ifconfig em0 -rxcsum
ifconfig em0 -txcsum
ifconfig em0 -tso

works around a number of bugs

	---Mike





More information about the freebsd-stable mailing list