dhcpd sending on the same IP it receives on

[John Wobus]

>> 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?

John Wobus