This patch add support for decoding hex input, so
that binary attributes can be read through --json.

Example (using future wireguard.yaml):
 $ sudo ./tools/net/ynl/pyynl/cli.py --family wireguard \
   --do set-device --json '{"ifindex":3,
     "private-key":"2a ae 6c 35 c9 4f cf <... to 32 bytes>"}'

Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
---
 tools/net/ynl/pyynl/lib/ynl.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/net/ynl/pyynl/lib/ynl.py b/tools/net/ynl/pyynl/lib/ynl.py
index a37294a751da..78c0245ca587 100644
--- a/tools/net/ynl/pyynl/lib/ynl.py
+++ b/tools/net/ynl/pyynl/lib/ynl.py
@@ -973,6 +973,8 @@ class YnlFamily(SpecFamily):
                 raw = ip.packed
             else:
                 raw = int(ip)
+        elif attr_spec.display_hint == 'hex':
+            raw = bytes.fromhex(string)
         else:
             raise Exception(f"Display hint '{attr_spec.display_hint}' not implemented"
                             f" when parsing '{attr_spec['name']}'")
-- 
2.51.0

2025-09-04, 22:01:33 +0000, Asbjørn Sloth Tønnesen wrote:
> This patch add support for decoding hex input, so
> that binary attributes can be read through --json.
> 
> Example (using future wireguard.yaml):
>  $ sudo ./tools/net/ynl/pyynl/cli.py --family wireguard \
>    --do set-device --json '{"ifindex":3,
>      "private-key":"2a ae 6c 35 c9 4f cf <... to 32 bytes>"}'
> 
> Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
> ---
>  tools/net/ynl/pyynl/lib/ynl.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/net/ynl/pyynl/lib/ynl.py b/tools/net/ynl/pyynl/lib/ynl.py
> index a37294a751da..78c0245ca587 100644
> --- a/tools/net/ynl/pyynl/lib/ynl.py
> +++ b/tools/net/ynl/pyynl/lib/ynl.py
> @@ -973,6 +973,8 @@ class YnlFamily(SpecFamily):
>                  raw = ip.packed
>              else:
>                  raw = int(ip)
> +        elif attr_spec.display_hint == 'hex':
> +            raw = bytes.fromhex(string)

I'm working on a spec for macsec and ended up with a similar change,
but doing instead:

+        elif attr_spec.display_hint == 'hex':
+            raw = int(string, 16)

since the destination attribute is u32/u64 and not binary for macsec.

So maybe this should be:

+            if attr_spec['type'] == 'binary':
+                raw = bytes.fromhex(string)
+            else:
+                raw = int(string, 16)

to cover both cases?

I think it matches better what's already in _formatted_string.

(I don't mind having the current patch go in and making this change
together with the macsec spec when it's ready)

>          else:
>              raise Exception(f"Display hint '{attr_spec.display_hint}' not implemented"
>                              f" when parsing '{attr_spec['name']}'")
> -- 
> 2.51.0
> 
> 

-- 
Sabrina

On 9/9/25 6:10 PM, Sabrina Dubroca wrote:
> 2025-09-04, 22:01:33 +0000, Asbjørn Sloth Tønnesen wrote:
>> This patch add support for decoding hex input, so
>> that binary attributes can be read through --json.
>>
>> Example (using future wireguard.yaml):
>>   $ sudo ./tools/net/ynl/pyynl/cli.py --family wireguard \
>>     --do set-device --json '{"ifindex":3,
>>       "private-key":"2a ae 6c 35 c9 4f cf <... to 32 bytes>"}'
>>
>> Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
>> ---
>>   tools/net/ynl/pyynl/lib/ynl.py | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/tools/net/ynl/pyynl/lib/ynl.py b/tools/net/ynl/pyynl/lib/ynl.py
>> index a37294a751da..78c0245ca587 100644
>> --- a/tools/net/ynl/pyynl/lib/ynl.py
>> +++ b/tools/net/ynl/pyynl/lib/ynl.py
>> @@ -973,6 +973,8 @@ class YnlFamily(SpecFamily):
>>                   raw = ip.packed
>>               else:
>>                   raw = int(ip)
>> +        elif attr_spec.display_hint == 'hex':
>> +            raw = bytes.fromhex(string)
> 
> I'm working on a spec for macsec and ended up with a similar change,
> but doing instead:
> 
> +        elif attr_spec.display_hint == 'hex':
> +            raw = int(string, 16)
> 
> since the destination attribute is u32/u64 and not binary for macsec.
> 
> So maybe this should be:
> 
> +            if attr_spec['type'] == 'binary':
> +                raw = bytes.fromhex(string)
> +            else:
> +                raw = int(string, 16)
> 
> to cover both cases?
> 
> I think it matches better what's already in _formatted_string.
> 
> (I don't mind having the current patch go in and making this change
> together with the macsec spec when it's ready)

Cool, I will include it in v2, which I hope to get out tomorrow.

Asbjørn Sloth Tønnesen <ast@fiberby.net> writes:

> This patch add support for decoding hex input, so
> that binary attributes can be read through --json.
>
> Example (using future wireguard.yaml):
>  $ sudo ./tools/net/ynl/pyynl/cli.py --family wireguard \
>    --do set-device --json '{"ifindex":3,
>      "private-key":"2a ae 6c 35 c9 4f cf <... to 32 bytes>"}'
>
> Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>

Reviewed-by: Donald Hunter <donald.hunter@gmail.com>

FWIW, the hex can include spaces or not when using bytes.fromhex(). When
formatting hex for output, I chose to include spaces, but I don't really
know if that was a good choice or not.

On 9/5/2025 3:51 AM, Donald Hunter wrote:
> Asbjørn Sloth Tønnesen <ast@fiberby.net> writes:
> 
>> This patch add support for decoding hex input, so
>> that binary attributes can be read through --json.
>>
>> Example (using future wireguard.yaml):
>>  $ sudo ./tools/net/ynl/pyynl/cli.py --family wireguard \
>>    --do set-device --json '{"ifindex":3,
>>      "private-key":"2a ae 6c 35 c9 4f cf <... to 32 bytes>"}'
>>
>> Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
> 
> Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
> 
> FWIW, the hex can include spaces or not when using bytes.fromhex(). When
> formatting hex for output, I chose to include spaces, but I don't really
> know if that was a good choice or not.

I also prefer the spaces for readability.

On 9/6/25 12:27 AM, Jacob Keller wrote:
> On 9/5/2025 3:51 AM, Donald Hunter wrote:
>> Asbjørn Sloth Tønnesen <ast@fiberby.net> writes:
>>
>>> This patch add support for decoding hex input, so
>>> that binary attributes can be read through --json.
>>>
>>> Example (using future wireguard.yaml):
>>>   $ sudo ./tools/net/ynl/pyynl/cli.py --family wireguard \
>>>     --do set-device --json '{"ifindex":3,
>>>       "private-key":"2a ae 6c 35 c9 4f cf <... to 32 bytes>"}'
>>>
>>> Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
>>
>> Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
>>
>> FWIW, the hex can include spaces or not when using bytes.fromhex(). When
>> formatting hex for output, I chose to include spaces, but I don't really
>> know if that was a good choice or not.
> 
> I also prefer the spaces for readability.
I formatted it with spaces for clarity, even without spaces it was a bit
long for one line. Spaces also has the advantage that you don't have to
think about endianness.

Should we define the display hints a bit more in a .rst, or is it OK that
they end up being implementation specific for each language library? Do we
want them to behave the same in a Rust YNL library, as they do in Python?

BTW: The rest of the key used in the example can be found with this key-gen:
$ printf "hello world" | sha1sum
[redacted key material]

Asbjørn Sloth Tønnesen <ast@fiberby.net> writes:

> On 9/6/25 12:27 AM, Jacob Keller wrote:
>> On 9/5/2025 3:51 AM, Donald Hunter wrote:
>>> Asbjørn Sloth Tønnesen <ast@fiberby.net> writes:
>>>
>>>> This patch add support for decoding hex input, so
>>>> that binary attributes can be read through --json.
>>>>
>>>> Example (using future wireguard.yaml):
>>>>   $ sudo ./tools/net/ynl/pyynl/cli.py --family wireguard \
>>>>     --do set-device --json '{"ifindex":3,
>>>>       "private-key":"2a ae 6c 35 c9 4f cf <... to 32 bytes>"}'
>>>>
>>>> Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
>>>
>>> Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
>>>
>>> FWIW, the hex can include spaces or not when using bytes.fromhex(). When
>>> formatting hex for output, I chose to include spaces, but I don't really
>>> know if that was a good choice or not.
>> I also prefer the spaces for readability.
> I formatted it with spaces for clarity, even without spaces it was a bit
> long for one line. Spaces also has the advantage that you don't have to
> think about endianness.
>
> Should we define the display hints a bit more in a .rst, or is it OK that
> they end up being implementation specific for each language library? Do we
> want them to behave the same in a Rust YNL library, as they do in Python?

Yes we should probably extend the existing doc to at least describe some
of the defacto behaviour.

https://docs.kernel.org/userspace-api/netlink/specs.html#display-hint

> BTW: The rest of the key used in the example can be found with this key-gen:
> $ printf "hello world" | sha1sum
> [redacted key material]