[Kea-users] keama mistranslating dhcp-client-identified
John Lind
steinhelten at gmail.com
Fri Feb 14 22:28:28 UTC 2025
Well, it appears that I have been on a fool's errand. What I WANT is
reservation matches by "hostname" which I am now pretty sure that kea does
not do. I analyzed the leases file (where kea apparently puts reservations
as well as pool leases, fortunately for my analysis) and in ALL cases where
the client provided a client-id, it was "01:" prefixed to the MAC address.
Well, if I have the MAC address, I might as well use hw-address! Also, if
I want a reserved IP address to "follow" a device regardless of its
interface, it makes life more complicated. I can mitigate this slightly by
using
"ip-reservations-unique": false,
but that doesn't entirely do what I want.
The implications for me are
1) when I get a device that doesn't have the MAC address in human-readable
form that I want to assign to a reserved address, I will have to connect it
to the network, search the leases file for the hostname, grab the MAC
address out of that, make the reservation, and restart kea, and possibly
restart the device, as well.
2) when I have a device with multiple connection options (WiFi, built-in
ethernet, USB dongle Ethernet), if I want it to get the same IP address
regardless of which connection method it uses, I'll have to include all
possible MAC values it might use, and in some cases, when I'm moving a USB
dongle from one device to another, I'll have to modify the configuration
file rather than having the IP address "follow" the device from one
connection method to another, and NOT follow the MAC address from one
device to another.
So if I include reservations for all the MAC addresses a device might use,
and if I move the USB dongle from one device to another, my dedicated IP
address will follow it, which is NOT what I want to happen. I'll have to
modify the config file and restart kea to avoid that which is a nuisance
and likely to be forgotten.
But at least I can quit chasing my tail looking for functionality which
does not appear to exist.
On Fri, Feb 14, 2025 at 4:16 AM Darren Ankney <darren.ankney at gmail.com>
wrote:
> 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
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20250214/ab15297f/attachment-0001.htm>
More information about the Kea-users
mailing list