> >Dennis's analysis seems dead-on to me.  The fix would be to have some
> >kind of BSD Sockets API extension that could be used to identify the
> >arriving interface for DHCP REQUEST packets.  Ideally, such an 
> >extension would be coordinated with the other *BSD kernel folks,
> >so it could be more widely implemented than just NetBSD.
> 
> i don't think so, if you consider what dhcpd is doing.
> 
> a host with *no ip address* is requesting an ip address.  it's sending
> a request for this ip address to, effectively, a link local ip
> broadcast address.  it does us very little good to know that the
> datagram was received at that ip address, since we (a) can't respond
> from that ip address, (b) can't respond to the ip address the request
> came from, and (c) we'll be receiving packets on every interface bound
> for that address.  the use of bpf here is, as i understand things,
> mandatory, since the *only* valid identifier we have for the requestor
> is the ethernet address and the only way to use it properly to send
> the response back is via bpf.

No....

The host has to 'invent' an IP address to put into the dhcp request!
One lot of code I had picked a random address from 10.0.0.x (just hoping
it wasn't valid on that network).  However using 0.0.0.0 worked ok (after
I changed it).

What happens if you call sendto(fd,packet,l,MSG_DONTROUTE,tgt,t_len)?
(I've never looked that deeply into IP, the iso stacks don't do that
sort of routing)

Maybe you need another flag bit to indicate that the hardware address
is lurking in the target address buffer.
An extra option for setsockopt() could be used to request that the relevant
hardware address be included in the address buffer returned by recvfrom().

The dhcpd code wouldn't necessarily have to parse the remove address buffer.
(except maybe it needs the interface name?)

    David