Hello Dave,
first of all thank you very much for your detailed answer.
>When you talk about "leaf handlers", do you mean the handlers for scalar
> objects, or the handlers for column objects within a table
Im just using scalar objects.
> What sort of registration ca
On 1 March 2011 13:04, Reto Jaeger wrote:
> I have implemented an snmp subagent using the agent-x protocol.
> When I do a snmpwalk operation I see that all leaf handlers are called
> twice. The leaf handlers are called once (as expected) when I performing
> a snmpget operation.
W
On 2 March 2011 17:38, Reto Jaeger wrote:
> > What sort of registration call(s) are you using?
>
> netsnmp_register_scalar(...)
In which case, the routine handle_callState() should only be called once
for each request.
If you're seeing it invoked twice, then my suspicion is that the agent
is rec
Hi,
I have implemented an snmp subagent using the agent-x protocol.
When I do a snmpwalk operation I see that all leaf handlers are called
twice.
The leaf handlers are called once (as expected) when I performing a
snmpget operation.
My question is: Why the leaf handlers called twice on a
Is it safe to make requests such as get from the same
> subagent process that has registered and handlers the values requested.
>
> >>>>> On Thu, 14 Oct 2010 15:32:25 -0600, "Marc Butler"
> said:
>
> MB> I have a subagent using the AgentX protocol. Fro
>>>>> On Thu, 14 Oct 2010 15:32:25 -0600, "Marc Butler"
>>>>> said:
MB> I have a subagent using the AgentX protocol. From the same process I
MB> need to make requests to the master agent using
MB> snmp_synch_response(). To complicate ma
Hi,
I have a subagent using the AgentX protocol. From the same process I need to
make requests to the master agent using snmp_synch_response(). To complicate
matters, requests for values that have handlers registered in the process, will
also be routed through the master agent.
That is
2009/4/8 Giuseppe Modugno :
> Is there a complete list (in any documentation pages or in the source
> code) of these "helpers"?
$ ls agent/helpers
Dave
--
This SF.net email is sponsored by:
High Quality Requirements i
I'm going to extend Net-SNMP agent writing a dynamically loadable
module. I'm studying the documentation and found the concept of
"helper handlers". I think they are very good and I'm almost sure to
use some of them to code my agent extension.
Is there a complete l
2009/3/31 Tarun Kumar :
> I have generated an agentX based subagent, but when I am running it, its
> table handlers are never called. This MIB contains some scalars variables,
> which are being called perfectly but some problem with the table handlers
> e.g in the
On 29/03/07, Sriventhal B <[EMAIL PROTECTED]> wrote:
> Can anybody tell me the exact working of the handlers.
> 1. when it is created
When the agent is initialised.
> 2.is it created once or each time a request comes
Once
> 3.is the handler destroyed,i
Hi all
Can anybody tell me the exact working of the handlers.
1. when it is created
2. is it created once or each time a request comes
3. is the handler destroyed,if yes when and how
Please respond at the earliest as we are really in need of ur help
Thanks and Regards
Subashini
On 20/03/07, Kobi Vaknin (kvaknin) <[EMAIL PROTECTED]> wrote:
> I've 2 tables entityStateTable (from the ENTITY-MIB) and the ccCopyTable
> (from CISCO-CONFIG-COPY-MIB) when i walk on the table
> entityStateTable the agent triggered ,also, the ccCopyTable handler ,
Yes - that's correct.
Remember
Hello All
In my Net-SNMP ,version 5.2.2 ,the agent trigger handlers that not
relevant for the specific request,
EXAMPLE:
I've 2 tables entityStateTable (from the ENTITY-MIB) and the ccCopyTable
(from CISCO-CONFIG-COPY-MIB) when i walk on the table
entityStateTable the agent triggered
> On Wed, 18 Jan 2006 21:10:50 +0100, Magnus Fromreide <[EMAIL PROTECTED]>
> said:
Robert> They shouldn't return ENDOFMIBVIEW, they should set the request error to
Robert> ENDOFMIBVIEW and return success/noerror.
Magnus> Ok, but if I return SUCCESS and sets the request error to
Magnus> E
On Wed, Jan 18, 2006 at 02:38:11PM -0500, Robert Story wrote:
> On Wed, 18 Jan 2006 20:21:29 +0100 Magnus wrote:
> MF> It seems that delegated handlers that return ENDOFMIBVIEW as response to
> MF> a GETNEXT request won't trigger any further advancement in the registry so
>
On Wed, 18 Jan 2006 20:21:29 +0100 Magnus wrote:
MF> It seems that delegated handlers that return ENDOFMIBVIEW as response to
MF> a GETNEXT request won't trigger any further advancement in the registry so
MF> they might end up returning a false ENDOFMIBVIEW (or, in some cases, an
MF
Hello!
It seems that delegated handlers that return ENDOFMIBVIEW as response to
a GETNEXT request won't trigger any further advancement in the registry so
they might end up returning a false ENDOFMIBVIEW (or, in some cases, an
NOSUCHOBJECT or NOSUCHINSTANCE)
Is this all intentional?
What
dear everyone,
We have registered a new project in sourceforge and the URL is
http://sourceforge.net/projects/lvm-mib
It includes a set of Net-SNMP MIB handlers and corresponding SNMP MIB
definition to Get/Set Linux LVM informations.
The handlers were written by
Hi Igor.
Nice problem description.
There was a bug with registering ranges on the last item in versions less than
5.2, so I'd suggest that you upgrade.
/MF
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hu
Hello every body,
I did a lot of playing recently with registering handlers for extended range
of the oids. When I setup up range_subid to the *length* of the registration
oid of the handler (and also setup some upper limit with range _ubound),
appropriate handler is *not called* for range
On Wed, 17 Nov 2004 22:41:50 +0100 Magnus wrote:
MF> On Wed, Nov 17, 2004 at 03:39:09PM -0500, Robert Story wrote:
MF> > On Wed, 17 Nov 2004 20:46:01 +0100 Magnus wrote:
MF> > MF> It seems as if netsnmp_register_instance doesn't set the
MF> > MF> FULLY_QUALIFIED_INSTANCE flag on the registration an
On Wed, Nov 17, 2004 at 03:39:09PM -0500, Robert Story wrote:
> On Wed, 17 Nov 2004 20:46:01 +0100 Magnus wrote:
> MF> It seems as if netsnmp_register_instance doesn't set the
> MF> FULLY_QUALIFIED_INSTANCE flag on the registration and further it looks
> MF> as if the handler interface doesn't supp
On Wed, 17 Nov 2004 20:46:01 +0100 Magnus wrote:
MF> It seems as if netsnmp_register_instance doesn't set the
MF> FULLY_QUALIFIED_INSTANCE flag on the registration and further it looks
MF> as if the handler interface doesn't support sending flags with the
MF> object registration at all as it uses a
Hello.
It seems as if netsnmp_register_instance doesn't set the
FULLY_QUALIFIED_INSTANCE flag on the registration and further it looks
as if the handler interface doesn't support sending flags with the
object registration at all as it uses a constant 0 for the flags parameter
in netsnmp_register_h
;ve used before is to use the data list of the agent request
info pointer. The same agent request pointer is passed to all handlers for teh
varbinds in a given request. In each handler, try to extract the value from the
list. If it isn't there, get the value and put it in the list for any othe
le handler for example.
Sorry - I'm not sure what you mean by that.
>
> Now I have been looking into handlers and it seems that the first
> splitting is done on the target variable level.
or that.
> Is it possible to do what I want using net-snmp handlers?
Unless I'v
for example.
Now I have been looking into handlers and it seems that the first splitting
is done on the target variable level.
Is it possible to do what I want using net-snmp handlers?
/MF
---
This SF.net email is sponsored by: IT Product Guide
On Fri, 02 Jul 2004 09:49:46 +0100 Dave wrote:
DS> RS> What you've proposed is pretty much the way it works now, except
DS> RS> the default for the flag is no auto next.
DS>
DS> Except that I'm suggesting that we have a quick push to convert
DS> *all* the (internal) helpers as far as possible (and
DS> - By default, handlers return success/failure, but don't explicitly
DS> call the next handler in the chain. This is (normally)
DS> done by the main netsnmp_call_next_handler routine.
DS> (i.e. AUTO_NEXT becomes the default)
RS&g
On Thu, 01 Jul 2004 11:15:10 -0700 Wes wrote:
WH> >>>>> On Thu, 1 Jul 2004 13:39:46 -0400, Robert Story (Coders)
WH> DS> - By default, handlers return success/failure, but don't explicitly
WH> DS> call the next handler in the chain. [...]
WH>
WH> Robert&
>>>>> On Thu, 1 Jul 2004 13:39:46 -0400, Robert Story (Coders) <[EMAIL PROTECTED]>
>>>>> said:
DS> Ok - maybe an example would help.[...]
DS>
DS> Robert> Some of the helper handlers, however, do care. Again, bulk_to_next
DS> is the best
On Thu, 01 Jul 2004 12:41:19 +0100 Dave wrote:
DS> Robert> I don't think what I'm proposing takes away any flexibility.
DS>
DS> Ok - maybe an example would help.[...]
DS>
DS> Robert> Some of the helper handlers, however, do care. Again, bulk_to_next
DS> i
a bit strong.
WH>Since we can not and
WH>should not delete the ability to have handlers do things
WH>themselves, it is unlikely it'll save us a huge amount of work if
WH>we change APIs in the future.
Yes, we have to maintain backwards compatibility. But that doesn&
maybe an example would help.
Suppose I'm writing a helper (say to time how long a request takes),
that needs to do something both before and after calling the lower handlers.
With the current pipeline model, that would be:
int stopwatch_helper_handler( )
{
beg
or those with weak stacks.
2) However, Robert is wrong that it helps APIs. Since we can not and
should not delete the ability to have handlers do things
themselves, it is unlikely it'll save us a huge amount of work if
we change APIs in the future. It's much more likely that
On Wed, 30 Jun 2004 15:52:23 +0100 Dave wrote:
DS> Having a set of handlers called "in sequence" is a perfectly reasonable
DS> alternative model. I'm unconvinced as to whether it's necessarily
DS> better than the current "pipeline" model, but it's cert
ink that it's that it's a change from how you understood things
Robert> worked, not that it's a bad idea. I'd bet if it had worked this way
Robert> from the beginning, you wouldn't have thought twice about it.
Probably not, no.
Having a set of handlers called "in
is behaviour belonged at
DS> Robert> a higher level. I've updated several handlers to use it,
DS> eliminating Robert> the redundant loop.
DS>
DS> Errr... what loop?
Oops. Replace 'eliminating the redundant loop' with 'eliminating an
unnecessary function call and
Dave> But now the handler seems to return success or failure immediately,
Dave> without actually calling any lower-level handlers.
Dave> This seems to be at odds with my understanding of the handler design.
Robert> A while ago I added a 'flags' field to the mib handler str
then passes control on to the next handler. I'm pretty sure that
DS> when I first wrote the original cache handler, it took this basic form.
DS>
DS> But now the handler seems to return success or failure immediately,
DS> without actually calling any lower-level handlers. At first si
41 matches
Mail list logo
