Hi Dave,
I have got one more doubt in the BIT String data types.
I got clear idea on the BIT String which in of 8bits(1 byte) length, now
my question is how do we treat a object which is BITS type with 64 bit
length.
As per RFC 1212 section 5.1.1. Mapping to the SYNTAX clause
(3) An object with BIT STRING syntax containing no more than
32 bits becomes an INTEGER defined as a sum; otherwise if
more than 32 bits are present, the object becomes an
OCTET STRING, with the bits numbered from left-to-right,
in which the least significant bits of the last octet may
be "reserved for future use".
my questions are
_*QUE 1.* _should we implement the object as OCTET string syntax or BIT
STRING syntax (if it is of 64bits).
_*QUE 2.* _example:
lets take one object xyz
whose syntax is BITS {
a(0),
b(1),
c(2),
d(3)
.....
A(60)
B(61)
--
F(63)
}
Here if the bits from 0 to 19 are set means, how we should set
i) either from left to right [left = 0th bit(LSB), right(63rd bit (MSB))]
ii) or from right to left [right = 0th bit(LSB), left(63rd bit (MSB))]
_*QUE 3. *_If i set the bits 0 to 19 and i have implemented the object
with BIT String syntax then,
i will initialize the value
*0000000000011111111111111111111 = 00000000000FFFFF* to object while the
SNMP initialization.
If i do snmpget on this object i am receiving the result in manager side
is == *BITS: FF FF 0F 00 00 00 00 00 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15 20 21 22 23* ==> Is this correct with respect to what i'm setting the
value to this object.
Thanks and Regards,
Venkatgiri
On 01/15/2009 02:21 PM, Dave Shield wrote:
2009/1/15 venkatgiri<venkatgir...@globaledgesoft.com>:
my questions is what value i need to give if i want to set
1. sunday
snmpset .... xyz b sunday
or
snmpset .... xyz b 0
2. sunday, monday
snmpset .... xyz b sunday,monday
or
snmpset .... xyz b 0,1
3. sunday, monday,wednesday.
snmpset .... xyz b sunday,monday,wednesday
or
snmpset .... xyz b 0,1,3
when i tried to the manager is behaving like this.
i want to set 1st bit 00000001 = 01
snmpset -c private -v 2c 172.16.8.60:161 .1.3.6.1.4.1.3.4.0 b 01 --------->
the manager is encoding like this 40(h) ->1000000(b)
That looks correct.
> From RFC1906 - section 8:
(3) When encoding an object whose syntax is described using the BITS
construct, the value is encoded as an OCTET STRING, in which all
the named bits in (the definition of) the bitstring, commencing
with the first bit and proceeding to the last bit, are placed in
bits 8 to 1 of the first octet, followed by bits 8 to 1 of each
subsequent octet in turn, followed by as many bits as are needed of
the final subsequent octet, commencing with bit 8.
i.e the BITS type is encoded in big-endian form.
Which is what you are seeing.
Dave
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
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
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
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
