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:
[EMAIL PROTECTED] bin]$ ./snmpgetnext -c public localhost
JINNY-MMSC-MIB:msend-ok
Timeout: No Response from localhost.
[EMAIL PROTECTED] 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
> > [EMAIL PROTECTED] 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
> >
> > [EMAIL PROTECTED] bin]$ ./snmpget -c public localhost
> > JINNY-MMSC-MIB:msend-ok.0
> > JINNY-MMSC-MIB::msend-ok.0 = Counter32: 0
> > [EMAIL PROTECTED] 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:
> >
> > [EMAIL PROTECTED] bin]$ ./snmpget -c public localhost
> > JINNY-MMSC-MIB:smsnot-ok.0
> >
> > JINNY-MMSC-MIB::smsnot-ok.0 = Counter32: 0
> >
> > [EMAIL PROTECTED] 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
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
