Hi John, The way to add a feature request is to open a Gitlab issue here: https://gitlab.isc.org/isc-projects/kea/-/issues/ You would, of course, first want to check if such an issue already exits that requests such a feature. It does not mean the feature will be implemented either.
Thank you, Darren Ankney On Sat, Feb 15, 2025 at 3:06 PM John Lind <steinhel...@gmail.com> wrote: > > Thanks! Yes - I understood about the "reservations" not being stored, but > rather a lease based on the reservation, though I did express that carelessly. > > So - is there a suggestion "box"? If so, do you think there would be any > point in requesting that kea include the capability of matching on option 12 > host-name for the uses I laid out above? > > On Sat, Feb 15, 2025 at 5:57 AM Darren Ankney <darren.ank...@gmail.com> wrote: >> >> Hi John, >> >> > 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. >> >> That is correct. Kea will not match reservation based on option 12 >> (host-name) (see here: >> https://www.rfc-editor.org/rfc/rfc2132#section-3.14). The only >> reservation identifiers supported (by kea-dhcp4) are: hw-address, >> duid, client-id, and circuit-id >> >> > 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. >> >> A couple of things here. client-id is a specific dhcp option: >> "dhcp-client-identifier" option 61. This option could contain >> something else but, most of the time, contains the mac address of the >> client, or isn't present at all (see here: >> https://www.rfc-editor.org/rfc/rfc2132#section-9.14). The leases file >> now contains a lease for reserved ip addresses. It is true that in >> ISC DHCP, there were no lease kept for a "fixed-address". Kea creates >> leases for all cases. So it isn't so much keeping the reservation in >> this file as it is keeping a lease. Clients who have not obtained >> their reserved address will not appear in this file. >> >> Thank you, >> Darren Ankney >> >> On Fri, Feb 14, 2025 at 5:28 PM John Lind <steinhel...@gmail.com> wrote: >> > >> > 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.ank...@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 <steinhel...@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 <steinhel...@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@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.ank...@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 <steinhel...@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 <steinhel...@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 >> >> >>> >> steinhel...@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@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@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@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@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@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@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@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@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
