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 <christopher...@zoho.com>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
