snmptrapd not processing traps with invalid agent address

O

outta_spac

I'm using using snmptrapd() with custom traphandle script to receive SNMP traps. Some devices on my network add 0x00 byte at the end of their IPs to the agent-addr field in SNMP message so the length of the agent-addr field becomes 5 bytes, which violates BER standard. Snmptrapd seems to not process such traps and traphandle script isn't even called. I'm currently unable to solve the problem on devices' side, can I somehow change snmptrapd behaviour for it to pass malformed traps to traphandle script anyway?
 
you can obviously hack snmptrapd since source code is available but this may complex
you can send the traps to another ip and run a kind of "snmp proxy" written in some scripting language which fixes the packet and sends it back to snmptrapd
you can create an alias ip on the same host
 
Try running snmptrapd with debug enabled (i.e. -f -DALL) and check if it says something about the problem. I am interested in seeing where exactly it refuses to process the trap (if at all) as I am not able to reproduce this without having specific device/agents.
 
outta_spac said:
Some devices on my network add 0x00 byte at the end of their IPs to the agent-addr field in SNMP message so the length of the agent-addr field becomes 5 bytes, which violates BER standard.
Click to expand...
Maybe fix the cause of the issue? Upgrade their firmware to fix the bug or replace those devices?
 
yuripv79 said:
Try running snmptrapd with debug enabled (i.e. -f -DALL) and check if it says something about the problem. I am interested in seeing where exactly it refuses to process the trap (if at all) as I am not able to reproduce this without having specific device/agents.
Click to expand...
Tried running snmptrapd -f -DALL -a -L o, here's normal trap:
Code: 
netsnmp_udp: recvfrom fd 9 got 101 bytes (from UDP: [x.x.x.x]:3073->[0.0.0.0]:0)
transport:recv: 101 bytes from UDP: [x.x.x.x]:3073->[0.0.0.0]:0
trace: _sess_process_packet_parse_pdu(): snmp_api.c, 5595:
sess_process_packet: session 0x801aa1ae0 fd 9 pkt 0x801b34c40 length 101
trace: snmp_parse_version(): snmp_api.c, 3693:
dumph_recv: SNMP Version
dumpx_recv:  02 01 00 
dumpv_recv:    Integer:    0 (0x00)
trace: _snmp_parse(): snmp_api.c, 4317:
snmp_api: Parsing SNMPv1 message...
trace: _snmp_parse(): snmp_api.c, 4324:
dumph_recv: SNMPv1 message

trace: snmp_comstr_parse(): snmp_auth.c, 127:
dumph_recv:   SNMP version
dumpx_recv:    02 01 00 
dumpv_recv:      Integer:    0 (0x00)
trace: snmp_comstr_parse(): snmp_auth.c, 139:
dumph_recv:   community string
dumpx_recv:    04 08 69 70 73 78 69 74 63 68 
dumpv_recv:      String:    super_secret
trace: _snmp_parse(): snmp_api.c, 4373:
dumph_recv:   PDU
trace: snmp_pdu_parse(): snmp_api.c, 4601:
dumpv_recv:     Command TRAP
dumpx_recv:    06 08 2B 06 01 04 01 81 CB 78 
dumpv_recv:      ObjID: SNMPv2-SMI::enterprises.26104
dumpx_recv:    40 04 0A 37 14 76 
dumpv_recv:      String:    
7.v
dumpx_recv:    02 01 06 
dumpv_recv:      Integer:    6 (0x06)
dumpx_recv:    02 01 24 
dumpv_recv:      Integer:    36 (0x24)
dumpx_recv:    43 04 65 00 34 0F 
dumpv_recv:      UInteger:    1694512143 (0x6500340F)
trace: snmp_pdu_parse(): snmp_api.c, 4724:
dumph_recv:     VarBindList
trace: snmp_pdu_parse(): snmp_api.c, 4740:
dumph_recv:       VarBind
trace: snmp_parse_var_op(): snmp.c, 165:
dumph_recv:         Name
dumpx_recv:          06 09 2B 06 01 04 01 81 CB 78 03 
dumpv_recv:            ObjID: SNMPv2-SMI::enterprises.26104.3
trace: snmp_pdu_parse(): snmp_api.c, 4749:
dumph_recv:         Value
dumpx_recv:          04 1F 54 69 6D 65 20 73 65 74 20 74 6F 20 30 39 
2F 31 32 2F 32 30 32 33 20 30 39 3A 34 39 3A 30 
32 
dumpv_recv:            String:    Time set to 09/12/2023 09:49:02
trace: _sess_process_packet_parse_pdu(): snmp_api.c, 5678:
sess_process_packet: received message id#0 reqid#0 len 101
trace: snmp_input(): snmptrapd_handlers.c, 1106:
snmptrapd: input: a4
trace: snmp_input(): snmptrapd_handlers.c, 1164:
snmptrapd: Trap OID: SNMPv2-SMI::enterprises.26104.0.36
trace: snmp_input(): snmptrapd_handlers.c, 1190:
snmptrapd: Running auth trap handlers
trace: netsnmp_trapd_check_auth(): snmptrapd_auth.c, 186:
snmptrapd:auth: Comparing auth types: result=0, request=0, result=1
No access configuration - dropping trap.
[/code

and here's trap with malformed agent-addr:
[code]
netsnmp_udp: recvfrom fd 9 got 140 bytes (from UDP: [x.x.x.x]:3072->[0.0.0.0]:0)
transport:recv: 140 bytes from UDP: [x.x.x.x]:3072->[0.0.0.0]:0
trace: debug_indent_reset(): snmp_debug.c, 110:
dump_indent: indent reset from 4
trace: _sess_process_packet_parse_pdu(): snmp_api.c, 5595:
sess_process_packet: session 0x801aa1ae0 fd 9 pkt 0x801b34ec0 length 140
trace: snmp_parse_version(): snmp_api.c, 3693:
dumph_recv: SNMP Version
dumpx_recv:  02 01 00 
dumpv_recv:    Integer:    0 (0x00)
trace: _snmp_parse(): snmp_api.c, 4317:
snmp_api: Parsing SNMPv1 message...
trace: _snmp_parse(): snmp_api.c, 4324:
dumph_recv: SNMPv1 message

trace: snmp_comstr_parse(): snmp_auth.c, 127:
dumph_recv:   SNMP version
dumpx_recv:    02 01 00 
dumpv_recv:      Integer:    0 (0x00)
trace: snmp_comstr_parse(): snmp_auth.c, 139:
dumph_recv:   community string
dumpx_recv:    04 08 69 70 73 78 69 74 63 68 
dumpv_recv:      String:    super_secret
trace: _snmp_parse(): snmp_api.c, 4373:
dumph_recv:   PDU
trace: snmp_pdu_parse(): snmp_api.c, 4601:
dumpv_recv:     Command TRAP
dumpx_recv:    06 08 2B 06 01 04 01 81 CB 78 
dumpv_recv:      ObjID: SNMPv2-SMI::enterprises.26104
trace: _sess_process_packet_parse_pdu(): snmp_api.c, 5678:
sess_process_packet: received message id#0 reqid#0 len 140
trace: _sess_process_packet_parse_pdu(): snmp_api.c, 5681:
sess_process_packet: parse fail
trace: _sess_read(): snmp_api.c, 6153:
sess_read: not reading 7 (fdset 0x7fffffffd6d8 set 0)
trace: _sess_read(): snmp_api.c, 6153:
sess_read: not reading 5 (fdset 0x7fffffffd6d8 set 0)

SirDice said:
Maybe fix the cause of the issue? Upgrade their firmware to fix the bug or replace those devices?
Click to expand...
I'd be right happy to, but there's thousands of them in different locations in different cities and the Chinese company that manufactured them no longer exists :)

I'll probably resort to writing some python script with pysnmp library to process traps and trim agent-addr field to 4 bytes.
 
You must log in or register to reply here.
Back
Top