Seppo Sandberg wrote:

Hello,

maybe I'll try and rephrase my question. Which attribute should I modify with update reply, e.g. in dhcp DHCP-Discover section of the sites-available/dhcp file, if I wanted to redirect the message to another DHCP server?

You can't. DHCP relaying is not supported. It shouldn't be hard to add, though. Patches are welcome. Alan DeKok.

Seppo Sandberg wrote:

If I was inclined to create such a patch how would we begin to tackle the issue? I guess you would tell me how you would like to have it implemented?

See src/main/dhcpd.c Look for "relay". Add a cache (hash table or rbtree) for XID, and maybe (XID,MAC). Add entries to the cache on forward, remove entries on reply. As a second step, tie the entries to the REQUEST structure, so that they get deleted when the REQUEST times out. That way you don't need to do timeouts in the relay code, and the server isn't subject to a DoS attack. Alan DeKok.

Phil Mayers wrote:

What's the rationale for keeping state?

Some security, IIRC.

I was under the impression that DHCP relays could be stateless. Since you can chain relays, but replies go straight back to the first one (via the giaddr field)

Yes. The ISC DHCP relay code doesn't store any state. But there *is* logic to add/delete relay options, and to check the giaddr field... That would need to be added, at least. For our purposes, storing state would allow us to know where to send the reply. The ISC server walks through it's list of interfaces for every reply. This is simple, but it would be safer to maintain state. Alan DeKok.

Seppo Sandberg wrote:

Is the bottom line that when implementing the dhcp relay there should be caching included?

Start off without it. If it works... it's good enough.

What data exactly should be stored in the cache?

I'll have to think about that. Alan DeKok.

Seppo Sandberg wrote:

...

Start off without it. If it works... it's good enough.

When I require any further pieces of information on this matter what would be the preferred way of communication, e.g. should I keep using this thread or open a new one on developer list?

The devel list is preferred. Also, github is wonderful. :) Alan DeKok.