Re: snmpwalk is sending an exact request when walking a tree

"mn kh" <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <[email protected]>
Hi Mike,

[ The first time I replied to u the list was automatically CC, I thought it
always is sorry about that]

Here is the ouput of snmpgetnext:
[[jinny@florida bin]$ ./snmpgetnext -c public localhost
JINNY-MMSC-MIB:msend-ok
Timeout: No Response from localhost.
[jinny@florida bin]$ ./snmpgetnext -c public localhost
JINNY-MMSC-MIB:smsnot-ok
JINNY-MMSC-MIB::smsnot-ok.0 = Counter32: 0

I am trying to realise the same thing that I hvae already did using a
dynamically loaded subagent. In fact, I have my counters in a shared memory,
the number of these counters is dynamic and they can increase in number
(they can also decrease). What I am trying to do is register the same
function for all the counters I already defined in the MIB. Then when I
receive an snmpwalk for example, I search my shared memory for the counter
that was requested, if found i return the value, if not i send a null  the
snmpwalk goes to the next oid in the registered counters and asks for it
(This is what i did in the dynamic subagent and it works perfectly). When I
tried to do the same thing in subagent agentx I came to this problem, it
seems like the tree isn't walked in a proper way and this results a timeout
if i didn't set it using the -t parameter. I have noticed that when a value
is returned to the findVar function (meaning that I dont return a NULL) the
snmpwalk goes to the next oid and walks the tree in a proper way.

u_char *var_jAgentX(struct variable *vp, oid *name, size_t *length, int
exact, size_t *var_len,
                  WriteMethod **write_method)


1-Could you please tell me what is the difference between vp->name and name?
In fact in a snmpwalk request shouldn't vp->name contain the parent node and
name is the leaf demanded this is what I thought? am I right?
I am going to expalin to u what is happening form a coding point of view

1-snmpwalk is called with name= JINNY-MMSC-MIB:msend-total and exact=1.
2-header generic is called header_generic(vp, name, length, exact, var_len,
write_method)
3-header generic failed (btw can u please tell me y is it failing i can't
seem to find any information regarding this)
4-I return NULL
5-snmpwalk is called again but this time with exact=0 and name=
JINNY-MMSC-MIB:msend-total and vp->name= JINNY-MMSC-MIB:msend-total
6-header generic is called header_generic(vp, name, length, exact, var_len,
write_method)
7-header generic succeed and vp->name= JINNY-MMSC-MIB:msend-total and name=
JINNY-MMSC-MIB:msend-total.0
8-my function searches for the counter in shared memory, if not found i
return null (in my case it doesnt exist in the shared memory so i return
null)
9-snmpwalk is called again with exact=0 and vp->name
:=JINNY-MMSC-MIB:msend-ok and name= JINNY-MMSC-MIB:msend-total
10- header generic is called header_generic(vp, name, length, exact,
var_len, write_method)
11--header generic succeed and vp->name= JINNY-MMSC-MIB:msend-ok and name=
JINNY-MMSC-MIB:msend-ok.0
12-counter not found retrun NULL
13-snmpwalk called with exact=0 and vp->name = JINNY-MMSC-MIB:msend-error
and name= JINNY-MMSC-MIB:msend-total
....
It continues like this with name always equal JINNY-MMSC-MIB:msend-total and
vp->name incrementing based on the tree till a counter that exist in the
shared memory is found and here is what happens:
1-snmpwalk is called with exact=0 and name= JINNY-MMSC-MIB:msend-total and
vp->name = JINNY-MMSC-MIB:smsnot-total
2-header generic is called header_generic(vp, name, length, exact, var_len,
write_method)
3-header generic succeed and vp->name= JINNY-MMSC-MIB:smsnot-total and name=
JINNY-MMSC-MIB:smsnot-total.0
4-counter FOUND return the (u_char*)&val
5-snmpwalk is called with name= JINNY-MMSC-MIB:msend-ok and exact=1.
 6-header generic is called header_generic(vp, name, length, exact, var_len,
write_method)
7-header generic failed
8-I return NULL
9-snmpwalk is called again but this time with exact=0 and name=
JINNY-MMSC-MIB:msend-ok and vp->name= JINNY-MMSC-MIB:msend-ok
 10- header generic is called header_generic(vp, name, length, exact,
var_len, write_method)
11--header generic succeed and vp->name= JINNY-MMSC-MIB:msend-ok and name=
JINNY-MMSC-MIB:msend-ok.0
12-counter not found return NULL
13-snmpwalk is called  with exact=0 and name= JINNY-MMSC-MIB:msend-ok and
vp->name= JINNY-MMSC-MIB:msend-error
14-header generic is called header_generic(vp, name, length, exact, var_len,
write_method) 15-header generic succeed and vp->name=
JINNY-MMSC-MIB:msend-error and name= JINNY-MMSC-MIB:msend-error.0

...
and it continues like this till another counter is found in the shared
memory and the process is repeated. I am a nwebie in snmp but it seems that
there is smthg wrong its like there a confusion between a node and a leaf, I
first thought that i have registered the mib in a wrong way, but i triple
checked it everythg seems perfect. I hope you can help me with these new
information. I am very thankfull for your time, please inform me if you need
more information

Thank You
Regards,





On Wed, Jul 9, 2008 at 8:33 PM, Mike Ayers <[email protected]> wrote:

>
>        [Please always CC the list.  This may be of value to others.]
>
>        First, there was a typo in my previous email (well, there's typos in
> most of my emails, but they're usually not significant).  The second request
> to try should have been `snmpgetnext JINNY-MMSC-MIB:msend-ok`, not
> "snmpget".  The response you got was the correct response for the bad
> command, if you are using SNMPv1, which you appear to be.
>
>        You explain that you are trying to implement sparse scalars of type
> Counter.  This is valid SNMP, but it may not be supported by your
> implementation methodology.  How, exactly, are you implementing these, from
> a coding standpoint?
>
>
>        Thanks,
>
> Mike
>
> > -----Original Message-----
> > From: mn kh [mailto:[email protected]]
>  > Sent: Tuesday, July 08, 2008 11:45 PM
> > To: Mike Ayers
> > Subject: Re: snmpwalk is sending an exact request when walking a tree
> >
> > I just want to add that the reason of the following
> > [jinny@florida bin]$ ./snmpget -c public localhost
> > JINNY-MMSC-MIB:msend-ok
> > Error in packet
> > Reason: (noSuchName) There is no such variable name in this MIB.
> > Failed object: JINNY-MMSC-MIB::msend-ok
> >
> > is the fact that in my implementation i don't accept this
> > kind of requests and i return NULL
> >
> > and I have one more question if you don't mind, if i have to
> > set the counter in my MIB how do i do it? and if i did will
> > the snmpwalk display the counter with the default value or
> > won't display it at all (I don't want to display it at all)
> >
> > Thanks,
> > Regards
> >
> >
> > On Wed, Jul 9, 2008 at 9:28 AM, mn kh
> > <[email protected]> wrote:
> >
> >
> >
> >       Hi Mike,
> >
> >       Before I even sent this email I tried smthg like the
> > following in the function pointed to by findVar.
> >       if (counter not found in shared memory)
> >       {
> >       //return NULL
> >       val=0
> >       return &val
> >       }
> >
> >       the problem is that snmpwalk dispalys the counter that
> > exists in the MIB even if it doesn't exist in the shared
> > memory which is not what i want, I aim for not dispalying the
> > counter if it doesn't  exist in the shared memory.
> >
> >       Concerning the question u asked abt snmpget the output
> > is the following
> >
> >       [jinny@florida bin]$ ./snmpget -c public localhost
> > JINNY-MMSC-MIB:msend-ok.0
> >       JINNY-MMSC-MIB::msend-ok.0 = Counter32: 0
> >       [jinny@florida bin]$ ./snmpget -c public localhost
> > JINNY-MMSC-MIB:msend-ok
> >       Error in packet
> >       Reason: (noSuchName) There is no such variable name in this MIB.
> >       Failed object: JINNY-MMSC-MIB::msend-ok
> >
> >       It retrieves the value in under a second but i probably
> > should note that the counter msend-ok doesnt exist in my
> > shared memory why was a 0 returned shouldn't it return a
> >       "JINNY-MMSC-MIB:msend-ok.0: Unknown Object Identifier" message.
> >
> >       I also tried the same thing on a counter that exists in
> > the shared memory:
> >
> >       [jinny@florida bin]$ ./snmpget -c public localhost
> > JINNY-MMSC-MIB:smsnot-ok.0
> >
> >       JINNY-MMSC-MIB::smsnot-ok.0 = Counter32: 0
> >
> >       [jinny@florida bin]$ ./snmpget -c public localhost
> > JINNY-MMSC-MIB:smsnot-ok
> >       Error in packet
> >       Reason: (noSuchName) There is no such variable name in this MIB.
> >       Failed object: JINNY-MMSC-MIB::smsnot-ok
> >
> >       In addition, is this output "There is no such variable
> > name in this MIB" normal?
> >
> >       Thank You
> >       Regards,
> >
> >       On Wed, Jul 9, 2008 at 12:49 AM, Mike Ayers
> > <[email protected]> wrote:
> >
> >
> >
> >               > From: mn kh [mailto:[email protected]]
> >               > Sent: Monday, July 07, 2008 11:25 PM
> >
> >
> >               > 1-all of my MIB object instances are of Counter type,
> >               > shouldn't I return NULL?
> >
> >
> >                      Never!
> >
> >               Counter32 ::=
> >                  [APPLICATION 1]
> >                      IMPLICIT INTEGER (0..4294967295)
> >
> >                      You must define an initial value for
> > your counter (note that this may be any valid value - the
> > value 0 has no special meaning syntactically, but typically
> > has semantic meaning and is usually used as an initial
> > value).  You may increment that value, by any amount, during
> > subsequent reads, as your business logic demands, but it must
> > never decrease or present a negative or null value.
> >
> >
> >               > 2-when I used a dynamically loaded subagent,
> > and I send the
> >               > same request (snmpwalk), the exact variable
> > is 0 in contrast
> >               > to the agentx subagent which sends exact=1 and then it
> >               > becomes 0 so I thought there is smthg wrong? is there?
> >
> >
> >                      Probably not.  If you are getting the
> > correct value returned, then don't worry about this.  This is
> > probably just an artifact of registration/implementation details.
> >
> >
> >               > 3-I have added to the end of file my MIB
> > implementation,
> >               > there are no tables in this MIB
> >
> >
> >                      Yep.  I understand a lot more now, thanks.
> >
> >
> >               > 4-what I ment in my -t argument is that when
> > I increase the
> >               > timeout and after that snmpwalk walk the tree
> > thousands of
> >               > times (I think) it outputs the correct the
> > result but this is
> >               > only when i increse the timeout
> >
> >
> >                      First, let's not use snmpwalk yet, as it
> > is an application, not a command.  I would suggest starting
> > with `snmpget JINNY-MMSC-MIB:msend-ok.0` to test the value
> > retrieval, then `snmpget JINNY-MMSC-MIB:msend-ok` to test the
> > search.  In each case, observe the time needed to execute the
> > command.  If it executes in under a second, that's good
> > enough for now, otherwise, you may want to examine your
> > implementation.  I suspect the delays were caused by your
> > nulls, but if not, please try to isolate a single SNMP
> > command that exhibits the bad behavior.
> >
> >
> >                      HTH,
> >
> >               Mike
> >
> >
> >
> >
> >
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.