[Kea-users] keama mistranslating dhcp-client-identified

Fri Feb 14 10:16:31 UTC 2025

Hi John,

Good to hear things are working.

> Note - you cannot have both the client-id and the "hw-address" in the same reservation.  The documentation claims that these are hierarchical with client-id above "chaddr" (which I assume to be the "hw-address" in this context) but if you can't have both of them, that's not much use.

The hierarchical nature of these is for performance.
"host-reservation-identifiers" allows you to tune which and in what
order the possible identifiers (hw-address, duid, client-id,
circuit-id) are checked (and if they are checked at all).  You would
remove the ones from the list that will never identify a reservation
in your environment.  You would put the one first that is most likely
to identify a reservation.  This does not allow you to have multiple
identifiers in the same reservation.  You can have multiple
reservations for the same IP address, however (see here:
https://kea.readthedocs.io/en/kea-2.6.1/arm/dhcp4-srv.html#multiple-reservations-for-the-same-ip),
which would let you achieve what you are trying to achieve I think.

Thank you,
Darren Ankney

On Thu, Feb 13, 2025 at 5:51 PM John Lind <steinhelten at gmail.com> wrote:
>
> Ok.  I'm up and running on kea-dhcp4, but it wasn't painless.  My reservations by hw-address all worked, but that's all.
>
> 1) it seems to have paid no attention to the leases I tried to import.  It started over assigning the first address from the pool.  If I had remembered to shorten the timeout/refresh before hand, that would have made things a bit less painful and confusing.  Immediately upon starting it logged "2025-02-13 15:30:15.717 WARN  [kea-dhcp4.dhcpsrv/35513.0x3f7aad812000] DHCPSRV_MEMFILE_CONVERTING_LEASE_FILES running LFC now to convert lease files to the current schema: 3.0" and it didn't complain, but it doesn't appear to have paid any attention to them, either.  Every pool lease I have looked at has changed.
> 2) The client-id format of "'casper'" didn't match.  I thought I had tried another host with only the double quotes and not the single quotes, but I guess I didn't.  I'm not sure how much I want to keep playing with that, or just bite the bullet and use all hw-addr.  Note - you cannot have both the client-id and the "hw-address" in the same reservation.  The documentation claims that these are hierarchical with client-id above "chaddr" (which I assume to be the "hw-address" in this context) but if you can't have both of them, that's not much use.
>
> On Sun, Feb 9, 2025 at 4:47 PM John Lind <steinhelten at gmail.com> wrote:
>>
>> Oops.  First let me apologize for an extra layer of complexity and confusion.  I started out with the entries for the system "twister" because it wasn't currently available and I didn't have to worry about corrupting its entries.  Then when I got to the point that I wanted to be able to try stuff out, I switched to "bringebaer".  There are no entries that need to mix these two strings - they should all be one or the other.
>>
>> So - I tried this out:
>>     "reservations-global": true,
>>     "reservations": [
>>       {
>>         "hostname": "bringebaer",
>>         "ip-address": "192.168.1.57",
>>         "client-id": "'bringebaer'"
>>       }
>>     ]
>>
>> So - then I did the syntax check:
>>
>> root at remo:/home/john/xfer # !kea
>> kea-dhcp4 -t kea-head.conf
>> 2025-02-09 16:39:51.055 INFO  [kea-dhcp4.hosts/3198.0x2cae30212000] HOSTS_BACKENDS_REGISTERED the following host backend types are available:
>> 2025-02-09 16:39:51.088 WARN  [kea-dhcp4.dhcpsrv/3198.0x2cae30212000] DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
>> 2025-02-09 16:39:51.088 WARN  [kea-dhcp4.dhcp4/3198.0x2cae30212000] DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
>> 2025-02-09 16:39:51.101 INFO  [kea-dhcp4.dhcpsrv/3198.0x2cae30212000] DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 192.168.1.0/24 with params: valid-lifetime=2592000
>> 2025-02-09 16:39:51.125 INFO  [kea-dhcp4.dhcpsrv/3198.0x2cae30212000] DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
>> 2025-02-09 16:39:51.127 INFO  [kea-dhcp4.dhcpsrv/3198.0x2cae30212000] DHCPSRV_CFGMGR_ADD_IFACE listening on interface ue0
>> 2025-02-09 16:39:51.128 INFO  [kea-dhcp4.dhcpsrv/3198.0x2cae30212000] DHCPSRV_CFGMGR_SOCKET_TYPE_DEFAULT "dhcp-socket-type" not specified , using default socket type raw
>>
>> No errors!  Tomorrow I'll have to munge all the entries and try it out.
>>
>> Thank you!
>>
>> On Sun, Feb 9, 2025 at 4:38 AM Darren Ankney <darren.ankney at gmail.com> wrote:
>>>
>>> Hi John,
>>>
>>> That is really interesting that this:
>>>
>>> host bringebaer { fixed-address bringebaer.starfire.mn.org;
>>>         option dhcp-client-identifier "bringebaer";
>>>  }
>>>
>>> somehow matches the client-identifier
>>> (https://www.rfc-editor.org/rfc/rfc2132#section-9.14).  ISC DHCP man
>>> page does say that you can match the dhcp-client-identifier option in
>>> a host object: https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpd#the-host-object
>>> Kea can too (https://kea.readthedocs.io/en/kea-2.6.1/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation):
>>>
>>> "Kea currently supports four types of identifiers: hw-address, duid,
>>> client-id, and circuit-id."
>>>
>>> Perhaps this:
>>>
>>>     {
>>>         "hostname": "bringebaer",
>>>         "ip-address": "192.168.1.57",
>>>         "client-id": "'twister'"
>>>       },
>>>
>>> (note the single quotes around twister inside the double quotes) but
>>> you might want to perform a packet capture to confirm that your client
>>> actually has a hostname in the client-id field.  I've not seen that
>>> previously.  Option 61 normally isn't present at all or contains the
>>> mac address.  But if this was working in ISC DHCP perhaps these are
>>> some devices I've not paid attention to before.
>>>
>>> Thank you,
>>> Darren Ankney
>>>
>>> On Sat, Feb 8, 2025 at 3:34 PM John Lind <steinhelten at gmail.com> wrote:
>>> >
>>> > I apologize - there's a typo in the subject line.  It should be dhcp-client-identifier (with an "r" at the end, not a "d').
>>> >
>>> > Anyway, I tried running "kea-dhcp4 -t" on one of these files and got this back:
>>> > 2025-02-08 14:18:27.503 ERROR [kea-dhcp4.dhcp4/94820.0x50554e412000] DHCP4_PARSER_FAIL failed to create or run parser for configuration element reservations: one of the supported identifiers must be specified for host reservation: circuit-id, client-id, duid, flex-id, hw-address (kea-head.conf:135:7)
>>> > Error encountered: one of the supported identifiers must be specified for host reservation: circuit-id, client-id, duid, flex-id, hw-address (kea-head.conf:135:7)
>>> > So - I don't see anything in that list that would correspond to what I've been doing with ISC-dhcp. I tried making up the syntax for client ID, and it didn't like that, either...
>>> >       {
>>> >         "hostname": "bringebaer",
>>> >         "ip-address": "192.168.1.57",
>>> >         "client-id": "twister"
>>> >       },
>>> > And the parser said:
>>> >
>>> > 2025-02-08 14:32:29.031 ERROR [kea-dhcp4.dhcp4/94837.0x5775ffa12000] DHCP4_PARSER_FAIL failed to create or run parser for configuration element reservations: invalid host identifier value 'twister' (kea-head.conf:135:7)
>>> > Error encountered: invalid host identifier value 'twister' (kea-head.conf:135:7)
>>> >
>>> >
>>> > On Sat, Feb 8, 2025 at 12:50 PM John Lind <steinhelten at gmail.com> wrote:
>>> >>
>>> >> Hey, all.  I've spent hours watching recorded webinars, reading documentation, and doing web searches in vain to try to figure out how to get these reservations to work in kea.
>>> >>
>>> >> For some of my devices / systems I like to use a value sent by the client rather than the hardware address to match them to a reservation.  This is especially useful in two cases
>>> >> 1) when I don't know the MAC address
>>> >> 2) when a device has different ways of connecting to my network (WiFi versus hardwired, and maybe different ethernet ports) but I want it to get the same IP address regardless of how it connects.
>>> >>
>>> >> For reference, here's how the values appear in the ISC dhcp leases file when there's not a reservation (yet).
>>> >>
>>> >>         client-hostname "MyQ-5C9";
>>> >>         client-hostname "casper";
>>> >>         client-hostname "StreamingStick4K-ET5";
>>> >>         client-hostname "Pixel-6a";
>>> >>         client-hostname "Paige-s-S23-Ultra";
>>> >>         client-hostname "Milea-s-S20-FE";
>>> >>         client-hostname "DESKTOP-7424SLE";
>>> >>         client-hostname "Pixel-8-Pro";
>>> >>         client-hostname "Pixel-7a";
>>> >>
>>> >> Here's an example of how I represent that in the dhcpd.conf file:
>>> >>  host bringebaer { fixed-address bringebaer.starfire.mn.org;
>>> >>         option dhcp-client-identifier "bringebaer";
>>> >>         }
>>> >> So, of course, keama is going to translate the FQDN to an IP address, but the rest of what it does doesn't seem like what I want:
>>> >>
>>> >>       {
>>> >>         "hostname": "bringebaer",
>>> >>         "ip-address": "192.168.1.57",
>>> >>         "option-data": [
>>> >>           {
>>> >>             "space": "dhcp4",
>>> >>             "name": "dhcp-client-identifier",
>>> >>             "code": 61,
>>> >> //          "original-data": "\"bringebaer\"",
>>> >>             "csv-format": false,
>>> >>             "data": "6272696e676562616572"
>>> >>           }
>>> >>         ]
>>> >>       },
>>> >> Note - the "data" in the option is actually a string of hex digits which truly does spell out "bringebaer" but I really think that keama is mapping dhcp-client-identifier to completely the wrong thing.
>>> >>
>>> >> If anyone can set me on the right course, I sure would appreciate it.
>>> >>
>>> >> --
>>> >> John Lind
>>> >> steinhelten at gmail.com
>>> >>
>>> > --
>>> > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>>> >
>>> > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>>> >
>>> > Kea-users mailing list
>>> > Kea-users at lists.isc.org
>>> > https://lists.isc.org/mailman/listinfo/kea-users
>>> --
>>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>>>
>>> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>>>
>>> Kea-users mailing list
>>> Kea-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/kea-users
>
> --
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users