Please ignore what I pointed out in the last message about the version being 1. I see in Wireshark that a version of hex 01 in the packet is what is used for v2c.
I looked more closely at the trace messages. In the "phase 0", "phase 1", etc sections the Windows version (which is working) is able to "resolve" and "compare" the community names. The Linux version just says "No security name found". Note: for these examples I switched to TRAPPY instead of trappy for the community name. running on 64 bit Linux OS: 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: running on 64 bit windows 7: snmptrapd:auth: Comparing auth types: result=0, request=0, result=1 trace: ..\..\apps\snmptrapd_auth.c, 118: snmptrapd:auth: Calling VACM for checking phase 0:read trace: ..\..\agent\mibgroup\mibII\vacm_conf.c, 1290: mibII/vacm_vars: vacm_in_view: ver=1, community=TRAPPY trace: ..\..\snmplib\snmpUDPDomain.c, 1182: netsnmp_udp_getSecName: opaque = 0000000001F1A510 (len = 20), sizeof = 20, family = 2 (2) trace: ..\..\snmplib\snmpUDPDomain.c, 1199: netsnmp_udp_getSecName: resolve <"TRAPPY", 0x9a473687> trace: ..\..\snmplib\snmpUDPDomain.c, 1204: netsnmp_udp_getSecName: compare <"TRAPPY", 0x00000000/0x00000000>... SUCCESS trace: ..\..\agent\mibgroup\mibII\vacm_conf.c, 1418: mibII/vacm_vars: vacm_in_view: sn=comm1, gn=grpcomm1, vn=trace: ..\..\snmplib\vacm.c, 493: vacm:getView: , none trace: ..\..\apps\snmptrapd_auth.c, 126: snmptrapd:auth: result: not authorized trace: ..\..\apps\snmptrapd_auth.c, 118: ---- On Fri, 09 May 2014 11:47:35 -0700 <christopher...@zoho.com> 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 > > > Net-snmp-users@lists.sourceforge.net > > > Please see the following page to unsubscribe or change other options: > > > https://lists.sourceforge.net/lists/listinfo/net-snmp-users > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
