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
