Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v4.4.5 fails to parse a BIT value #193

Closed
muxout opened this issue Aug 28, 2018 · 7 comments
Closed

v4.4.5 fails to parse a BIT value #193

muxout opened this issue Aug 28, 2018 · 7 comments

Comments

@muxout
Copy link

muxout commented Aug 28, 2018

Upgrading from 4.4.4 to 4.4.5 has introduced a bug for us. For example this BITS value in CISCO-WAN-3G-MIB has now become an OctetString instead of Bits:

c3gConnectionStatusChangedNotifFlag OBJECT-TYPE
    SYNTAX          BITS {
                        unknown(0),
                        error(1),
                        connecting(2),
                        dormant(3),
                        connected(4),
                        disconnected(5),
                        idle(6),
                        active(7),
                        inactive(8)
                    }
    MAX-ACCESS      read-write
    STATUS          current
    DESCRIPTION
        "This object is the flag bitmap to control the generation of
        notification c3gConnectionStatusChangedNotif.  e.g. setting bit
        0 (error(0)) to 1 and bit 4 (disconnected(4)) to 1 will cause
        the notification c3gConnectionStatusChangedNotif to be
        generated when object c3gConnetionStatus changes the status to
        error or disconnected.  The default value of this object is
        '00'H."
    ::= { c3gWanCommonEntry 24 }

Rolling back to 4.4.4 resolved the problem

@etingof
Copy link
Owner

etingof commented Aug 29, 2018

Thank you for raising this! And sorry for the regression!

If you got a simple reproducer handy, that would be awesome. If not - no worries, I will try to come up with one.

@muxout
Copy link
Author

muxout commented Aug 29, 2018

Sorry, our code was masking an error.

This will reproduce the error with a compatible Cisco device:

import pysnmp
import pysnmp.hlapi

target = pysnmp.hlapi.UdpTransportTarget(('cisco-router.lab', 161), timeout=10)
community_data = pysnmp.hlapi.CommunityData('public')
engine = pysnmp.hlapi.SnmpEngine()
context = pysnmp.hlapi.ContextData()

mib_builder = engine.getMibBuilder()
pysnmp.smi.compiler.addMibCompiler(mib_builder, sources=['file:///usr/share/snmp/mibs/'])
mib_builder.loadModule('CISCO-WAN-3G-MIB')
mib_view = pysnmp.smi.view.MibViewController(mib_builder)

oi = pysnmp.hlapi.ObjectIdentity('CISCO-WAN-3G-MIB', 'c3gConnectionStatusChangedNotifFlag', 10)
ot = pysnmp.hlapi.ObjectType(oi).resolveWithMib(mib_view)

results = pysnmp.hlapi.getCmd(engine, community_data, target, context, lookupMib=False, *[ot])

for (errindic, errstat, errindex, binds) in results:
    for bind in binds:
        oid = bind[0]
        value = bind[1]
        oid, value = pysnmp.hlapi.ObjectType(pysnmp.hlapi.ObjectIdentity(oid), value).resolveWithMib(mib_view)
        print(oid, type(value))

In 4.4.5 the above produces this error pysnmp.smi.error.SmiError: MIB object 'CISCO-WAN-3G-MIB::c3gConnectionStatusChangedNotifFlag.10' having type 'Bits' failed to cast value <OctetString value object at 0x7f0490de8210 subtypeSpec <ConstraintsIntersection object at 0x7f04959a7710 consts <ValueSizeConstraint object at 0x7f04959a76d0 consts 0, 65535>> tagSet <TagSet object at 0x7f049730efd0 tags 0:0:4> encoding iso-8859-1 payload [0xff80]>: Duplicate name dormantcaused by <class 'pyasn1.error.PyAsn1Error'>: Duplicate name dormant

In 4.4.4 it works as expected:

(ObjectIdentity(<ObjectName value object at 0x7f3ff35b4250 tagSet <TagSet object at 0x7f3ff7dd5510 tags 0:0:6> payload [1.3.6.1.4.1.9.9.661.1.1.1.24.10]>), <class 'pysnmp.proto.rfc1902.Bits'>)

@muxout muxout changed the title v4.4.5 is parsing a BIT value as an Octet String v4.4.5 fails to parse a BIT value Aug 30, 2018
@etingof
Copy link
Owner

etingof commented Sep 9, 2018

Both master and release-4.4.6 branches should have this issue fixed.

@thomasgoirand
Copy link

Hi etingof,

Coud you please release 4.4.6, so that we have a new release with the fix?

Cheers,
Thomas Goirand (zigo)

@etingof
Copy link
Owner

etingof commented Sep 10, 2018

Before I release, just wanted to double-check - does it work for you?

@vincentbernat
Copy link
Contributor

Applying patch 74434d7 on top of 4.4.5 fixes the issue.

@etingof
Copy link
Owner

etingof commented Sep 13, 2018

jfyi: pysnmp 4.4.6 with this fix has been released

@etingof etingof closed this as completed Sep 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants