DHCPOFFER sent to wrong MAC?

[David W. Hankins]

On Fri, Aug 18, 2006 at 11:08:20AM -0400, Jason Lixfeld wrote:
> Is this a configuration glitch on my end or is something else wrong?   

Well, there's nothing unusual in your packet traces (aside from the
problem you're having), so it's a bit odd that no one else on the
planet is having this problem.  But I'm sure there are people running
6.1 without this issue.

I presume you had this problem before you switched to the custom
kernel?


Can you:

	md5 /usr/ports/net/isc-dhcp3-server/files/*

and paste the results?

>          0... .... .... .... = Broadcast flag: Unicast

See that?  It's a bit odd that your server clearly chooses to send
this packet to 255.255.255.255 later on.  If it's using BPF sockets,
which should be the default, it can craft a unicast local
transmission without an ARP...it just fills in the header fields
with what it knows.

Unless something odd is over-writing these layers after the fact.

> Frame 29 (347 bytes on wire, 347 bytes captured)
> Ethernet II, Src: 3com_d1:c9:f0 (00:50:04:d1:c9:f0), Dst:  
> Cisco_bb:c6:a1 (00:05:9b:bb:c6:a1)
>      Destination: Cisco_bb:c6:a1 (00:05:9b:bb:c6:a1)
>      Source: 3com_d1:c9:f0 (00:50:04:d1:c9:f0)
>      Type: IP (0x0800)
>      Frame check sequence: 0x94468004 [correct]
> Internet Protocol, Src: 192.168.100.10 (192.168.100.10), Dst:  
> 255.255.255.255 (255.255.255.255)

That's just weird.

If 255.255.255.255 were used, the server would be in broadcast mode.
In broadcast mode, NULL is passed for the hardware address, and '0xff'
is memset() into the field to make an ethernet broadcast address,
rather than a memcpy() from any location.

But in order to even be in broadcast mode, as I said, you have to
be using BSD sockets rather than BPF, and /usr/ports builds the
DHCP software to use BPF.

The hardware address field itself is memcpy'd from a field that's
also copied to the bootp 'chaddr' field.  So it's triply weird
that your 'chaddr' field doesn't match the destination mac here.

So I just can't explain this as dhcpd behaviour.  At least not
unless there is something very wrong happening in your ports
patches, or if some unknown external entity is rewriting these
packets inbetween.

Like if your switch were trying to be clever.

So compare the switch spanned results with what you get by
tcpdumping directly on the dhcp server.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email training at isc.org.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins