>> 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.

it looks to me like that'll tell me on which interface i received the
given packet, and my hardware address on that interface as well,
though not necessarily the hardware address the packet came to me
from.

>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.

and...if the address isn't on the local network, then adding an arp
entry will fail, no?  i ought still to be able to answer such a dhcp
request, no?  i'm stuck on seeing the possibility of a discrepancy
between the link layer address that the packet comes from and the link
layer address as embedded in the dhcp packet itself...kinda like the
way that the arp subsystem can't properly tell you from which hardware
address an erroneous arp datagram originated...just what that host
claimed to be at in the arp data.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."