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

Reply via email to