Phil Mayers wrote:
Perhaps I've misunderstood, but this doesn't reflect the DHCP behaviour I've seen on "normal" clients.
It's possible.
As far as I know, it goes (starting from INIT, as opposed to INIT-REBOOT which effectively starts from step 4):
1. Client sends DISCOVER to broadcast 2. NAS forwards to server; giaddr==1, srcip==2 3. Server sends DHCPOFFER; dstip==giaddr, server_id=$SERVER 4. Repeat 1-3 with DHCPREQUEST/ACK 5. Client comes to t1 - unicast DHCPREQUEST dstip=$SERVER 6. If no reply, at t2 - broadcast DHCPREQUEST
Yes.
i.e. AFAIK, the client *always* sends packets to broadcast or to the server ident (DHCP option 54). Note the latter is mandatory in all DHCP replies.
That's the usual practice... but some clients may be weird.
There are a bunch of subtleties in this whole area - some devices offer knobs to control giaddr in the case of multinettings, and some devices offer knobs to control srcip - but, in my experience, you are asking for trouble if giaddr is not valid for accepting relayed replies. We've had significant problems with setups where this is difficult or impossible to achieve as a result. Multinetting a private and public range onto the same interface falls into exactly that category.
Yes. Maybe I got parts of the explanation wrong, but the DHCP handling of giaddr is just weird. Alan DeKok.