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
