You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The LLDP standard specifies alpha-numeric data shall be encoded as UTF-8 in TLVs in Section 8.4.3. This seems to apply to custom-tlvs as well because the custom-tlv section of the standard specifies in Section 8.6 "Organizationally Specific TLVs shall conform to 8.4 and 8.6.1" and in in Section 8.6.1.5 explicitly states "Alpha-numeric information should be encoded in UTF-8".
A mechanism could be added to lldpcli to support entering text that gets ascii encoded. This would make it easier to comply with the standards idea of how this data should be encoded.
From that the suggested new supplemental command format (first command below) would be equivalent to the current way of doing things (second command below). Will probably need some modification to sort out ambiguities.
Yes, we could do that. I would suggest to add oui-info-str to avoid ambiguity (quoting is done before evaluation of a command, so you cannot know if a string was quoted or not). This is likely doable just by modifying src/lldpcli/conf-lldp.c.
Hey, I made a change to type oui-info to accept strings. So my local copy of this now supports strings passed in. I can submit it as a patch to this repo. cc: @vincentbernat
The LLDP standard specifies alpha-numeric data shall be encoded as UTF-8 in TLVs in Section 8.4.3. This seems to apply to custom-tlvs as well because the custom-tlv section of the standard specifies in Section 8.6 "Organizationally Specific TLVs shall conform to 8.4 and 8.6.1" and in in Section 8.6.1.5 explicitly states "Alpha-numeric information should be encoded in UTF-8".
A mechanism could be added to
lldpcli
to support entering text that gets ascii encoded. This would make it easier to comply with the standards idea of how this data should be encoded.From that the suggested new supplemental command format (first command below) would be equivalent to the current way of doing things (second command below). Will probably need some modification to sort out ambiguities.
The text was updated successfully, but these errors were encountered: