DHCPOFFER sent to wrong MAC?

[George C. Kaplan]

David W. Hankins wrote:
> On Fri, Aug 18, 2006 at 11:08:20AM -0400, Jason Lixfeld wrote:
>>         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.

This discussion rings a bell.  I saw some weird broadcast-related
behavior on FreeBSD 6.0 a few months back.  That was with a dhcp client
sending unicast renewal packets (normal), that were going on the wire
with a broadcast Ethernet address.  See the attached tcpdump packet trace.

I'll follow up with the owner of that FreeBSD 6.0 system to see if he
found out anything useful.  Perhaps there's some weirdness in the
FreeBSD 6 TCP/IP stack or some of the Ethernet drivers?

-- 
George C. Kaplan                            gckaplan at ack.berkeley.edu
IST - Infrastructure Services               510-643-0496
University of California at Berkeley