[ net-snmp-Bugs-757137 ] Traps not recoieved on local port in Net-SNMP5.0.8

[SourceForge.net <no...@so...>]

Bugs item #757137, was opened at 2003-06-19 06:41
Message generated for change (Comment added) made by slif
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=757137&group_id=12694

>Category: apps
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Jyoti Yaduwanshi (jyotiy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Traps not recoieved on local port in Net-SNMP5.0.8

Initial Comment:
In files snmpUDPDomain.c as well as 
snmpUDPIPv6Domain.c I have found that when we open 
the session for reciving traps i.e. when our application 
runs as server, then while binding to the local port the 
local port supplied by my application is not put in 
the "address" supplied as argument to the method
netsnmp_udp_transport() in snmpUDPDomain.c and in 
method netsnmp_udp6_transport() in 
snmpUDPIPv6Domain.c . So the traps are not received 
at the local port supplied by the application rather it 
binds to the standard port "161" for recieving traps.

----------------------------------------------------------------------

>Comment By: Michael J. Slifcak (slif)
Date: 2004-04-20 19:10

Message:
Logged In: YES 
user_id=88697

Thanks for the bug report!  We've fixed the problem in the
5.1.x code branch and the main development tree,
so it should be fixed in future releases of the net-snmp package.

----------------------------------------------------------------------

Comment By: Michael J. Slifcak (slif)
Date: 2004-04-20 19:10

Message:
Logged In: YES 
user_id=88697

There was a problem with trap receiver not listening
by default to port 162, which is the commonly used
trap receiving port (161 is commonly used by the agent).

Without specifying a port, the default listening port
for snmptrapd is now 162, as it should be.

Verified fixed at net-snmp 5.1.1.




----------------------------------------------------------------------

Comment By: David Beattie (dbeattie)
Date: 2003-06-19 14:28

Message:
Logged In: YES 
user_id=804938

Couldn't tell you if this is a "fix" or not, but, it's certainly a 
work-around.  It could be considered a fix if the internal 
documentation in the source code were modified to make it 
clear, and ideally user documentation created to tell us how 
this is supposed to work.

I ran into the same problem this week (listening on port 161) 
when trying to use the perl module.  The code in trap-
example.pl, for example, showed the "local" field set to the 
port number (162), and the "peer" field set to 0.0.0.0.  
****This doesn't work****.  After extensive debugging, and 
comparing with the source code for snmptrapd, I discovered 
that the "local" flag, while it seems thought to contain a port 
number, in reality does not (in the current implementation) 
contain anything more than a boolean flag telling the library 
whether to listen (as a server) or not.  To be successful at 
listening on a different port than the default (161) one can 
encode the port number in the "peer" field, after a colon, and 
in addition, set "local" to 1, or, anything non-zero.  All of the 
following seem to work "0.0.0.0:162", "192.168.1.75:162", 
and "udp:162"  (the first and last listen on all interfaces, the 
middle listens on the interface with that IP address).  I plan 
to post this information to coders as well unless somebody 
tells me it's not necessary.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=757137&group_id=12694