[Kea-users] Option 43 - Different formats for different client classes and host reservations

[Darren Ankney]

Hi Andreas,

To expand on what Francis has said. I think you'll find if you only
ever set the option 43 definition and/or data inside a client class
you should be OK.  You can add clients to classes in a reservation:
https://kea.readthedocs.io/en/stable/arm/dhcp4-srv.html#reserving-client-classes-in-dhcpv4

So, perhaps one class contains these "Special" clients and another
class contains the not-so-special clients.

Thank you,
Darren Ankney

On Mon, Sep 28, 2026 at 3:39 PM Andreas <ml+dhcp at tibdefender.com> wrote:
>
> Hi Francis,
>
> What do you mean by
> > before the option is decoded.
> Define the class as the first one in the config? I already tried to do this:
>
>   {
>      // DRG546 Voice
>      "name": "drg546-voice",
>      "test": "substring(option[60].text, 0, 11) == 'drg-DRG546s'",
>          "option-def": [
>              {
>                  "name": "vendor-encapsulated-options",
>                  "code": 43,
>                  "type": "binary",
>                  "space": "dhcp4",
>                  "array": false,
>                  "encapsulate": ""
>              }
>          ],
>   },
>
> and then set the option in the subnet reservation:
>   {
>       "ip-address": "10.123.123.2",
>       "option-data": [
>           {
>               "code": 43,
>               "data": "5446545...",
>               "name": "vendor-encapsulated-options",
>               "space": "dhcp4",
>               "csv-format": false
>           }
>       ],
>       "hw-address": "00:AA:BB:CC:60:ED",
>   },
>
> Obviously this is not working.
>
> You mean to define these legacy devices via global reservation? Would
> that change the behaviour that kea treats the "data"-part as different
> suboptions like it does in the above example?
>
>
> BR
> Andreas
>
> Am 28.09.2026 um 19:09 schrieb Francis Dupont:
> > Option 43 is a mess because it is underf specified so you can need
> > different incompatible ways to decode it. Kea tries to solve this issue
> > with per class option definition so you only need to put the incoming
> > query in the right class before the option is decoded. Now it can be
> > hairy, early global reservation lookup should help...
> >
> > Regards
> >
> > Francis Dupont <fdupont at isc.org>
>
> --
> 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 at lists.isc.org