Re: bin/46907: evbarm/sheevaplug: built-in dhcpd in -current ignores all incoming packets

[Masanobu SAITOH <msaitoh%execsw.org@localhost>]

The following reply was made to PR port-arm/46907; it has been noted by GNATS.

From: Masanobu SAITOH <msaitoh%execsw.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: michel.belleau%malaiwah.com@localhost, gnats-admin%netbsd.org@localhost, 
 netbsd-bugs%netbsd.org@localhost, msaitoh%execsw.org@localhost
Subject: Re: bin/46907: evbarm/sheevaplug: built-in dhcpd in -current ignores
 all incoming packets
Date: Wed, 05 Sep 2012 12:13:38 +0900

 (2012/09/05 11:00), michel.belleau%malaiwah.com@localhost wrote:
 >> Number:         46907
 >> Category:       bin
 >> Synopsis:       built-in dhcpd in -current ignores all incoming packets 
 >> (bad checksum)
 >> Confidential:   no
 >> Severity:       serious
 >> Priority:       medium
 >> Responsible:    bin-bug-people
 >> State:          open
 >> Class:          sw-bug
 >> Submitter-Id:   net
 >> Arrival-Date:   Wed Sep 05 02:00:00 +0000 2012
 >> Originator:     Michel Belleau
 >> Release:        NetBSD 6.99.10 (2012-09-01)
 >> Organization:
 >      malaiwah.com
 >> Environment:
 > System: NetBSD net01 6.99.10 NetBSD 6.99.10 (SHEEVAPLUG) #5: Tue Aug 28 
 > 20:56:04 EDT 2012 
 > root@littlemoon.malaiwah.local:/root/netbsd/src/sys/arch/evbarm/compile/obj/SHEEVAPLUG
 >  evbarm
 > Architecture: arm
 > Machine: evbarm
 >> Description:
 >      I compiled NetBSD-current (2012-09-01 cvs) and installed it on my two 
 > Seagate Dockstar little boxes (little endian); these are just like 
 > SHEEVAPLUGs. They are running fine; I can mount /usr/pkgsrc with NFS and 
 > even do compile, this proves me that networking and general health of the 
 > build is OK.
 >      I tried setting up a DHCP server with the built-in "dhcpd", but it 
 > fails to give leases to clients, complaining about bad IP checksums.
 >      I believe the hardware and network stack is fine because NFS just plain 
 > works, simple Netcat between hosts shows that UDP works and does not corrupt 
 > things (I transfered a couple of files through netcat with no issue).
 >      I went to IRC to get some help, but we concluded that there was a 
 > software bug in dhcpd.
 >      netstat shows no errors whatsoever.
 > 
 > Here is the exact message thrown by dhcpd:
 > 5 bad IP checksums in 5 packets
 > 
 > Here is the corresponding DHCP request viewed with tcpdump (interface is 
 > mvgbe0):
 > 01:53:04.284685 IP (tos 0x0, ttl 255, id 64419, offset 0, flags [none], 
 > proto UDP (17), length 328)
 >      0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 
 > 5c:95:ae:0b:3b:90, length 300, xid 0xcc6faa64, Flags [none]
 >            Client-Ethernet-Address 5c:95:ae:0b:3b:90
 >            Vendor-rfc1048 Extensions
 >              Magic Cookie 0x63825363
 >              DHCP-Message Option 53, length 1: Request
 >              Parameter-Request Option 55, length 6:
 >                Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
 >                Option 119, Option 252
 >              MSZ Option 57, length 2: 1500
 >              Client-ID Option 61, length 7: ether 5c:95:ae:0b:3b:90
 >              Requested-IP Option 50, length 4: 192.168.15.86
 >              Lease-Time Option 51, length 4: 7776000
 > 
 > I made a hack-patch to skip the IP checksum check and display more 
 > information about the packet that BPF sends down to dhcpd:
 > DEBUG: sizeof (bpf_hdr) = 20
 > DEBUG: interface -> rbuf_len = 368
 > DEBUG: hdr -> bh_caplen = 346
 > DEBUG: hdr -> bh_datalen = 346
 > DEBUG: hdr -> bh_hdrlen = 22
 > DEBUG: new offset = 14
 > ip length 328 disagrees with bytes received 332.
 > accepting packet with data after udp payload.
 > 5 bad udp checksums in 5 packets
 > 
 >      The received packet is really 328 (as per tcpdump), not 332. It looks 
 > like there is an extra 4 bytes that is tacked to the packet somehow; is that 
 > an alignment of some sort, this beats me I don't know.
 > 
 >      I also think that we might have the same bug affecting bind99 (I 
 > suspect it shares some code with dhcpd as those two products are ISC); I had 
 > set up slave zones and it looks like the box is just ignoring the zone 
 > transfers contents (the other side says it is fine) and eventually times-out 
 > (no records received).
 >> How-To-Repeat:
 >      Start the built-in dhcpd and look at the error messages in 
 > /var/log/messages when clients are asking for DHCP leases.
 >> Fix:
 >      I tried various fixes, but none worked; I don't know how to deal with 
 > those mysterious 4 bytes.
 > 
 >      I'm available to help ironing this bug out, the hardware is sitting in 
 > my home lab with no production on it for the moment.
 
  Thank you for your report. This problem will fix when PR#46898 is fixed.
 
 -- 
 -----------------------------------------------
                 SAITOH Masanobu (msaitoh%execsw.org@localhost
                                  msaitoh%netbsd.org@localhost)