Snmptrapd crashes when forwarding SNMPv3 notifications

Dear all

I like to forward SNMPv3 traps from one notification receiver (snmptrapd) to
another. I have the following simple config:


receiver1:

createUser boris SHA borisboris AES borisboris
authUser log,execute,net boris noauth

forward default localhost:3000

snmpTrapdAddr 0.0.0.0:2000


receiver2:

createUser boris SHA borisboris AES borisboris
authUser log,execute,net boris noauth

snmpTrapdAddr 0.0.0.0:3000


then I start both receivers:


/usr/local/sbin/snmptrapd -f -C -c snmptrapd1.conf -Le

/usr/local/sbin/snmptrapd -f -C -c snmptrapd2.conf -Le


Now, I try to send a trap to receiver1 (I use noAuthNoPriv for simplicity).
This gives a timeout on the sender and the receiver1 crashes with segfault
after having logged the incoming trap.

snmptrap -Ci -v3 -u boris -l noAuthNoPriv localhost:2000 0 linkUp.0
snmpinform: Timeout (Sub-id not found: (top) -> linkUp)


receiver1:
2011-08-23 10:52:01 localhost [UDP: [127.0.0.1]:40308->[127.0.0.1]]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkUp.0
Segmentation fault


This is the gdb stack trace:

(gdb) bt
#0  0x00007ffff5cce43e in memcpy () from /lib64/libc.so.6
#1  0x00007ffff60275d3 in MD5_Update () from /lib64/libcrypto.so.1.0.0
#2  0x00007ffff63cac8f in sc_hash (hashtype=<value optimized out>,
hashtypelen=10,
    buf=0x6 <Address 0x6 out of bounds>, buf_len=1, MAC=0x7fffffffac20 "",
MAC_len=0x7fffffffac18) at scapi.c:460
#3  0x00007ffff63c895b in hash_engineID (engineID=<value optimized out>,
engineID_len=<value optimized out>)
    at lcd_time.c:503
#4  0x00007ffff63c89fa in search_enginetime_list (engineID=0x6 <Address 0x6
out of bounds>, engineID_len=1)
    at lcd_time.c:440
#5  0x00007ffff63c8ca8 in get_enginetime (engineID=0x6 <Address 0x6 out of
bounds>, engineID_len=1,
    engineboot=0x7fffffffbd7c, engine_time=0x7fffffffbd78,
authenticated=<value optimized out>) at lcd_time.c:124
#6  0x00007ffff63de983 in usm_rgenerate_out_msg (msgProcModel=<value
optimized out>,
    globalData=0x656d8d "\002\001\003\060\021\002\004\033W\026\256\002\003",
globalDataLen=22,
    maxMsgSize=<value optimized out>, secModel=<value optimized out>,
secEngineID=0x6b9820 "\200",
    secEngineIDLen=17, secName=0x6b9860 "boris", secNameLen=5, secLevel=1,
scopedPdu=0x6bc040 "0N\004\021\200",
    scopedPduLen=80, secStateRef=0x682740, wholeMsg=0x7fffffffc038,
wholeMsgLen=0x7fffffffc030,
    offset=0x7fffffffc028) at snmpusm.c:1470
#7  0x00007ffff63e06f2 in usm_secmod_rgenerate_out_msg (parms=<value
optimized out>) at snmpusm.c:1267
#8  0x00007ffff63a221e in snmpv3_packet_realloc_rbuild (pkt=0x7fffffffc038,
pkt_len=0x7fffffffc030,
    offset=0x7fffffffc028, session=0x658360, pdu=0x6b96e0, pdu_data=<value
optimized out>, pdu_data_len=0)
    at snmp_api.c:2748
#9  0x00007ffff63a2c39 in snmpv3_build (pkt=0x7fffffffc038,
pkt_len=0x7fffffffc030, offset=0x7fffffffc028,
    pss=0x658360, pdu=0x6b96e0) at snmp_api.c:2335
#10 _snmp_build (pkt=0x7fffffffc038, pkt_len=0x7fffffffc030,
offset=0x7fffffffc028, pss=0x658360, pdu=0x6b96e0)
    at snmp_api.c:2906
#11 snmp_build (pkt=0x7fffffffc038, pkt_len=0x7fffffffc030,
offset=0x7fffffffc028, pss=0x658360, pdu=0x6b96e0)
    at snmp_api.c:3243
#12 0x00007ffff63a82f2 in _sess_async_send (sessp=0x6a4950, pdu=0x6b96e0,
callback=0, cb_data=0x0)
    at snmp_api.c:5052
#13 snmp_sess_async_send (sessp=0x6a4950, pdu=0x6b96e0, callback=0,
cb_data=0x0) at snmp_api.c:5212
#14 0x00007ffff7bd92b3 in snmp_input (op=<value optimized out>,
session=0x658360, reqid=<value optimized out>,
    pdu=0x6b8bb0, magic=0x698480) at snmptrapd_handlers.c:1066
#15 0x00007ffff63ac974 in _sess_process_packet (sessp=0x6a4950, sp=0x658360,
isp=0x6a4680,
    transport=<value optimized out>, opaque=0x6a46f0, olength=<value
optimized out>,
    packetptr=0x6a8ba0
"0\201\216\002\001\003\060\021\002\004\033W\026\256\002\003", length=145) at
snmp_api.c:5604
---Type <return> to continue, or q <return> to quit---
#16 0x00007ffff63ad27a in _sess_read (sessp=0x6a4950, fdset=<value optimized
out>) at snmp_api.c:6043
#17 0x00007ffff63ae0b9 in snmp_sess_read2 (sessp=0x6a4950, fdset=<value
optimized out>) at snmp_api.c:6075
#18 0x00007ffff63ae17b in snmp_read2 (fdset=0x7fffffffc660) at
snmp_api.c:5667
#19 0x00007ffff63ae1c4 in snmp_read (fdset=0x7fffffffc860) at
snmp_api.c:5657
#20 0x0000000000404b56 in main (argc=<value optimized out>, argv=<value
optimized out>) at snmptrapd.c:1283



Remark 1:

Sending the trap directly to receiver2 with

snmptrap -Ci -v3 -u boris -l noAuthNoPriv localhost:3000 0 linkUp.0

works! The trap is logged from the receiver as expected.


Remark 2:

Using SNMPv2 notifications everything works! A trap sent to receiver1 is
forwarded to receiver2 and logged there...


Remark 3:

I tried with 5.5, 5.6 and 5.7. Always the same behaviour.


Is forwarding v3 traps really possible? I guess the forward handler of
snmptrapd can not simply 'forward' the trap, it had to encrypt it for the
receiver and do the whole engineId probing etc. Is this supported?


Thanks a lot for any help!

Regards

Boris

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2

_______________________________________________
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