#30 setFromName fixed-length string check

open
None
5
2006-11-21
2006-10-26
Brian K
No

I've attached a patch, but note that it doesn't
completely solve the problem. I have tried the
__has_fixed_length method in isolation, but not
integrated into the rest of the module.

I believe trying to solve this bug exposes another
problem. The object I'm trying to encode is an OCTET
STRING, but it meets the condition

elif self.__bitsValue.isSuperTypeOf(obj):

and I don't think it should.

A little bit of background:
RFC 2578 indicates, in section 3.2, that the BITS
construct is not a reference to the ASN.1 type 'BIT
STRING'. Section 7.1.4 ties BITS to ASN.1's OCTET STRING.

I see that Bits, in Pysnmp, is a sub-type of
univ.OctetString. I have yet to dig into why
(apparently all) octet string objects are being treated
as Bits.

Discussion

1 2 > >> (Page 1 of 2)
  • Brian K

    Brian K - 2006-10-26

    SNMPv2-SMI.py patch

     
  • Brian K

    Brian K - 2006-10-27

    Logged In: YES
    user_id=1577145

    After reading and running the code, I think we can safely
    get rid of the condition in SNMPv2-SMI.py's setFromName and
    getAsName for which self.__bitsValue.isSuperTypeOf(obj) is
    true. The Bits() object has the same self.tagSet as an
    OctetString object, and the constraints of both a Bits()
    object and an OctetString() object both default to an empty
    ConstraintsIntersection object. This makes sense from a
    higher level, as I explained in my last post, because Bits
    is a sub-type of or is implemented via OCTET STRING.

    The patch I've attached passes the tests I've run
    completely, from the sending of the SET or GET to the
    receipt and validation of the response.

    Note that there may be some cases for which
    __get_fixed_length(...) does not return the right answer. I
    have yet to think of situations where a legal MIB module
    would compile to produce objects having constraints that
    would produce such a case, however. Also, this method gets
    called quite frequently, so it's worthwhile to keep it simple.

     
  • Brian K

    Brian K - 2006-10-27
    • status: open --> closed
     
  • Ilya Etingof

    Ilya Etingof - 2006-11-02
    • assigned_to: nobody --> elie
    • status: closed --> open
     
  • Ilya Etingof

    Ilya Etingof - 2006-11-02

    Logged In: YES
    user_id=106050

    This bug report appears to remain in 'closed' state so I've
    not been aware of it. ;-(

    I've just [hopefully] fixed the OctetString/Bits matching
    order what might fix the latter problem you mentioned in the
    initial report.

    I'm not sure why you consider rfc1902.Bits and
    rfc1902.OctetString having the same set of constraints:

    >>> from pysnmp.proto import rfc1902
    >>> rfc1902.OctetString.subtypeSpec
    ConstraintsIntersection(ValueSizeConstraint(0, 65535))
    >>> rfc1902.Bits.subtypeSpec
    ConstraintsIntersection()

    So, rfc1902.Bits and rfc1902.OctetString are different types
    in pyasn1 terms.

    I keep working on the issue...

    Thanks,
    ilya

     
  • Ilya Etingof

    Ilya Etingof - 2006-11-02

    Logged In: YES
    user_id=106050

    From the first glance, your patch does not support
    potentially recursive sets of constraints, as your code
    seems to check the second-level constraints only. Also, the
    code is not particulary fast.

    Maybe more generic and fast implementation would involve
    hacking pyasn1 ValueSizeConstraint & AbstractConstraintSet
    code in a way to treat the fixed-size as a static property
    of constraints tree.

    That's just a passing thought, I'm still working on it.

    Thanks,
    ilya

     
  • Brian K

    Brian K - 2006-11-03

    Logged In: YES
    user_id=1577145

    >From the first glance, your patch does not support
    >potentially recursive sets of constraints, as your code
    >seems to check the second-level constraints only. Also, the
    >code is not particulary fast.

    As I mentioned, I realized that there may be cases where it
    doesn't support a syntax, but I couldn't think of any such
    syntaxes that were legal.

    >
    >Maybe more generic and fast implementation would involve
    >hacking pyasn1 ValueSizeConstraint & AbstractConstraintSet
    >code in a way to treat the fixed-size as a static property
    >of constraints tree.
    >
    >That's just a passing thought, I'm still working on
    >it.
    >

    Thanks for working on it. I do like the idea of tagging the
    syntax once and being done with it to improve execution time.

    >
    >This bug report appears to remain in 'closed' state so
    >I've
    >not been aware of it. ;-(
    >

    My mistake; sorry about that.

    >I've just [hopefully] fixed the OctetString/Bits matching
    >order what might fix the latter problem you mentioned in the
    >initial report.
    >
    >I'm not sure why you consider rfc1902.Bits and
    >rfc1902.OctetString having the same set of constraints:
    >
    >>>> from pysnmp.proto import rfc1902
    >>>> rfc1902.OctetString.subtypeSpec
    >ConstraintsIntersection(ValueSizeConstraint(0, 65535))
    >>>> rfc1902.Bits.subtypeSpec
    >ConstraintsIntersection()
    >
    >So, rfc1902.Bits and rfc1902.OctetString are different types
    >in pyasn1 terms.
    >

    I've verified that a Bits() object does not get caught by
    the OctetString condition due to the difference in
    constraints you mention, so I agree that should work.

    BTW, your fix for the rowcreation error bug I submitted,
    number 1575697, works for me. Sorry for the delayed reply
    about that. Thanks.

     
  • Ilya Etingof

    Ilya Etingof - 2006-11-16

    Logged In: YES
    user_id=106050
    Originator: NO

    Sorry for it takes so long for me to handle these issues.

    I've tried several approaches to handle that mysterious fixed-length-string feature and I finally ended up with a special property of rfc1902.OctetString objects. If you have your own MIBs you'd need to re-built them with the latest libsmi2pysnmp script. All relevant code is in CVS now. I'd be happy knowing how it works for you.

    Thanks,
    ilya

     
  • Ilya Etingof

    Ilya Etingof - 2006-11-16
    • status: open --> pending-fixed
     
  • Brian K

    Brian K - 2006-11-17

    Logged In: YES
    user_id=1577145
    Originator: YES

    The latest revision of the code passes most of my tests, but fails where an object that could be any of the several types of InetAddress is used as an index. In this case, the MIB module SYNTAX statement for the object is:

    SYNTAX InetAddress (SIZE (4|16|20))

    As shown in the debugger interaction below, the _subtypeSpec for OctetString() is:

    ConstraintsIntersection(ValueSizeConstraint(0, 65535))

    and for this specialization of InetAddress, it is:

    ConstraintsUnion(ConstraintsIntersection(ValueSizeConstraint(0, 255), ValueSizeConstraint(0, 65535)), ValueRangeConstraint(4, 4), ValueRangeConstraint(16, 16), ValueRangeConstraint(20, 20))

    ConstraintsUnion objects do not yet have the property 'hasConstraint', so isSuperTypeOf fails.

    With ConstraintsUnion and ConstraintsIntersection, the code is referring to sets which haven't fully been resolved. For example, ConstraintsIntersection(ValueSizeConstraint(0, 255), ValueSizeConstraint(0, 65535)) equates to ValueSizeConstraint(0, 255). Perhaps when trying to solve this bug, it would be easier for you to deal with sets of constraints.

    (Pdb) c
    > /home/kyckelha/sandbox/hitv3/trunk/src/hitsnmp/libs/pysnmp/build/lib/pysnmp/v4/smi/mibs/SNMPv2-SMI.py(733)setFromName()
    -> elif self.__strValue.isSuperTypeOf(obj):
    (Pdb) c
    > /home/kyckelha/sandbox/hitv3/trunk/src/hitsnmp/libs/pyasn1/build/lib/pyasn1/v1/type/base.py(45)isSuperTypeOf()
    -> return self._tagSet.isSuperTagSetOf(other.getTagSet()) and \ (Pdb) self
    OctetString()
    (Pdb) other
    InetAddress()
    (Pdb) self._tagSet
    TagSet(Tag(tagClass=0, tagFormat=0, tagId=4))
    (Pdb) self._subtypeSpec
    ConstraintsIntersection(ValueSizeConstraint(0, 65535))
    (Pdb) other.getSubtypeSpec()
    ConstraintsUnion(ConstraintsIntersection(ValueSizeConstraint(0, 255), ValueSizeConstraint(0, 65535)), ValueRangeConstraint(4, 4), ValueRangeConstraint(16, 16), ValueRangeConstraint(20, 20))
    (Pdb) c
    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "/usr/lib/python2.4/pdb.py", line 990, in run
    Pdb().run(statement, globals, locals)
    File "/usr/lib/python2.4/bdb.py", line 366, in run
    exec cmd in globals, locals
    File "<string>", line 1, in ?

    ... lines omitted ...

    File "/home/kyckelha/sandbox/hitv3/trunk/src/hitsnmp/libs/pysnmp/build/lib/pysnmp/v4/entity/rfc3413/mibvar.py", line 45, in oidToMibName
    return (symName, modName), rowNode.getIndicesFromInstId(suffix)
    File "/home/kyckelha/sandbox/hitv3/trunk/src/hitsnmp/libs/pysnmp/build/lib/pysnmp/v4/smi/mibs/SNMPv2-SMI.py", line 900, in getIndicesFromInstId
    syntax, instId = self.setFromName(mibObj.syntax, instId, impliedFlag)
    File "/home/kyckelha/sandbox/hitv3/trunk/src/hitsnmp/libs/pysnmp/build/lib/pysnmp/v4/smi/mibs/SNMPv2-SMI.py", line 733, in setFromName
    elif self.__strValue.isSuperTypeOf(obj):
    File "/home/kyckelha/sandbox/hitv3/trunk/src/hitsnmp/libs/pyasn1/build/lib/pyasn1/v1/type/base.py", line 45, in isSuperTypeOf
    return self._tagSet.isSuperTagSetOf(other.getTagSet()) and \ File "/home/kyckelha/sandbox/hitv3/trunk/src/hitsnmp/libs/pyasn1/build/lib/pyasn1/v1/type/constraint.py", line 166, in isSuperTypeOf
    if not constraintSet.hasConstraint(c): # super type must have all
    AttributeError: ConstraintsUnion instance has no attribute 'hasConstraint'

    The accompanying script will reproduce the errors if you modify it in the two places indicated.

     
  • Brian K

    Brian K - 2006-11-17
    • status: pending-fixed --> open-fixed
     
  • Ilya Etingof

    Ilya Etingof - 2006-11-20
    • status: open-fixed --> pending
     
  • Ilya Etingof

    Ilya Etingof - 2006-11-20

    Logged In: YES
    user_id=106050
    Originator: NO

    Yeah, I guess I see what is wrong there. Perhaps pyasn1 constraints derivation logic (isSuperTypeOf()) needs to be slightly re-written/completed...

    BTW, you may not need calling loadModules() unless you really want to load up all modules available in search path, which is very slow.

    Thanks,
    ilya

     
  • Nobody/Anonymous

    Logged In: NO

    Did you mean to mark the bug as 'closure pending'? Your reply implies the bug isn't fixed.

     
  • Ilya Etingof

    Ilya Etingof - 2006-11-21

    Logged In: YES
    user_id=106050
    Originator: NO

    That's it. I see that there is a problem and I'm now thinking over the best solution. ;)

     
  • Ilya Etingof

    Ilya Etingof - 2006-11-21

    Logged In: YES
    user_id=106050
    Originator: NO

    I've tried to re-work pyasn1 constraints derivation scheme. Still not sure how good it is. Two patches that may fix your problem attached. Please, let me know if it helps. Thanks!

     
  • Ilya Etingof

    Ilya Etingof - 2006-11-21
     
  • Ilya Etingof

    Ilya Etingof - 2006-11-21
     
  • Brian K

    Brian K - 2006-11-21
     
  • Brian K

    Brian K - 2006-11-21
    • status: pending --> open
     
  • Brian K

    Brian K - 2006-11-21

    Logged In: YES
    user_id=1577145
    Originator: YES

    Some of our code is barfing because an instance of MibBuilder contains an IF-MIB::ifNumber node which has a SubtypeSpec that isn't well-formed. Specifically, it is:

    ConstraintsIntersection(ValueRangeConstraint(-2147483648, 2147483647), ConstraintsIntersection())

    The attached script bad_subtypespec.py demonstrates the problem.

     
  • Ilya Etingof

    Ilya Etingof - 2006-11-22

    Logged In: YES
    user_id=106050
    Originator: NO

    What exactly do you think is malformed there? An empty ConstraintsIntersection()? Yeah, it looks useless but should be harmless, no? I run your script and get the same constraint set but do not see how it causes problem. Please, clarify.

    Thanks,
    ilya

     
  • Ilya Etingof

    Ilya Etingof - 2006-11-22

    Logged In: YES
    user_id=106050
    Originator: NO

    Meanwhile, I've CVS committed the latest changes to pyasn1. Please, let me know if/how it works.

    Thanks,
    ilya

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks