Thanks for that tip, Dave! I was already looking at those functions,
using a few printf() around the code, but they were strange.
I went debugging with GDB, and now things are getting even stranger.
I've set the breakpoint at the last 'if' condition it checked before
returning.
(gdb) b agent_trap.c:694
Breakpoint 2 at 0xa7e7ee44: file agent_trap.c, line 694.
(gdb) c
Continuing.
Breakpoint 2, netsnmp_send_traps (trap=-1, specific=-1,
enterprise=0xa7e8c000, enterprise_length=10, vars=0x8092f50,
context=0x0, flags=0)
at agent_trap.c:694
694 if (!trap_vb ||
(gdb) bt full
#0 netsnmp_send_traps (trap=-1, specific=-1, enterprise=0xa7e8c000,
enterprise_length=10, vars=0x8092f50, context=0x0, flags=0) at
agent_trap.c:694
template_v1pdu = (netsnmp_pdu *) 0x8093ad8
template_v2pdu = (netsnmp_pdu *) 0x8091830
vblist = (netsnmp_variable_list *) 0x8093d30
trap_vb = (netsnmp_variable_list *) 0x8093d30
var = (netsnmp_variable_list *) 0x8094b10
pdu_in_addr_t = (in_addr_t *) 0xafa25104
uptime = 14479
sink = (struct trap_sink *) 0xa7da5ff4
__FUNCTION__ = "netsnmp_send_traps"
[...gdb debug snip....]
Just to be clear on what we are talking about:
(gdb) list
689 * 'trap_vb' should point to the snmpTrapOID.0 varbind,
690 * identifying the requested trap. If not then bomb out.
691 * If it's a 'standard' trap, then we need to append an
692 * snmpEnterprise varbind (if there isn't already one).
693 */
694 if (!trap_vb ||
695 snmp_oid_compare(trap_vb->name, trap_vb->name_length,
696 snmptrap_oid, snmptrap_oid_len)) {
697 snmp_log(LOG_WARNING,
698 "send_trap: no v2 trapOID varbind provided\n");
That's the code it is going to check before bailing out with the "no
v2 trapOID varbind provided" message.
trap_vb is not NULL, so there's something nasty going on the compare.
Let's see what those things are? Sure:
(gdb) print snmptrap_oid
$15 = {1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0}
(gdb) print snmptrap_oid_len
$16 = 0
Hmmm... why is snmptrap_oid_len equal 0 ? Shouldn't it be the size of
OID fields of snmptrap_oid?
And, oddly,
(gdb) print trap_vb->name
$17 = (oid *) 0x8093d48
Is trap_vb->name supposed to be a pointer? Yes, it's a pointer to
somewhere. Actually, a pointer to trap_vb->name_loc in that case.
Aaaaand,
(gdb) print trap_vb->name_loc
$20 = {1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0 <repeats 118 times>}
Great! name_loc is the thing we expected it to be.
So, now what: is snmptrap_oid_len broken or am I missing something?
Any help will be greatly appreciated!
Yours,
Felipe
On 8/17/06, Dave Shield <[EMAIL PROTECTED]> wrote:
> On 17/08/06, Felipe openglx <[EMAIL PROTECTED]> wrote:
> > When I
> > ran snmpd, it gave me this error everytime my send_trap function was
> > called:
> >
> > "send_trap: no v2 trapOID varbind provided"
>
>
> > My code looks something like this:
>
> > snmp_varlist_add_variable(&var_list,
> > snmptrap_oid, OID_LENGTH(snmptrap_oid),
> > ASN_OBJECT_ID,
> > dlswTrapCircuitUp_oid,
> > OID_LENGTH(dlswTrapCircuitUp_oid));
>
> No - that looks fine at first glance.
>
> I'd be inclined to run the agent under a debugger, set a breakpoint in
> the send_trap routine (perhaps at the point this message is
> displayed), and have a look at the varbind list of the PDU. How does
> this compare with the list that you were expecting to see?
>
> Dave
>
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
