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

[michel.belleau%malaiwah.com@localhost]

>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.