Re: Cannot receive v2 traps/informs sent via IPv6
Bill Fenner <[email protected]>
| Newsgroups | gmane.network.net-snmp.user |
|---|---|
| Message-ID | <CAF4SogZh3Tx1s4uo-m4CSAeCSv_6+XxyQ94+RLm-JgAJuVqL4g@mail.gmail.com> |
This is pretty interesting:
trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 130:
snmptrapd:auth: Calling VACM for checking phase 0:read
trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
mibII/vacm_vars: vacm_in_view: ver=1, community=trappy
trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1401:
mibII/vacm_vars: vacm_in_view: No security name found
trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 138:
snmptrapd:auth: result: not authorized
Between lines 1300 and 1401, we have:
1332 #ifdef NETSNMP_TRANSPORT_UDPIPV6_DOMAIN
1333 } else if (pdu->tDomain == netsnmp_UDPIPv6Domain
1334 #ifdef NETSNMP_TRANSPORT_TCPIPV6_DOMAIN
1335 || pdu->tDomain == netsnmp_TCPIPv6Domain
1336 #endif
1337 ) {
1338 if (!netsnmp_udp6_getSecName(pdu->transport_data,
1339 pdu->transport_data_length,
1340 pdu_community,
1341 pdu->community_len, &sn,
1342 &contextName)) {
1343 /*
1344 * There are no com2sec entries.
1345 */
1346 sn = NULL;
1347 }
now, there are no code paths through netsnmp_udp6_getSecName() that don't
trace anything, and yet, there is no tracing from it in your log. I can
only draw one of two conclusions:
1. Your snmplib is built without NETSNMP_TRANSPORT_UDPIPV6_DOMAIN
2. Somehow pdu->tDomain != netsnmp_UDPIPv6Domain
I don't quite think #1 could be true, since the udp6: transport works.
This is very strange.
Bill
On Fri, May 9, 2014 at 2:47 PM, christopher.wu <[email protected]>wrote:
> How do I determine if the Windows binary is 32 bit? When I run it with
> "-v" it only shows me the version number.
>
> I thought that these lines were very interesting. It says the version is
> 1, but I passed in 2c to snmptrap when I generated the trap.
>
> mibII/vacm_vars: vacm_in_view: ver=1, community=trappy
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1401:
> mibII/vacm_vars: vacm_in_view: No security name found
>
> Here's the full dump of the messages from -DALL:
>
> trace: netsnmp_ipv6_fmtaddr(): transports/snmpIPv6BaseDomain.c, 97:
> netsnmp_ipv6: fmtaddr: t = (nil), data = 0xa39920, len = 28
> trace: netsnmp_udp6_recv(): transports/snmpUDPIPv6Domain.c, 131:
> netsnmp_udp6: recvfrom fd 8 got 69 bytes (from UDP/IPv6:
> [fd22:2222:2222:3490::1]:40890)
> trace: netsnmp_ipv6_fmtaddr(): transports/snmpIPv6BaseDomain.c, 97:
> netsnmp_ipv6: fmtaddr: t = 0xa3a7a0, data = 0xa39920, len = 28
> transport:recv: 69 bytes from UDP/IPv6: [fd22:2222:2222:3490::1]:40890
> trace: _sess_process_packet(): snmp_api.c, 5171:
> sess_process_packet: session 0xa37ff0 fd 8 pkt 0xa484b0 length 69
> trace: snmp_parse_version(): snmp_api.c, 3489:
> dumph_recv: SNMP Version
> dumpx_recv: 02 01 01
> dumpv_recv: Integer: 1 (0x01)
> trace: _snmp_parse(): snmp_api.c, 4084:
> snmp_api: Parsing SNMPv2 message...
> trace: _snmp_parse(): snmp_api.c, 4094:
> dumph_recv: SNMPv2c message
>
> trace: snmp_comstr_parse(): snmp_auth.c, 130:
> dumph_recv: SNMP version
> dumpx_recv: 02 01 01
> dumpv_recv: Integer: 1 (0x01)
> trace: snmp_comstr_parse(): snmp_auth.c, 142:
> dumph_recv: community string
> dumpx_recv: 04 06 74 72 61 70 70 79
> dumpv_recv: String: trappy
> trace: _snmp_parse(): snmp_api.c, 4140:
> dumph_recv: PDU
> trace: snmp_pdu_parse(): snmp_api.c, 4360:
> dumpv_recv: Command TRAP2
> trace: snmp_pdu_parse(): snmp_api.c, 4445:
> dumph_recv: request_id
> dumpx_recv: 02 04 31 43 6D 8F
> dumpv_recv: Integer: 826502543 (0x31436D8F)
> trace: snmp_pdu_parse(): snmp_api.c, 4456:
> dumph_recv: error status
> dumpx_recv: 02 01 00
> dumpv_recv: Integer: 0 (0x00)
> trace: snmp_pdu_parse(): snmp_api.c, 4467:
> dumph_recv: error index
> dumpx_recv: 02 01 00
> dumpv_recv: Integer: 0 (0x00)
> trace: snmp_pdu_parse(): snmp_api.c, 4485:
> dumph_recv: VarBindList
> trace: snmp_pdu_parse(): snmp_api.c, 4515:
> dumph_recv: VarBind
> trace: snmp_parse_var_op(): snmp.c, 164:
> dumph_recv: Name
> dumpx_recv: 06 08 2B 06 01 02 01 01 03 00
> dumpv_recv: ObjID: DISMAN-EVENT-MIB::sysUpTimeInstance
> trace: snmp_pdu_parse(): snmp_api.c, 4524:
> dumph_recv: Value
> dumpx_recv: 43 01 2A
> dumpv_recv: UInteger: 42 (0x2A)
> trace: snmp_pdu_parse(): snmp_api.c, 4515:
> dumph_recv: VarBind
> trace: snmp_parse_var_op(): snmp.c, 164:
> dumph_recv: Name
> dumpx_recv: 06 0A 2B 06 01 06 03 01 01 04 01 00
> dumpv_recv: ObjID: SNMPv2-MIB::snmpTrapOID.0
> trace: snmp_pdu_parse(): snmp_api.c, 4524:
> dumph_recv: Value
> dumpx_recv: 06 09 2B 06 01 06 03 01 01 05 04
> dumpv_recv: ObjID: IF-MIB::linkUp
> trace: _sess_process_packet(): snmp_api.c, 5218:
> sess_process_packet: received message id#0 reqid#826502543 len 69
> trace: snmp_input(): snmptrapd_handlers.c, 969:
> snmptrapd: input: a7
> trace: snmp_input(): snmptrapd_handlers.c, 1027:
> snmptrapd: Trap OID: IF-MIB::linkUp
> trace: snmp_input(): snmptrapd_handlers.c, 1053:
> snmptrapd: Running auth trap handlers
> trace: netsnmp_trapd_check_auth(): snmptrapd_auth.c, 179:
> snmptrapd:auth: Comparing auth types: result=0, request=0, result=1
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 130:
> snmptrapd:auth: Calling VACM for checking phase 0:read
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
> mibII/vacm_vars: vacm_in_view: ver=1, community=trappy
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1401:
> mibII/vacm_vars: vacm_in_view: No security name found
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 138:
> snmptrapd:auth: result: not authorized
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 130:
> snmptrapd:auth: Calling VACM for checking phase 1:write
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
> mibII/vacm_vars: vacm_in_view: ver=1, community=trappy
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1401:
> mibII/vacm_vars: vacm_in_view: No security name found
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 138:
> snmptrapd:auth: result: not authorized
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 130:
> snmptrapd:auth: Calling VACM for checking phase 2:notify
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
> mibII/vacm_vars: vacm_in_view: ver=1, community=trappy
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1401:
> mibII/vacm_vars: vacm_in_view: No security name found
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 138:
> snmptrapd:auth: result: not authorized
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 130:
> snmptrapd:auth: Calling VACM for checking phase 3:log
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
> mibII/vacm_vars: vacm_in_view: ver=1, community=trappy
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1401:
> mibII/vacm_vars: vacm_in_view: No security name found
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 138:
> snmptrapd:auth: result: not authorized
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 130:
> snmptrapd:auth: Calling VACM for checking phase 4:execute
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
> mibII/vacm_vars: vacm_in_view: ver=1, community=trappy
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1401:
> mibII/vacm_vars: vacm_in_view: No security name found
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 138:
> snmptrapd:auth: result: not authorized
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 130:
> snmptrapd:auth: Calling VACM for checking phase 5:net
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
> mibII/vacm_vars: vacm_in_view: ver=1, community=trappy
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1401:
> mibII/vacm_vars: vacm_in_view: No security name found
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 138:
> snmptrapd:auth: result: not authorized
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 130:
> snmptrapd:auth: Calling VACM for checking phase 6:(null)
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
> mibII/vacm_vars: vacm_in_view: ver=1, community=trappy
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1401:
> mibII/vacm_vars: vacm_in_view: No security name found
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 138:
> snmptrapd:auth: result: not authorized
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 130:
> snmptrapd:auth: Calling VACM for checking phase 7:(null)
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1300:
> mibII/vacm_vars: vacm_in_view: ver=1, community=trappy
> trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1401:
> mibII/vacm_vars: vacm_in_view: No security name found
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 138:
> snmptrapd:auth: result: not authorized
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 141:
> snmptrapd:auth: Final bitmask auth: 0
> trace: netsnmp_trapd_auth(): snmptrapd_auth.c, 155:
> snmptrapd:auth: Dropping unauthorized message
> trace: _sess_read(): snmp_api.c, 5512:
> sess_read: not reading 7 (fdset 0x7ffff9ba6030 set 0)
> trace: _sess_read(): snmp_api.c, 5512:
> sess_read: not reading 5 (fdset 0x7ffff9ba6030 set 0)
> trace: _sess_read(): snmp_api.c, 5512:
> sess_read: not reading 3 (fdset 0x7ffff9ba6030 set 0)
> trace: snmp_sess_select_info2_flags(): snmp_api.c, 6015:
> sess_select: for all sessions: 8 7 5 3
> sess_select: next alarm at 182583.984172 sec
> verbose:sess_select: timer due in 5.869168 sec
> ^C2014-05-09 14:04:42 NET-SNMP version 5.7.2.1 Stopped.
>
> ---- On Fri, 09 May 2014 07:47:02 -0700 Bill Fenner wrote ----
>
> >Let's get to the bottom of this. One notable difference between our
> configurations is that on my example system that worked, I was running a
> 32-bit binary. It's not outside the realm of possibility that there's a
> 64-bit bug here. (Was the Windows binary 32-bit?)
> >
> >Forget about "-d", how about running snmtrapd with -DALL? It will, of
> course, be incredibly verbose, but we should be able to get to the bottom
> of why it's ignoring the trap.
> >
> >
> > Bill
> >
> >
> >
> >
> >
> >On Thu, May 8, 2014 at 6:54 PM, christopher.wu wrote:
> > My configuration and invocation is similar. To simplify things I did
> some testing using your exact examples and found that the same problem
> happened.
> >
> > I sent the trap using your syntax and port:
> >
> > snmptrap -v 2c -c trappy
> "udp6:[fd22:2222:2222:3490:be5f:f4ff:fee1:a1ef]:2000" 42 linkUp;
> >
> > Because of the -d arg passed to snmptrapd I see the packet coming in,
> but it is not accepted.
> >
> > /tmp>sudo snmptrapd -d -Le -f -c ~/snmptrapd.conf udp:2000 udp6:2000
> > NET-SNMP version 5.7.2.1
> >
> > Received 69 byte packet from UDP/IPv6: [fd22:2222:2222:3490::1]:57327
> > 0000: 30 43 02 01 01 04 06 74 72 61 70 70 79 A7 36 02 0C.....trappy.6.
> > 0016: 04 0E 96 8D 3D 02 01 00 02 01 00 30 28 30 0D 06 ....=......0(0..
> > 0032: 08 2B 06 01 02 01 01 03 00 43 01 2A 30 17 06 0A .+.......C.*0...
> > 0048: 2B 06 01 06 03 01 01 04 01 00 06 09 2B 06 01 06 +...........+...
> > 0064: 03 01 01 05 04 .....
> >
> > ^C2014-05-08 16:13:09 NET-SNMP version 5.7.2.1 Stopped.
> > Stopping snmptrapd
> >
> > I used the same conf file as you did:
> >
> > /tmp>cat ~/snmptrapd.conf
> > authCommunity log trappy
> > /tmp>
> >
> > This is on 64 bit Xubuntu. Here's the 'uname -a' output:
> > Linux cwu-dev2 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC
> 2014 x86_64 x86_64 x86_64 GNU/Linux
> >
> > I decided to try sending traps to a completely different PC that I put
> on the same network. I used a PC running the 64 bit version of Windows 7.
> To my surprise it worked. I couldn't test with version 5.7.2.1 because
> Windows binaries for that version aren't available yet.
> >
> > C:ar>snmptrapd -d -Le -f -c snmptrapd.conf udp:2000 udp6:2000
> > NET-SNMP version 5.5
> >
> > Received 69 bytes from UDP/IPv6: [fd22:2222:2222:3490::1]:59337
> > 0000: 30 43 02 01 01 04 06 74 72 61 70 70 79 A7 36 02
> 0C.....trappy§6.
> > 0016: 04 40 E0 C1 B2 02 01 00 02 01 00 30 28 30 0D 06
> .@àA²......0(0..
> > 0032: 08 2B 06 01 02 01 01 03 00 43 01 2A 30 17 06 0A
> .+.......C.*0...
> > 0048: 2B 06 01 06 03 01 01 04 01 00 06 09 2B 06 01 06 +..........
> +...
> > 0064: 03 01 01 05 04 .....
> >
> > 2014-05-08 18:38:14 UDP/IPv6: [fd22:2222:2222:3490::1]:59337 [UDP/IPv6:
> [fd22:2222:2222:3490::1]:59337]:
> > DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (42) 0:00:00.42
> SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkUp
> >
> >^C
> > C:ar>
> >
> > ---- On Thu, 08 May 2014 07:37:35 -0700 Bill Fenner wrote ----
> >
> > >Can you say more about your configuration and invocation?
> > >
> > >Using net-snmp 5.7.2, I ran:
> > >
> > >
> > >snmptrapd -Le -f -c ~/snmptrapd.conf udp:2000 udp6:2000
> > >
> > >
> > >
> > >with just this line in ~/snmptrapd.conf
> > >
> > >
> > >authCommunity log trappy
> > >
> > >
> > >
> > >and then sent a trap with:
> > >
> > >
> > >snmptrap -v 2c -c trappy
> "udp6:[fd7a:629f:52a4:2010:225:90ff:fea8:86a2]:2000" 42 linkUp
> > >
> > >
> > >
> > >and got:
> > >
> > >
> > > 2014-05-08 07:34:17 UDP/IPv6:
> [fd7a:629f:52a4:2010:225:90ff:fea8:86a2]:50583 [UDP/IPv6:
> [fd7a:629f:52a4:2010:225:90ff:fea8:86a2]:50583]:
> > >DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (42) 0:00:00.42
> SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkUp
> > >
> > >
> > >
> > > Bill
> > >
> > >
> > >
> >
> >>On Thu, May 1, 2014 at 2:00 PM, christopher.wu wrote:
> > > I'm having a strange problem where my snmptrapd server will not accept
> v2 traps/informs if they are sent via ipv6. My snmptrapd server is version
> 5.7.2.1 running on Linux. The traps/informs are being sent by version
> 5.5.1 of snmptrap, also on Linux. I tried version 5.7.2.1 of snmptrap but
> that did not work either.
> > >
> > > Here are the scenarios:
> > >
> > > 1) v3 inform sent via ipv4 - works
> > > 1) v3 inform sent via ipv6 - works
> > > 2) change to v2 and send to same ipv6 address - fails. Because I'm
> running snmptrapd with the '-d' arg I do see the packet come in, but it is
> not accepted. In the packet dump I can see the correct v2 community name
> is being used. Of course I switched to a different, appropriate v2 config
> file for snmptrapd when I switched from sending v3 to v2 traps.
> > > 3) keep the same v2 credentials and send via ipv4 - works
> > >
> > > I couldn't find anything in the bug database that mentions this. Are
> there any debugging steps that I can do to help figure out what is
> happening?
> > >
> > > Here's an example of ipv4 working but ipv6 not when v2 is used.
> > >
> > >
> > > Received 75 byte packet from UDP:
> [192.168.108.1]:55953->[192.168.108.2]:162
> > > 0000: 30 49 02 01 01 04 0A 4E 4F 54 57 4F 52 4B 49 4E
> 0I.....NOTWORKIN
> > > 0016: 47 A6 38 02 04 1E 48 83 BD 02 01 00 02 01 00 30
> G.8...H........0
> > > 0032: 2A 30 0F 06 08 2B 06 01 02 01 01 03 00 43 03 67
> *0...+.......C.g
> > > 0048: 66 B4 30 17 06 0A 2B 06 01 06 03 01 01 04 01 00
> f.0...+.........
> > > 0064: 06 09 2B 06 01 06 03 01 01 05 01 ..+........
> > >
> > > 2014-05-01 13:47:02 UDP: [192.168.108.1]:55953->[192.168.108.2]:162
> [UDP: [192.168.108.1]:55953->[192.168.108.2]:162]:
> > > DISMAN-EXPRESSION-MIB::sysUpTimeInstance = Timeticks: (6776500)
> 18:49:25.00 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-MIB::coldStart
> > >
> > > Sending 75 bytes to UDP: [192.168.108.1]:55953->[192.168.108.2]:162
> > > 0000: 30 49 02 01 01 04 0A 4E 4F 54 57 4F 52 4B 49 4E
> 0I.....NOTWORKIN
> > > 0016: 47 A2 38 02 04 1E 48 83 BD 02 01 00 02 01 00 30
> G.8...H........0
> > > 0032: 2A 30 0F 06 08 2B 06 01 02 01 01 03 00 43 03 67
> *0...+.......C.g
> > > 0048: 66 B4 30 17 06 0A 2B 06 01 06 03 01 01 04 01 00
> f.0...+.........
> > > 0064: 06 09 2B 06 01 06 03 01 01 05 01 ..+........
> > >
> > >
> > > Received 74 byte packet from UDP/IPv6: [fd22:2222:2222:3490::1]:33344
> > > 0000: 30 48 02 01 01 04 0A 4E 4F 54 57 4F 52 4B 49 4E
> 0H.....NOTWORKIN
> > > 0016: 47 A6 37 02 03 68 5B 7F 02 01 00 02 01 00 30 2A
> G.7..h[.......0*
> > > 0032: 30 0F 06 08 2B 06 01 02 01 01 03 00 43 03 67 66
> 0...+.......C.gf
> > > 0048: B4 30 17 06 0A 2B 06 01 06 03 01 01 04 01 00 06
> .0...+..........
> > > 0064: 09 2B 06 01 06 03 01 01 05 01 .+........
> > >
> > >
> > > Received 74 byte packet from UDP/IPv6: [fd22:2222:2222:3490::1]:33344
> > > 0000: 30 48 02 01 01 04 0A 4E 4F 54 57 4F 52 4B 49 4E
> 0H.....NOTWORKIN
> > > 0016: 47 A6 37 02 03 68 5B 7F 02 01 00 02 01 00 30 2A
> G.7..h[.......0*
> > > 0032: 30 0F 06 08 2B 06 01 02 01 01 03 00 43 03 67 66
> 0...+.......C.gf
> > > 0048: B4 30 17 06 0A 2B 06 01 06 03 01 01 04 01 00 06
> .0...+..........
> > > 0064: 09 2B 06 01 06 03 01 01 05 01 .+........
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > > Instantly run your Selenium tests across 300+ browser/OS combos. Get
> > > unparalleled scalability from the best Selenium testing platform
> available.
> > > Simple to use. Nothing to install. Get started now for free."
> > > http://p.sf.net/sfu/SauceLabs
> > > _______________________________________________
> > > 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
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
>
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
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