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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
