dhcpd sending on the same IP it receives on
bakers at web-ster.com
Wed Dec 12 22:47:59 UTC 2007
Simon Hobson wrote:
> Phil Mayers wrote:
>> I have tried to use dhcpd in various policy-routed ways in the past,
>> and it is hard. It would be nice if dhcpd behaved in a similar manner
>> to bind/named and ntpd, and bound a file descriptor to each IP
>> (re-discovering the IPs every N minutes) and always replied via the
>> same file descriptor the request came in on.
> Can it always do that ?
> bind and ntpd have the luxury of only ever dealing with unicast packets,
> dhcpd must deal with broadcast packets.
> Also, back to the original problem, I would suggest that the devices
> being fussy are broken ! It is valid and legal to set the server address
> to a broadcast address and hence have the packets 'delivered' to
> multiple servers. Since it is (in the general case) not possible* to
> determine whether an address is a broadcast address they should not
> assume or expect replies to return from the address they sent the
> request to.
> * Well you can infer that a zero lsb of the address means that it can't
> be a broadcast. And you can infer that if the next bit is zero then it's
> highly unlikely that it's a broadcast address. But that's about it.
In my case our DHCP server is ONLY acting as a DHCP-Relay receiver.
There is no broadcast DHCP packets coming in. That is mentioned
specifically in the documentation.
The local-address statement
This statement causes the DHCP server to listen for
DHCP requests sent to the specified address, rather than requests
sent to all addresses. Since serving directly attached DHCP
clients implies that the server must respond to requests sent to the
all-ones IP address, this option cannot be used if clients are on
directly attached net-works...it is only realistically useful for
a server whose only clients are reached via unicasts, such as
via DHCP relay agents.
Scott Baker - Canby Telcom
RHCE - System Administrator - 503.266.8253
More information about the dhcp-users