3c59x 2.4.18 userspace seeing UDP packets with bad checksum?

[bert hubert <ahu@ds9a.nl>]

On Tue, Jul 30, 2002 at 04:40:38PM +0400, kuznet@ms2.inr.ac.ru wrote:
> Hello!
> 
> > I'm under the strong impression that 2.4.18 lets userspace see packets with
> > incorrect UDP checksums.
> 
> How did you get this impression?

The hardware:

3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
01:02.0: 3Com PCI 3c905C Tornado at 0xd800. Vers LK1.1.16
01:02.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink]
(rev 78)

The packet is subtly corrupted and contains an invalid DNS label which our
nameserver tripped over (oops). It looks like a single byte error. PowerDNS
lives inside a wrapper, once every second the wrapper calls wait(), to see
if the child is well:

Jul 30 07:04:44 knife pdns-powerdns[2983]: Our pdns instance (6595) exited
after signal 11

These are the relevant packets, grouped by question/answer.

07:04:42.902162 200.171.175.165.14760 > 213.244.168.217.53:  [udp sum ok]
4170 CNAME? ifm.com.br. [|domain] (ttl 112, id 41767, len 56)

07:04:42.902198 213.244.168.217.53 > 200.171.175.165.14760:  [udp sum ok]
4170*- q: CNAME? ifm.com.br. 0/0/0 (28) (DF) (ttl 64, id 0, len 56)

==

07:04:43.147215 202.239.113.18.56146 > 213.244.168.217.53:  [udp sum ok]
32295 A? failte.powernap.org. [|domain] (ttl 241, id 11501, len 65)

07:04:43.149494 213.244.168.217.53 > 202.239.113.18.56146:  [udp sum ok]
32295*- q: A? failte.powernap.org. 1/0/0 failte.powernap.org. A 213.106.2.65
(53) (DF) (ttl 64, id 0, len 81)

==

This is the packet I mean. Note that no answers are sent out after this
one:

07:04:43.505166 61.222.31.205.62361 > 213.244.168.217.53:  [bad udp cksum
25f1!] 49 op5 [2a][|domain] (ttl 112, id 51330, len 109)

== 

07:04:43.698853 194.25.2.147.34441 > 213.244.168.217.53:  [udp sum ok] 53889
[1au] AAAA? DNS-EU1.POWERDNS.NET. . OPT  UDPsize=4096 (49) (DF) (ttl 248, id
23358, len 77)

==

07:04:43.699074 194.25.2.147.34441 > 213.244.168.217.53:  [udp sum ok] 32420
[1au] A6 ? DNS-EU1.POWERDNS.NET. . OPT  UDPsize=4096 (49) (DF) (ttl 248, id
23359, len 77)

==

Until a few seconds later when the parent respawns a new PowerDNS.

> > Is this policy?
> 
> This is impossible unless requested explicitly with SO_NO_CHECK
> or a buggy hardware incorrectly reports checksum is valid.

We don't supply SO_NO_CHECK. As the driver source mentions hardware
checksumming I've cc'd in Andrew, Donald & Jeff.

Regarding Andi's message, isn't it so that recvfrom() may return but in that
case returns -1 and sets errno to EAGAIN? I've seen that when trying to
reproduce this bug by using tcpreplay.

Anything I can do to help, let me know. I get in the order of 20 of these
corrupted packets each night from our Taiwanese friends at Hinet, and only
at night.

Netstat -s output after 81 days:

Udp:
    112974784 packets received
    10386 packets to unknown port received.
    3840 packet receive errors
    112889199 packets sent

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO