Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Initial feedback on the new Radius integration
(Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Wed, 23 May 2018 07:52:09 +0000
From: Francis Dupont <[email protected]>
To: Baptiste Jonglez <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Initial feedback on the new Radius integration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Baptiste Jonglez writes:
> As you probably know, I have been developing Radius integration in Kea for
> a non-profit ISP / community network I am a member of. Here is the
> work-in-progress code: https://code.ffdn.org/zorun/kea
>
> I saw that there is a new Radius feature in Kea 1.4 (unfortunately not
> publicly available). Based on its documentation [1], I have a couple of
> questions:
>
> - do you support the Framed-IP-Netmask radius attribute? Our use-case
> involves giving /32 IP addresses to clients, regardless of the actual
> prefix length in Kea's configuration. So we basically use
> Framed-IP-Netmask = 255.255.255.255, would it be interpreted by Kea?
=> it is not supported by Kea itself: it unconditionally puts a
netmask option based on the subnet prefix. This means that with
RADIUS or not you have to patch it before answers are sent...
> - is there a reason for using the original freeradius client library
> (which is unmaintained to the point that you had to patch it locally),
> while radcli [2] is actively maintained and has the same API? We tried
> to discuss this some time ago [3].
=> freeradius client library is maintained (I found a bug in it, sent
a PR with the fix which was merged in hous). The local patch is about
a noy yet integrated PR to add asynchronous communication.
> - your radius implementation is advertised as a hook, but I see that a
> full rebuild of Kea is needed. It seems that part of the implementation
> is built into Kea? We initially tried to implement radius support as a
> hook, but it was really awkward, so we implemented it within Kea.
=> The core Kea was modified to help support but the RADIUSD code
itself it fully in the hook.
> - the host reservation cache looks very nice! This is something we really
> wanted to implement but it looked quite complex to do.
=> it was not so easy to write... Note it made far more changes in
the core Kea than RADIUS.
Thanks
Francis Dupont <[email protected]>
------------------------------
Subject: Digest Footer
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
------------------------------
End of kea-dev Digest, Vol 50, Issue 4
**************************************
