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
