[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
bin/46907: evbarm/sheevaplug: built-in dhcpd in -current ignores all incoming packets
>Synopsis: built-in dhcpd in -current ignores all incoming packets (bad
>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
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]
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.
Main Index |
Thread Index |