[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/46907: evbarm/sheevaplug: built-in dhcpd in -current ignores all incoming packets
The following reply was made to PR port-arm/46907; it has been noted by GNATS.
From: Masanobu SAITOH <msaitoh%execsw.org@localhost>
Cc: michel.belleau%malaiwah.com@localhost, gnats-admin%netbsd.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)
> System: NetBSD net01 6.99.10 NetBSD 6.99.10 (SHEEVAPLUG) #5: Tue Aug 28
> 20:56:04 EDT 2012
> Architecture: arm
> Machine: evbarm
> 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
> 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).
> Start the built-in dhcpd and look at the error messages in
> /var/log/messages when clients are asking for DHCP leases.
> 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
Main Index |
Thread Index |