dhcpd sending on the same IP it receives on
jw354 at cornell.edu
Tue Feb 5 21:41:29 UTC 2008
>> It would be nice if the DHCP server were to respond to unicast
>> requests using the address to which the request was sent, but if I
>> recall correctly that's not quite as trivial a code change as one
>> might hope.
> It's sounding like there's no easy fix for this, I'll submit a bug and
> maybe it'll be resolved in future releases. Proper TCP/IP behavior is
> something that should be aimed for. =)
Is what you imply truly "Proper TCP/IP behavior"? Or is it an
expectation of IP-stack-DWIM behavior? The packet that the daemon
sends back does have the proper destination IP address. The stack is
configured with your simple routing configuration (a default route)
that instructs it what to do with such a packet.
To do what you want, somehow the stack is expected to know the IP
address of this other (non-default) router that you want to send this
particular packet through. That IP address is not evident from the
incoming packet. It would either have to be preconfigured or you'd
have to infer it by scanning your ARP table.
I occasionally talk to people who want their app to do this sort of
thing. It seems possible with a sufficiently rich OS and networking
interface, since you could certainly virtualize, and run two copies of
the daemon in two separate operating system instances, each with its
own interface, and each with its own (preconfigured) default route.
Someone once suggested to me that some host-based-firewalls can be
configured to set up temporary routes to make a server do this sort of
thing. Can anyone here confirm this? Does anyone do such a thing with
the ISC DHCP server?
More information about the dhcp-users