[Kea-users] Is KEA trying to do some smart caching?

[Marcin Siodelski]

Hi Ola,

I believe Kea should provide some generic solution for this issue. I
made a post on the kea-dev mailing list:

https://lists.isc.org/pipermail/kea-dev/2016-April/000647.html

where I am proposing to provide an API for hooks libraries accessing
DHCP options. Hopefully, we can discuss and come up with something that
will work for everyone, without requiring people to know internals of
the Kea server to safely modify the contents of the packet.

As an aside, this kind of discussion fits more into kea-dev, rather than
kea-users mail list.

Marcin Siodelski
ISC


On 22.04.2016 15:26, Ola Thoresen wrote:
> After some thinking, I believe the issue is that kea is "re-using" the
> packet-data for each reply, and not creating a copy of the initial
> packet-info read from the config.
> That way - when I rewrite an option that is not set by other internal
> functions in Kea - such as the Option43-values - it is tracked to all
> new DHCP-replies.
> 
> I have managed to work around the problem by caching and resetting the
> initial values inside the hook (by abusing buffer4_send).
> It's ugly, but it works. I would really prefer if Kea started each
> "response4" with a new packet - with all options directly from the
> config-file though.
> 
> I have now also updated the github-repo with proper logging, makefiles
> and some other fixes.
> 
> I would still love some proper review of the code, as this is really not
> my field, but at least it compiles and seems to do what I need it to do.
> 
> 
> 
> Rgds.
> 
> Ola Thoresen
> 
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users