[Kea-users] Option 125 (VIVSO) with csv-format: false drops sub-option payload

[Darren Ankney]

Hi Alexis,

I can confirm that this is the behavior of Kea.  I do not know if it
is intended behavior or a bug, however.  I performed some testing and
did confirm your observation.  I set my option 125 like this:

    "option-data": [
      {
        "code": 125,
        "always-send": true,
        "csv-format": false,
        "data": "0x00000de90b04021aaa05021186060105"
      }
    ],

but what was actually in the packet was this: 0x00000de900 (the length
0b was changed to 00).

However, the mailing list isn't the right place to report potential
problems in Kea.  Please report this issue here:
https://gitlab.isc.org/isc-projects/kea/-/issues You can create an
account to do so.  However, Gitlab will try very hard not to let you
sign up with @gmail.com (or other free service) email address.  This
is due to overwhelming amounts of spam accounts that are created from
these services.

Thank you,
Darren Ankney

On Mon, Mar 30, 2026 at 10:59 AM Alexis <alstukov at gmail.com> wrote:
>
> Hi,
>
> I'm running Kea on OPNsense and I've found that option 125 (VIVSO) does not behave as expected when configured with csv-format: false and raw hex data.
>
> When I send the full VIVSO payload as raw hex:
>
> "option-data": [
>   { "code": 125, "csv-format": false, "always-send": true, "data": "00000DE924..." }
> ]
>
> Kea only sends 5 bytes on the wire (confirmed via tcpdump):
>
>   Unknown (125), length 5: 0.0.13.233.0
>
> Only the enterprise number (3561) + an empty byte. The sub-option TLV payload is dropped.
>
> However, when using the option-def + vivso-suboptions + vendor space framework with the exact same data:
>
> "option-def": [
>   { "name": "vc-opt4", "code": 4, "type": "binary", "space": "vendor-3561" },
>   { "name": "vc-opt5", "code": 5, "type": "binary", "space": "vendor-3561" },
>   { "name": "vc-opt6", "code": 6, "type": "binary", "space": "vendor-3561" }
> ],
> "option-data": [
>   { "name": "vivso-suboptions", "always-send": true, "data": "3561" },
>   { "name": "vc-opt4", "space": "vendor-3561", "always-send": true, "csv-format": false, "data": "..." },
>   { "name": "vc-opt5", "space": "vendor-3561", "always-send": true, "csv-format": false, "data": "..." },
>   { "name": "vc-opt6", "space": "vendor-3561", "always-send": true, "csv-format": false, "data": "..." }
> ]
>
> The full 41-byte option 125 is correctly sent on the wire with all sub-options.
>
> It appears that Kea treats option 125 specially because it is internally defined as vivso-suboptions (type uint32). Even with csv-format: false, Kea parses the enterprise number and discards the remaining data instead of treating it as an opaque binary blob.
>
> My expectation would be that csv-format: false sends raw bytes unchanged, regardless of the option code.
>
> Is this the intended behavior or a bug?
>
> Use case: French ISP (Orange) FTTH requires VIVSO with enterprise 3561 and vendor sub-options for TV decoder authentication.
>
> Related OPNsense issue: https://github.com/opnsense/core/issues/10060
>
> Kea version: as shipped with OPNsense 26.1 (FreeBSD)
>
> Thanks
> --
> 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