> >> I think [dhcp uses bpf] because it needs to know which interface the
> >> packet arrived on, and there traditionally hasn't been a way to find
> >> this out about UDP packets.  [...]
> >> 
> >> If NetBSD already has a way to identify the incoming interface for an
> >> IP datagram it could probably be put to use.
> >
> >It looks as though setting IP_RECVIF with setsockopt (level IPPROTO_IP,
> >if I've read the code right) should do this - search for IP_RECVIF and
> >INP_RECVIF in /sys/netinet for full details.
> 
> so...it would seem that with proper use of IP_RECVIF/INP_RECVIF and
> IP_RECVDSTADDR/INP_RECVDSTADDR, one can find out on which interface
> and at which address a udp datagram was received.
> 
> not having dug too deeply into dhcpd or the protocol, however, i
> remain unconvinced that not knowing the actual source hardware is
> acceptable.  doesn't dhcpd need to know that in order to send the
> reply?  and won't it need to use a bpf in order to do so?

No.  You need to know the incoming hardware the packet arrived on to
assign an address to the host, so I hope this is what IP_RECVIF is
telling you.  Once you've assigned the address, however, you now have
the host's MAC address (from the dhcp packet), the interface the host
is attached to (IP_RECVIF?) and the host's new IP address (you assigned
it) and you have several ways to send a packet back using this.

The way sending the response back is usually accomplished is to manually
add an ARP entry for the host at its new address, if the incoming interface
was an ethernet, or to configure the arrival interface's destination
with the new address if the incoming interface was point-to-point.  Then
you can send the response back addressed to the host's new address on
a regular UDP socket.  In fact just broadcasting the response back will
work as well, too, the client is required to verify that the response is
to its own request from the contents of the dhcp packet in any case.

Dennis Ferguson