> Jim Wise <jwise@draga.com> writes:
> > The problem is, unlike the other udp ports which dhcpd(8) uses (67,
> > 111), dhcpd does _not_ listen on port 68.  It appears that it is using
> > bpf to snatch packets directly from the wire.
> 
> Why does it need to do that, anyway? Is there a good reason for it?
> My suspicion is that it is done only so it can get the MAC address of the
> requester or some such, and there should reasonably be a better way to
> deliver such information to an application.

It already knows the MAC address it needs, it is included in the dhcp
request packet.

I think it does this 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.  Bpf is the workaround, I think, it knows the interface
the packet arrived on since you open it on the interface (routing protocols
often have the same requirement, but have traditionally worked around the
inability to learn the incoming interface explicitly by the sleazy cheat
of guessing at it from the addresses in the packet; this doesn't work for
dhcp, however, since the sending host doesn't usually know his address and
puts nothing useful in the packet). 

If NetBSD already has a way to identify the incoming interface for an IP
datagram it could probably be put to use.  It NetBSD doesn't have a way to
do this then it should probably acquire one; the functionality is generically
useful.  Being able to bind unicast sockets to particular interfaces, sort
of like the multicast code does, is sometimes useful as well since it allows
the process to avoid seeing datagrams from interfaces other than the ones it
is configured on.

Dennis Ferguson