Re: String in OID

2009/6/5 Vincent Bernat <[email protected]>:
> So, a  variable-length string should  always be prefixed by  its length,
> except if it is IMPLIED.

Yes.


> LldpManAddress ::= TEXTUAL-CONVENTION
>    SYNTAX      OCTET STRING (SIZE (1..31))

>
> lldpLocManAddrEntry OBJECT-TYPE
>    INDEX   { lldpLocManAddrSubtype,
>              lldpLocManAddr }
>    ::= { lldpLocManAddrTable 1 }



> So,  the  index  is  an   integer  and  a  non  implied  variable-length
> string. The string should be prefixed  by its length.

Correct.

> However, if I walk this table, I get:
>
> .1.0.8802.1.1.2.1.3.8.1.3.1.4.172.16.101.218 = INTEGER: 5
> .1.0.8802.1.1.2.1.3.8.1.4.1.4.172.16.101.218 = INTEGER: unknown(1)
> .1.0.8802.1.1.2.1.3.8.1.5.1.4.172.16.101.218 = INTEGER: 0
> .1.0.8802.1.1.2.1.3.8.1.6.1.4.172.16.101.218 = OID: .1.3.6.1.4.1.45.3.53.1

That looks right, yes.
I'm assuming that .1.0.8802.1.1.2.1.3.8  is the OID of lldpLocManAddrTable
followed by 1 (lldpLocManAddrEntry)
    3,4,5,6 (the column objects),
    1 (lldpLocManAddrSubtype = ipV4)
    4 (the length of the string)
    172.16.101.218   (the IP address)


> I suppose that I should get:
>
> .1.0.8802.1.1.2.1.3.8.1.3.1.4.4.172.16.101.218 = INTEGER: 5
> .1.0.8802.1.1.2.1.3.8.1.4.1.4.4.172.16.101.218 = INTEGER: unknown(1)
> .1.0.8802.1.1.2.1.3.8.1.5.1.4.4.172.16.101.218 = INTEGER: 0
> .1.0.8802.1.1.2.1.3.8.1.6.1.4.4.172.16.101.218 = OID: .1.3.6.1.4.1.45.3.53.1

No - that would have *two* length subidentifiers.



> Usually, when length is not too large, it should have displayed:
> LLDP-MIB::lldpLocManAddrLen.ipV4.172.16.101.218.
> But maybe there is some heuristics here.

You'd need some form of Display Hint within the LldpManAddress
convention, for snmpwalk to know how to display this properly.

All it knows is that this is a "string", so it tries to display it as such.


> I  think  that  the  implementation  is  wrong from  the  RFC  point  of
> view.  Some other equipments respect the RFC by using a "real" string :
>
> LLDP-MIB::lldpLocManAddrLen.ipV4."172.16.101.218" = INTEGER: 5

You seem to be confusing two things - what values are being returned,
and how these values are displayed.

The agent seems to be returning plausible values, so I'm not sure
it's fair to say that this "implementation is wrong".
I can't comment about what "other equipment" might be doing.



Dave

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users