SNMPSET failure for BITS
Sam K. Sankoorikal
--------------070809060609050604010103
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
Well we have just changed the following file and the problem
associated with BITS seems to be sorted out. The change is as follows:
snmp_api.c +6461
6461c6461
< snmp_pdu_add_variable(pdu, name, name_length, ASN_BIT_STR,
---
> snmp_pdu_add_variable(pdu, name, name_length, ASN_OCTET_STR,
Any clarification for the issues sought in previous mail would
be very helpful.
Thanks and Regards,
Sam.
Sam K. Sankoorikal wrote:
> Hi ,
>
> There is a clarification that we need for the BITS type of
> objects. The scenario and problems are described below.
>
> *Problem Scenario:*
>
> MIB:
>
> exampleServiceType OBJECT-TYPE
> SYNTAX BITS {
> firestbit (0),
> secondbit (1),
> }
> MAX-ACCESS read-create
>
> *The following command is issued:*
>
> /usr/local/bin/snmpset -v 2c -c public 10.114.5.248 "OID of
> exampleServiceType" b 0
>
> (netsnmp version 5.0.3)
>
> *The response is:*
>
> Error in packet.
> Reason: wrongType (The set datatype does not match the data type the
> agent expects)
> Failed object: "OID of exampleServiceType"
>
> *In the Agent the DEBUG message is:*
>
> "write to exampleServiceType not ASN_BIT_STR"
>
> *On debuggin the code(write_method) we find that the type and data
> length is*:
>
> var_val_type=4, var_val_len=1.
>
> This implies that the agent has received it as a ASN_OCTET_STR instead
> of a ASN_BIT_STR(3)
>
>
> *Clarifications required:*
>
> 1. Are we seeing a bug in snmpset ?
>
> 2. The same operation was repeated with tkmib by setting it to the
> option equivalent to bit 0 being set . This time however the type was
> matching(ASN_BIT_STR) but in the write_method the *var_val did not
> show an expected value.
>
> *var_val: Expected value: *0x80*
>
> *var_val: Actual value: "*firstbit"* --> Are we expected to support
> also string mapping.
>
> 3. Is there any other value allowed other than the value indicating
> the bit being set. For eg 0x60 indicates 0110 0000?
>
> 4. How do we set multiple bits of the same OID? In tkmib, only a
> single bit set is allowed in a single set. Tkmib does not give an
> option to set BITS type on any general OID but if one were to click on
> the object "exampleServiceType" and then click "set", the user can now
> set a bit.
>
> 5. How is bits implementation to be handled in the agent to suite all
> kinds of managers?
>
>
> Thanks and Regards,
> Sam.
>
> --
> Sam K. Sankoorikal.
> Home Net Solutions <http://www.wipro.com/homenet> ,
> Wipro Technologies <http://www.wipro.com>
> Ganapa Complex,
> #53/1 Hosur Rd Madivala,
> Bangalore, India 560068
> PBX: +91 80 5502001 extn 3114
> sam.ku...@wipro.com
>
>
>
--
Sam K. Sankoorikal.
Home Net Solutions <http://www.wipro.com/homenet> ,
Wipro Technologies <http://www.wipro.com>
Ganapa Complex,
#53/1 Hosur Rd Madivala,
Bangalore, India 560068
PBX: +91 80 5502001 extn 3114
sam.ku...@wipro.com
--------------070809060609050604010103--
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Net-snmp-coders mailing list
Net-snm...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Wes Hardaker
Sam> This implies that the agent has received it as a ASN_OCTET_STR instead of a
Sam> ASN_BIT_STR(3)
It should be a ASN_OCTET_STR. The ASN_BIT_STR is a type dropped from
SMIv1 onward in favor of the BITS macro, which is just a definition
sitting on top of a normal ASN_OCTET_STR.
Sam> 4. How do we set multiple bits of the same OID? In tkmib, only a
Sam> single bit set is allowed in a single set.
I never quite finished implementing the bits support in tkmib...
sorry. snmpset handles it perfectly though.
--
Wes Hardaker
Please mail all replies to net-snm...@lists.sourceforge.net
Gino Mathews Kunnumpurath
The change we made was from ASN_OCTET_STR to ASN_BIT_STR in snmp_api.c in line number 6461 for both netsnmp 5.0.3 and 5.0.6.
Please let us know what is the actual correction that has to be made.
regards and thanks
gino mathews.
-----Original Message-----
From: Wes Hardaker [mailto:hard...@users.sourceforge.net]
Sent: Thu 12/5/2002 8:04 PM
To: Sam Kuruvilla Sankoorikal
Cc: net-snm...@lists.sourceforge.net; Gino Mathews Kunnumpurath
Subject: Re: SNMPSET failure for BITS
>>>>> On Thu, 05 Dec 2002 17:46:32 +0530, "Sam K. Sankoorikal" <sam.ku...@wipro.com> said:
>> snmp_pdu_add_variable(pdu, name, name_length, ASN_OCTET_STR,
That's what's in the most recent code base, so...
Wes Hardaker
Gino> The change we made was from ASN_OCTET_STR to ASN_BIT_STR in
Gino> snmp_api.c in line number 6461 for both netsnmp 5.0.3 and 5.0.6.
Ah, then that's wrong. It should be an ASN_OCTET_STR. BITS == ASN_OCTET_STR
David T. Perkins
Don't do this change because it is WRONG! Data type BITS is encoded
as OCTET STRING! Read the RFCs. See RFC 1906.
Regards,
/david t. perkins
Sam K. Sankoorikal
--------------020701040407030004090405
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hi David,
Thanks for the RFC reference. Well BITS actually maps to
ASN_OCTET_STR. We find that the mib2c does the code generation for BITS
type as ASN_BITS_STR... This has now been corrected to ASN_OCTET_STR in
the mib code(write_method ).
Thanks,
Sam.
David T. Perkins wrote:
--
Sam K. Sankoorikal.
Home Net Solutions <http://www.wipro.com/homenet> ,
Wipro Technologies <http://www.wipro.com>
Ganapa Complex,
#53/1 Hosur Rd Madivala,
Bangalore, India 560068
PBX: +91 80 5502001 extn 3114
sam.ku...@wipro.com
--------------020701040407030004090405--
Wes Hardaker
Sam> Thanks for the RFC reference. Well BITS actually maps to
Sam> ASN_OCTET_STR. We find that the mib2c does the code generation
Sam> for BITS type as ASN_BITS_STR... This has now been corrected to
Sam> ASN_OCTET_STR in the mib code(write_method ).
The old mib2c did that a long time ago. I don't think the current one
does? (in fact, I know it doesn't because I just checked).
--
Wes Hardaker
Please mail all replies to net-snm...@lists.sourceforge.net