On Tue, Jul 30, 2002 at 04:40:38PM +0400, kuznet@xxxxxxxxxxxxx wrote:
> > I'm under the strong impression that 2.4.18 lets userspace see packets with
> > incorrect UDP checksums.
> How did you get this impression?
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]
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: Our pdns instance (6595) exited
after signal 11
These are the relevant packets, grouped by question/answer.
07:04:42.902162 126.96.36.199.14760 > 188.8.131.52.53: [udp sum ok]
4170 CNAME? ifm.com.br. [|domain] (ttl 112, id 41767, len 56)
07:04:42.902198 184.108.40.206.53 > 220.127.116.11.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 18.104.22.168.56146 > 22.214.171.124.53: [udp sum ok]
32295 A? failte.powernap.org. [|domain] (ttl 241, id 11501, len 65)
07:04:43.149494 126.96.36.199.53 > 188.8.131.52.56146: [udp sum ok]
32295*- q: A? failte.powernap.org. 1/0/0 failte.powernap.org. A 184.108.40.206
(53) (DF) (ttl 64, id 0, len 81)
This is the packet I mean. Note that no answers are sent out after this
07:04:43.505166 220.127.116.11.62361 > 18.104.22.168.53: [bad udp cksum
25f1!] 49 op5 [2a][|domain] (ttl 112, id 51330, len 109)
07:04:43.698853 22.214.171.124.34441 > 126.96.36.199.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 188.8.131.52.34441 > 184.108.40.206.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
Netstat -s output after 81 days:
112974784 packets received
10386 packets to unknown port received.
3840 packet receive errors
112889199 packets sent
http://www.PowerDNS.com Versatile DNS Software & Services
http://www.tk the dot in .tk
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO