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

It doesn't matter.  The client is required to put its MAC address in
the dhcp packet payload so it is always available there.

> and...if the address isn't on the local network, then adding an arp
> entry will fail, no?

Which address?  If we're talking about the IP address, then you're the
server which assigned the address and something is broken if the address
you assigned isn't on the interface's subnet.  If we're talking about the
MAC address, however, then ARP doesn't care what it is and won't fail
to add an ARP entry because of it.

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

As I noted you could always broadcast the response back instead if you
felt some need to do it this way.

I don't get what the issue is, however.  The host which sends the request
is required to put its MAC address in the dhcp payload.  The same host is
required to use its MAC address as the source address in the ethernet
header.  If the host lies about his MAC address in the dhcp payload it
won't work, but the host could just as easily lie about his MAC address
in the ethernet header so I'm not sure why that one would be better.  It
is the same host putting the address in both places, so if it really wants
to lie to you it'll just do it in both places and you'll never know.  The
host could also legitimately have more than one MAC address (sometimes
routers do this), but in this case if there is a difference between payload
and the ethernet MAC address you are required to use the payload MAC
address since this is the one the host has told you to base its configuration
on.  And, if none of the above, then the host may just be confused, but
there's no way the protocol can determine or fix a host which is sufficiently
confused in any case, which still leaves you using the payload MAC address
since the host may not be confused and may just have several MAC addresses.

I don't see any problem which is fixed by looking at the source address
in the ethernet header.  The protocol certainly doesn't require it, in
fact it seems to require that you don't do this.

Dennis Ferguson