The problem exists for the 5.3.1 as well. Basically, if you want to receive v3 trap at default port 162 at the recipient, you have to specify the port in the 'trapsess' like the following:
trapsess [v1/v2/v3 options] ipaddr:162 Otherwise, the traps are sent to udp port 161 of the recipient (use ethereal to observe). Stephen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Yu Sent: Monday, November 20, 2006 3:02 PM To: Dave Shield Cc: net-snmp-users@lists.sourceforge.net Subject: RE: Configure trap port Hi Dave, Thank you very much for your reply. The version we use is from our embedded Linux vendor MontaVista Software. So we are kind of stuck with them. Knowing this is a bug, I don't have to mess with the snmpd.conf. I can simply patch the code myself for the moment and wait for MontaVista Software giving us a newer version that have the problem fixed. Again, thank you for your quick reply. Stephen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Shield Sent: Monday, November 20, 2006 2:38 PM To: Stephen Yu Cc: net-snmp-users@lists.sourceforge.net Subject: Re: Configure trap port On 20/11/06, Stephen Yu <[EMAIL PROTECTED]> wrote: > I just want to confirm the correct way to specify the trap port in > snmpd.conf in net-snmp 5.1.1 and above. Is there any particular reason you are working with that version? It's *extremely* old now (having been released over 2 1/2 years ago), and the 5.1.x line has now been mothballed. It's not even the most recent version on that line, since 5.1.4 was released back in March this year. We would *strongly* encourage you to use 5.1.4 (at the very least). And preferably one of the more recent releases, on a line that is still being maintained. The latest release is currently 5.3.1, with 5.4 due imminently. > We were using ucd-snmp 4.2.6.... [with] trapsess [v1, v2c or v3 > options] ip-addr > > Now, we move to net-snmp 5.1.1, the above 'trapsess' line causes the > traps to be sent to port 161 of the destination This is a bug, that I'm pretty sure was fixed some time ago. The current code certainly handles this properly (though it appears v5.1.4 still suffers from the same problem). Note that the handling of transport addresses changed significantly with the v5 code, and use of the 'remote_port' field is no longer recommended. Ideally, we would have removed this field altogether, but that would obviously have broken any existing software that relied on it. Try upgrading to a newer version (e.g. 5.3.1 or the upcoming 5.4). Dave ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V _______________________________________________ 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ 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
