Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Oct 2007 20:25:09 +0200
From:      Kris Kennaway <kris@FreeBSD.org>
To:        Jack Vogel <jfvogel@gmail.com>,  freebsd-net@freebsd.org
Subject:   em driver sending bad packet lengths
Message-ID:  <470FBC05.6010601@FreeBSD.org>

next in thread | raw e-mail | index | archive | help
I am seeing the em driver on 7.0 sending packets with bad UDP (and 
apparently sometimes IP) packet length fields.  This is from UDP NFS 
traffic (90MB/sec over gige).  These packets are dropped on reception by 
the kernel and counted.

Here is a tcpdump trace showing some bad packets:

17:50:27.912629 IP bad-len 0
17:50:27.912748 IP bad-len 0
17:50:27.912764 IP bad-len 0

I havent yet caught a better tcpdump of the UDP bad packets but they are 
logged by netstat -s

hydra1# netstat -s -p udp
udp:
         120091992 datagrams received
         0 with incomplete header
         1775 with bad data length field
         ^^^^
         14840 with bad checksum
         0 with no checksum
         16 dropped due to no socket
         258 broadcast/multicast datagrams undelivered
         0 dropped due to full socket buffers
         0 not for hashed pcb
         120075103 delivered
         120190737 datagrams output
         0 times multicast source filter matched

Disabling txcsum and rxcsum didnt help.

em0: <Intel(R) PRO/1000 Network Connection Version - 6.5.3> port 
0x2000-0x201f mem 0xd8a00000-0xd8a1ffff irq 18 at device 0.0 on pci4
em0: Ethernet address: 00:30:48:33:54:ca
em0: [FILTER]

em0@pci4:0:0:   class=0x020000 card=0x000015d9 chip=0x10968086 rev=0x01 
hdr=0x00
     vendor     = 'Intel Corporation'
     device     = 'PRO/1000 EB Network Connection'
     class      = network
     subclass   = ethernet

em0: <Intel(R) PRO/1000 Network Connection Version - 6.5.3> port 
0x4000-0x401f mem 0xe1000000-0xe101ffff irq 16 at device 0.0 on pci18
em0: Ethernet address: 00:30:48:8f:55:48
em0: [FILTER]

em0@pci18:0:0:  class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 
hdr=0x00
     vendor     = 'Intel Corporation'
     device     = 'PRO/1000 PM'
     class      = network
     subclass   = ethernet

The second-order effect from this is that our NFS client currently 
misbehaves when UDP packets are dropped, and this leads to data corruption.

Kris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?470FBC05.6010601>