kea 2.7.0 sends empty vendor-encapsulated-options when option-data is in reservations and option-def for suboptions sits in a class + dedicated space

Describe the bug

When using client reservations with vendor-encapsulated-options data, and client-classes, Kea (problem present in at least 2.6.x releases and 2.7.0) sends 0-length option 43 data.

This happens only when said option 43 suboptions definitions are in a different space than vendor-encapsulated-options-space and a dedicated client-class is used, and suboption data definition sits in a client reservation.

Otherwise, when option 43 suboptions definitions are defined in vendor-encapsulated-options-space, and suboption data is defined in per-host reservations, Kea sends option 43 with the expected data.

This is currently an issue, because we cannot use machines with conflicting option 43 suboptions definitions and per-host suboption data.

To Reproduce

Run Kea dhcpv4 daemon with the following configuration:

{
  "Dhcp4": {
    "client-classes": [
      {
        "name": "JUNOS",
        "option-def": [
          {
            "code": 43,
            "encapsulate": "junos-veo-space",
            "name": "vendor-encapsulated-options",
            "type": "empty"
          }
        ]
      }
    ],
    "host-reservation-identifiers": [
      "hw-address"
    ],
    "interfaces-config": {
      "dhcp-socket-type": "udp",
      "interfaces": [
        "ens18"
      ]
    },
    "lease-database": {
      "name": "/var/lib/kea/dhcp4.leases",
      "persist": true,
      "type": "memfile"
    },
    "option-def": [
      {
        "code": 0,
        "name": "image-file-name",
        "space": "junos-veo-space",
        "type": "string"
      },
      {
        "code": 1,
        "name": "config-file-name",
        "space": "junos-veo-space",
        "type": "string"
      },
      {
        "code": 2,
        "name": "image-file-type",
        "space": "junos-veo-space",
        "type": "string"
      },
      {
        "code": 3,
        "name": "transfer-mode",
        "space": "junos-veo-space",
        "type": "string"
      },
      {
        "code": 4,
        "name": "alt-image-file-name",
        "space": "junos-veo-space",
        "type": "string"
      },
      {
        "code": 5,
        "name": "http-port",
        "space": "junos-veo-space",
        "type": "string"
      }
    ],
    "reservations": [
      {
        "client-classes": [
          "JUNOS"
        ],
        "hostname": "test",
        "hw-address": "06:3f:05:83:99:98",
        "ip-address": "10.128.6.12",
        "option-data": [
          {
            "always-send": true,
            "name": "vendor-encapsulated-options"
          },
          {
            "always-send": true,
            "data": "127.0.0.1",
            "name": "tftp-server-name"
          },
          {
            "data": "config/test0001.cfg",
            "name": "config-file-name",
            "space": "junos-veo-space"
          },
          {
            "data": "tftp",
            "name": "transfer-mode",
            "space": "junos-veo-space"
          }
        ]
      }
    ],
    "subnet4": [
      {
        "id": 1,
        "option-data": [
          {
            "data": "10.128.6.9",
            "name": "routers"
          },
          {
            "data": "45.139.138.24",
            "name": "ntp-servers"
          }
        ],
        "reservations-global": true,
        "subnet": "10.128.6.8/29"
      },
      {
        "id": 2,
        "option-data": [
          {
            "data": "10.128.6.7",
            "name": "routers"
          },
          {
            "data": "45.139.138.24",
            "name": "ntp-servers"
          }
        ],
        "reservations-global": true,
        "subnet": "10.128.6.16/29"
      }
    ]
  }
}

When sending a dhcp discover from the client with dhcptest, the server replies with the following answer (tcpdump below):

17:44:25.314892 IP (tos 0x0, ttl 64, id 4503, offset 0, flags [DF], proto UDP (17), length 330)
    10.128.4.15.67 > 10.128.6.9.67: [bad udp cksum 0x205f -> 0x2a38!] BOOTP/DHCP, Reply, length 302, hops 1, xid 0x6155d16b, Flags [none] (0x0000)
          Client-IP 10.128.6.12
          Your-IP 10.128.6.12
          Gateway-IP 10.128.6.9
          Client-Ethernet-Address 06:3f:05:83:99:98
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: ACK
            Subnet-Mask (1), length 4: 255.255.255.248
            Default-Gateway (3), length 4: 10.128.6.9
            Hostname (12), length 4: "test"
            NTP (42), length 4: 45.139.138.24
            Vendor-Option (43), length 0
            Lease-Time (51), length 4: 7200
            Server-ID (54), length 4: 10.128.4.15
            Client-ID (61), length 7: ether 06:3f:05:83:99:98
            TFTP (66), length 9: "127.0.0.1"
            END (255), length 0

Expected behavior

It was expected that Kea would send option 43 along with the suboption data defined in the matching client reservation (as it is the case without client-classes and suboption definition in vendor-encapsulated-options-space.

Environment:

• Kea version: 2.7.0 (tarball)
• OS: nixos 24.05
• Which features were compiled in (in particular which backends)
  • linked with:
    • log4cplus 2.1.1
    • OpenSSL 3.0.13 30 Jan 2024
  • backends:
    • MySQL backend 23.0, library 3.3.5
    • PostgreSQL backend 23.0, library 150007
    • Memfile backend 3.0
• no hooks loaded

Additional Information

I have kea compiled with debug symbols and full access to the server in which it is running + possibility to send you a rr record (https://rr-project.org/) if needed.

Contacting you

You can contact me on the following email address: lou.lecrivain@wdz.de