The API has to deal with both DisplayString (underlying type OCTETSTR) and
actual octet strings. It makes sense for a DisplayString to be utf-8
encoded, but, it doesn't make sense for actual octet strings.
Python 3 does have two different types that can very usefully be used for
this: a string could be treated as being utf-8 encoded, assuming it's a
DisplayString, and a bytes value could be treated as a series of bytes.
Unfortunately, get() would have to return bytes only, as consulting the MIB
is the only way to tell whether a given incoming OCTETSTR is a
DisplayString or not.
I don't have cycles to work on this, unfortunately.
Bill
On Thu, Feb 2, 2023 at 4:10 PM Steve Hollywood <steve.hollyw...@chorus.co.nz>
wrote:
> Net-SNMP v5.9.3 with python 3.6.3.
>
>
>
> I’m not sure if this has only become an issue since the move of strings
> from bytes to Unicode in Python 3 but I cannot set an OID value to an octet
> string containing octets >=128.
>
> I am trying to set a MAC address in an OID.
>
>
>
> macAddress = '\x02\0\0\0\x80\xff'
>
> varbind = netsnmp.Varbind(oidSvcMacNameAddr, iid, macAddress,
> 'OCTETSTR')
>
>
>
> The python bindings convert everything to strings in the Varbind object.
>
>
>
> class Varbind(object):
>
> def __init__(self, tag=None, iid=None, val=None, type_arg=None):
>
> self.tag = STR(tag)
>
> self.iid = STR(iid)
>
> self.val = STR(val)
>
> self.type = STR(type_arg)
>
>
>
> The result on the wire of the performing an SNMP set on using the values
> above is:
>
>
>
> variable-bindings: 2 items
>
>
> TIMETRA-GLOBAL-MIB::tmnxSRObjs.4.2.59.1.4.10.83.84.69.45.80.79.76.84.48.49
> (1.3.6.1.4.1.6527.3.1.2.4.2.59.1.4.10.83.84.69.45.80.79.76.84.48.49):
> 02000000c280c3bf
>
> Object Name:
> 1.3.6.1.4.1.6527.3.1.2.4.2.59.1.4.10.83.84.69.45.80.79.76.84.48.49
> (TIMETRA-GLOBAL-MIB::tmnxSRObjs.4.2.59.1.4.10.83.84.69.45.80.79.76.84.48.49)
>
> Value (OctetString): 02000000c280c3bf
>
>
> TIMETRA-GLOBAL-MIB::tmnxSRObjs.4.2.59.1.4.10.83.84.69.45.80.79.76.84.48.49
> (1.3.6.1.4.1.6527.3.1.2.4.2.59.1.4.10.83.84.69.45.80.79.76.84.48.49):
> 020000007f55
>
> Object Name:
> 1.3.6.1.4.1.6527.3.1.2.4.2.59.1.4.10.83.84.69.45.80.79.76.84.48.49
> (TIMETRA-GLOBAL-MIB::tmnxSRObjs.4.2.59.1.4.10.83.84.69.45.80.79.76.84.48.49)
>
> Value (OctetString): 020000007f55
>
>
>
> As a result an error is returned because the octet string is 8 bytes
> rather than 6.
>
> Note: Setting values <0x80 works without issue. The second variable
> binding is using a macAddress = ‘\x02\0\0\0\x7f\x55’ is correct and when
> used without the 1st binding sets the value.
>
>
>
> Within the library bindings, the val attribute is read using the function
> py_netsnmp_attr_string, which calls PyUnicode_AsUTF8AndSize function
> which returns a UTF8 encoded char buffer. The value sent on the wire is the
> UTF-8 encoded string.
>
>
>
> >>> macAddress = '\x02\0\0\0\x80\xff'
>
> >>> macAddress
>
> '\x02\x00\x00\x00\x80ÿ'
>
> >>> macAddress.encode('utf8')
>
> b'\x02\x00\x00\x00\xc2\x80\xc3\xbf'
>
>
>
> UTF8 encoding is probably a poor choice for encoding octet strings. I
> believe that if the string was encoded as latin-1 (which is the same as
> iso-8859-1) within the bindings the problem wouldn’t occur.
>
>
>
> >>> macAddress.encode('latin-1')
>
> b'\x02\x00\x00\x00\x80\xff'
>
>
>
> Does anyone have any idea of how to cleverly work around this or failing
> that patch the bindings?
>
>
> The content of this email (including any attachments) is intended for the
> addressee only, is confidential and may be legally privileged. If you’ve
> received this email in error, you shouldn’t read it - please contact me
> immediately, destroy it, and do not copy or use any of the content of this
> email . No confidentiality or privilege is waived or lost by any
> mis-transmission or error. This communication does not designate an
> information system for the purposes of Part 4 of the Contract and
> Commercial Law Act 2017. Although we have taken reasonable precautions to
> ensure no viruses are present in this email, we cannot accept
> responsibility for any loss or damage arising from the use of this email or
> its attachments.
> _______________________________________________
> Net-snmp-users mailing list
> Net-snmp-users@lists.sourceforge.net
> Please see the following page to unsubscribe or change other options:
> https://lists.sourceforge.net/lists/listinfo/net-snmp-users
>
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
