>>> 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.
>
>IP_RECVIF gets you the if_index value for the interface in question.
>Mapping that to anything useful is up to the packet recipient.

egad.  i thought it was more useful than that.  i wonder what sort of
issues would be be incurred by *making* it more useful...

>>> The way sending the response back is usually accomplished is to
>>> manually add an ARP entry for the host at its new address, [...p2p
>>> stuff...]
>> and...if the address isn't on the local network, then adding an arp
>> entry will fail, no?
>
>No.  You can add an ARP entry on a "wrong" interface easily enough,
>provided you do it yourself with a routing socket.  (I know this
>because I did it, once - I can babble about the motivation if anyone is
>interested.)  Since DHCP requests are sent as link-layer broadcasts,
>you must actually be in the same broadcast domain as the client, in
>which case the ARP entry will DTRT.  (The p2p case, of course, is
>trivial, as there is only one link-layer address possible.)

i tried adding an arp entry via a routing socket once.  i wasn't sure
of the exact formatting and construction of the routing messages,
though, and thought i could rely on the kernel to repeatedly tell me
EINVAL (or something like that) until i got it right.  i was wrong.
the machine promptly crashed.  i didn't try it again.

what i did expect, however, was that the kernel would not let you add
an arp entry for an ip address which was not "local" to one of the
interfaces.  this is not so?

>> 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.
>
>Even the from-address in the Ethernet header is only what the host
>claims; most Ethernet hardware is quite capable of generating packets
>with a "wrong" address in the Ethernet-header from field.

sure, and some networking hardware is capable of totally screwing it
up anyway, so all bets are off.

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