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

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

(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)