[kea-dev] I'd appreciate some feedback on trac ticket 3963 :)

[Marcin Siodelski]

On 04.08.2015 21:43, Angelo Failla wrote:
> On August 4, 2015 at 6:30:09 PM, Marcin Siodelski (marcin at isc.org
> <mailto:marcin at isc.org>) wrote:
> >
> >
> > On 04.08.2015 17:35, Angelo Failla wrote:
> > > On August 4, 2015 at 4:34:30 PM, Marcin Siodelski (marcin at isc.org
> > > <mailto:marcin at isc.org>) wrote:
> > >>
> > >> > one nice thing to also get rid of, when enabling the stateless
> switch,
> > >> > is to
> > >> > avoid this horrible hack to allow KEA to start :)
> > >> >
> > >> > 'subnet4' => [
> > >> > {
> > >> > 'subnet' => '0.0.0.0/0',
> > >> > 'pools' => [{ 'pool' => '0.0.0.0-255.255.255.255' }]
> > >> > },
> > >> > ],
> > >> >
> > >>
> > >> As a matter of curiosity. If you're having this hack already
> could you
> > >> possibly implement the lease4_select hook to set the yiaddr to
> non-zero
> > >> value in the DHCPOFFER, which would case processDiscover to not
> drop the
> > >> packet?
> > >>
> > >
> > > Yeah, I will try that and report back.
> >
> >
> > Actually, wouldn't it suffice to just restrict the pool to
> > 0.0.0.1-255.255.255.255C?
> >
> > That way none of the clients would ever be assigned a zero address and
> > the packet wouldn't be dropped.
>
> So I tried that, and compiled my hook lib w/o the change
> in https://github.com/isc-projects/kea/pull/11
> and it doesn’t solve the problem, I see that only my pkt4_receive
> callout gets called, then I see
>
> 2015-08-04 12:34:59.869 ERROR [kea-dhcp4.bad-packets/966953]
> DHCP4_PACKET_NAK_0001
> [hwtype=1 00:02:c9:de:70:4e], cid=[no info], tid=0x2eed: failed to
> select a subnet for incoming packet,
> src 10.35.139.81, type DHCPDISCOVER
>
> and that’s it. no pkt4_send is called.
>
> config has this:
>
> "subnet4": [
>   {
>     "subnet": "0.0.0.1/0",
>     "pools": [
>       {
>         "pool": "0.0.0.1-255.255.255.255"
>       }
>     ]
>   }
> ]
>
> Anyway, it’s not a big deal, we got a version that is going to prod with
> my github change above for the time
> being.
>
> let me know how your meeting goes in relation to the proposed change.
>

Angelo,

We have accepted this work for 1.0 assuming that you will write the code
for it. I do think it is quite a straight forward change. One thing I
haven't pointed out in the ticket, and which may be worth some
clarification, is that we would like to have a 'runtime' configuration
parameter, rather than the compilation time parameter to enable
stateless mode.

One question I had is this. Do you require sending different sets of
options depending on the location of the client in the network? So for
example: for the clients from which the packet is received on this
interface you send these options, and for the clients connected to
another interface other options? Or accordingly for different relays
when dealing with the relayed traffic?


Marcin

Marcin