Octet string index problem in net-snmp

Hi,

I am using net-snmp version 5.4.1 from Linux.

I am using octet string as index into the table. When
sending SNMP request during walk or Get, why net-snmp
is sending the octet-string index with integer tag 02
instead of octetstring tag 04?

if the index is of size Octet String(6) and it is some
system-id say:22 22 33 33 44 44.
The index part in reuqest is sent as 02 22 22 33 33 44
44 and not as 04 06 22 22 33 33 44 44.

Is it a bug in net-snmp? How will I over come this
bug.

I have to use -Ob option in the request to get the
proper index values in the integer format. ie. 22 will
be displayed as 34 in this example. otherwise index is
displayed junk ascii chars.

Thanks in advance.

-Alamelu Ramadurai


--- Mike Ayers <mike_ayers@tvworks.com> wrote:

> > From: net-snmp-users-bounces@lists.sourceforge.net
>
> >
>
[mailto:net-snmp-users-bounces@lists.sourceforge.net]
> On
> > Behalf Of McGowen, Wendy
> > Sent: Wednesday, January 09, 2008 9:43 AM
>
> > Ok, so do you mean that I shouldn't put anything
> that's already in
> > MIB-II in our private MIB if we include MIB-II
> support in our product?
>
> I'll go one step farther and say that you should
> not duplicate support from any standard, available
> MIB in your private MIB. This is not only due to
> the standardization issues Dave mentioned, but also
> because setting up proper management for things that
> seem trivial at first can be very difficult.
>
> > When I said "the same data" I really should have
> said that there might
> > be a few data points that would be duplicated
> between the 2 (like IP
> > addresses).
>
> IPv4? IPv6? How to tell which one (or more) to
> use. Are you sure you'll get this notoriously
> tricky area right? Enable IF-MIB, and work with it,
> and one big headache becom,es a manageable problem.
>
> > Would it be best to just not include any default
> > MIB support
> > and only support our private MIB in that case?
>
> As above, I think not. Often it is believed that
> putting everything in a private MIB will keep things
> less complicated and allow the scope to be
> restrained, but it really translates to a separate
> development effort, one in which expertise is
> lacking.
>
> > I was told that most
> > shops would want at least MIB-II support, and then
> if they want to
> > peruse our data they could go to our enterprise
> OID. And I've
> > been told
> > that it's really traps that are the most important
> aspect of our SNMP
> > support (from our customer's perspective), so I'm
> not even
> > sure how our
> > "private" data will be used, if at all, by the
> customer.
>
> In the end, your customers will decide what data
> interests them, but the scope you mention above
> sounds about right.
>
> > Our GUI doesn't use SNMP - it's CIM based (not my
> choice).
> > We're adding
> > SNMP support after-the-fact, so they want the SNMP
> data to
> > "mirror" what
> > we're doing in CIM (and even there we defined
> everything under our own
> > objects).
>
> Ah! This is the one case where it may be
> acceptable to put everything in your own mib - if
> and only if it's a mirror, then make everything the
> same.
>
> Note that if you give the mirror to a true SNMP
> house, they probably won't be very happy about it.
>
>
> HTH,
>
> Mike
>
>
-------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
http://ad.doubleclick.net/clk;164216...et/marketplace
> _______________________________________________
> 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/...net-snmp-users
>



__________________________________________________ __________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i...Dypao8Wcj9tAcJ


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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/...net-snmp-users