Subject: BITS construct question

From: RP <[email-masked]>
Date: Wed, 11 Oct 2000 08:54:25 +0100

Hi.
I have a basic (I think) question about the BITS construct on the 
DISMAN-SCHEDULE-MIB (also on DISMAN-EVENT-MIB).
To issue an SNMP-SET to, for example, schedMonth to set january and 
december, the command should be:

$ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v 100000000001B

or

$ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v "100000000001"

or

$ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v "january"
$ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v "december"

or

$ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v 0
$ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v 11

?
I tried the AdventNet MIB compiler and it generates code to store a 
String on the schedMonth object and validates it to be one of 
"january","february",...,"december".

I also tried the SMASH MIB compiler and it complaints about the DEFVAL { 
{ } }.

So, what is the data type to send to a BITS object? A string, a byte[], 
an int or other?
I looked the RFCs from 1066 to 2579 to look for how to set a BITS object 
and did not find nothing except that it is an enumeration of named bits. 
Now, how to set an enumeration of named bits? Send the name of the 
corresponding bit, send all the bits in an OCTET STRING or send the 
INTEGER correspondent to the bit position?

Thanks in advance.

Cheers,

Rui Pedro

---

From: Frank Strauss <[email-masked]>
Date: 11 Oct 2000 11:18:50 +0200

RP> I have a basic (I think) question about the BITS construct on the 
RP> DISMAN-SCHEDULE-MIB (also on DISMAN-EVENT-MIB).
RP> To issue an SNMP-SET to, for example, schedMonth to set january and 
RP> december, the command should be:

RP> $ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v 100000000001B
RP> or
RP> $ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v "100000000001"
RP> or
RP> $ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v "january"
RP> $ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v "december"
RP> or
RP> $ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v 0
RP> $ ./set localhost .1.3.6.1.2.1.63.1.2.1.6.x.y.z.v 11
RP> ?

In the sense of SMI syntax the first notation (100000000001B) should
do what you expect. It depends on what your `./set' does to interpret
the last argument. Maybe it is so clever to see from its own MIB
knowledge that `.1.3.6.1.2.1.63.1.2.1.6' is a BITS type and does
the appropriate transformation.

Anyhow, an SMIv2 BITS construct is mapped to an OCTET STRING in the
protocol, where each bit of each octet (except the padding bits)
represents one bit of the BITS construct.

RP> I tried the AdventNet MIB compiler and it generates code to store a 
RP> String on the schedMonth object and validates it to be one of 
RP> "january","february",...,"december".

As far as I understand your description of the generated code, this is
wrong, but maybe I misunderstand what the compiler generated.

RP> I also tried the SMASH MIB compiler and it complaints about the
RP> DEFVAL { { } }.

Seems to be a bad compiler. ;-)

RP> So, what is the data type to send to a BITS object? A string, a
RP> byte[], an int or other?

An OCTET STRING on the wire, whatever your SNMP toolkit matches it to
in your application code.  A byte array would be reasonable along with
some functions to check and modify single bits.

RP> I looked the RFCs from 1066 to 2579 to look for how to set a BITS
RP> object and did not find nothing except that it is an enumeration
RP> of named bits.  Now, how to set an enumeration of named bits? Send
RP> the name of the corresponding bit, send all the bits in an OCTET
RP> STRING or send the INTEGER correspondent to the bit position?

Send all the bits in an OCTET STRING.

See RFC 1906, Section 8 for the exact protocol encoding of BITS:

   (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.  Remaining bits,
        if any, of the final octet are set to zero on generation and
        ignored on receipt.