dhcpd sending on the same IP it receives on

[Scott Baker]

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

local-address address;

         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