From owner-freebsd-stable@FreeBSD.ORG Thu Nov 11 19:01:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B2901065673 for ; Thu, 11 Nov 2010 19:01:35 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD4A8FC08 for ; Thu, 11 Nov 2010 19:01:34 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:b11b:8f5:3197:8539] ([IPv6:2607:f3e0:0:4:b11b:8f5:3197:8539]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id oABJ1RZu003156 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 11 Nov 2010 14:01:27 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4CDC3D7B.7000108@sentex.net> Date: Thu, 11 Nov 2010 14:01:15 -0500 From: Mike Tancsa User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20101111052656.21C0E1CC0E@ptavv.es.net> In-Reply-To: <20101111052656.21C0E1CC0E@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 19:01:35 -0000 On 11/11/2010 12:26 AM, Kevin Oberman wrote: >> Date: Thu, 11 Nov 2010 13:01:26 +0800 >> From: "Wilkinson, Alex" >> Sender: owner-freebsd-stable@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@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@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