On 07/08/06, Leo Lei <[EMAIL PROTECTED]> wrote:

> trapsink        localhost
> monitor exist_test .1.3.6.1.4.1.2021.2.1.2
>
> complaining error message when starting the snmpd:
> netsnmp_assert pss->s_snmp_errno != (-11) failed snmp_api.c:3119 snmp_build()

> maybe some one can tell me why this happened, thank you~!

I can tell you why it happened - unfortunately, I don't have a fix.

The agent is choking when encoding the varbind list for the trap PDU -
in particular, the fifth varbind payload - .1.3.6.1.2.1.88.2.1.5.0.
This is DISMAN-EVENT-MIB::mteHotValue - the value of the monitored
object that triggered the trap.

Normally, this is an integer-based object, with an integer value (as
per the definition of mteHotValue).  But in the case of existence
tests, the object being monitored need not be integer-valued, and may
not have a value at all.

That seems to be what's happening here - the trigger fires and the
agent is given a non-existent value to include in the trap.   That
confuses the code to encode the trap (since the varbind type is '0'),
with the error you've seen.

I raised this issue with the IETF working group a couple of years ago,
but never got a sensible answer.  That was a purely theoretical
concern at the time, but it's now surfaced to bite us for real.

I'm not quite sure what the best way forward is - it may prove
necessary to drop this varbind altogether.  We probably need to go
back to the IETF WG, and see if we can get a more helpful response.

Dave

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
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

Reply via email to