Re: em driver sending bad packet lengths

You should a couple different adapters below, are you saying that
its just one of them, can you try different ones to see if its specific.

Also, would you be able to test my latest driver to see if it still
happens?

Cheers,

Jack


On 10/12/07, Kris Kennaway <kris@xxxxxxxxxxx> wrote:
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

_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Update: UDP 770 Potential Worm
    ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
    (Incidents)
  • Re: Overhead, UDP: Many packets on 1 socket vs. one packet and many ?sockets.
    ... a gigabit LAN network using UDP. ... into "frames" and each device frame is a single UDP packet. ... information in the data packets. ... over each of those sockets. ...
    (comp.unix.programmer)
  • Re: Determining if it is "safe" to send UDP packets
    ... IMHO for "reliable" UDP you need to use some Quality of service ... Maybe your network is QoS enabled and your traffic gets classified as "below ... > the sender's OS that is throwing the UDP packets away. ... > next 100%-x% are not send, they are almost all completely lost. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Loosing UDP packets...
    ... The applications I support send lots of UDP via ... Sometimes all the packets hit the wire, ... Perhaps that is only for a non-blocking socket - per my stuff above? ... as I don't send> MTU datagrams. ...
    (comp.os.linux.networking)
  • Overhead, UDP: Many packets on 1 socket vs. one packet and many sockets.
    ... gigabit LAN network using UDP. ... information in the data packets. ... Create a new socket for each of these new pieces of data. ...
    (comp.unix.programmer)