Thanks for your answere. It helped and now sysORTable works from the
subagent. I'm registring to sysORTable last in the initialization process of
the subagent.
I will wait for the first release of 5.5 before I start to use it. I think I
can survive without the reregistration for now.
Thanks,
Göran
[ First - *please* don't mail me privately, without copying
any responses to the mailing list. I don't have the time
or inclination to offer private, unpaid, SNMP consultancy.
Keep discussions to the list, where others can both learn
and offer advice. Thanks. ]
On Mon, 2
On Mon, 2008-06-23 at 14:02 +0200, Goran wrote:
> Hi
>
> Is it possible to register to the sysORTable from within a subagent?
Yes.
> It works when I register to the sysORTable when compiling the
> nstAgentModuleObject.c into the Agent. If I register to sysORTable
> from the example subagent (nst
On 27/03/2008, Magnus Fromreide <[EMAIL PROTECTED]> wrote:
> Another problem of this patch is that it fails to follow the rules set
> out in 'MIB Module ReWrites'
Note that the policy outlined in this Wiki page currently has no
standing whatsoever. It's just something that I put together
as my
Magnus Fromreide wrote:
> I have a rewrite of sysORTable that have the following advantages and
> disadvantages:
Without having done a full review yet, I must say I like what you did.
I'd be fine with committing it to trunk.
> Another problem of this patch is that it fails to follow the rules set
> "MF" == Magnus Fromreide <[EMAIL PROTECTED]> writes:
MF> The question that rise from this is how to handle sysORTable in
MF> subagents, the obvious way seems to be that sysORTable entries are
MF> automatically reregistered just like mib registrations are.
Probably the best choice... cache
> "MF" == Magnus Fromreide <[EMAIL PROTECTED]> writes:
MF> I was trying to write an agnet module and should register myself
MF> in sysORTable and then got very confused as it looks like the
MF> header file for doing that isn't part of the default install - is
MF> this intentional?
The agent m
