TRAP and WALK from same IP Address

Hi Frank,

My agent is sending trap to : udp:<my_ip>:162
My agent is sending trap to : udp:<my_ip>:161

When I configure transport mappings with these and start my agent it contonuously send and receives message from port 161 and 162.

I found the follwing log continuously being printed:

Looking up coexistence info for 'public'
Found coexistence info for 'public'=CoexistenceInfo[securityName=public,contextEngineID=,contextName=,transportTag=]
Found coexistence info for 'public'=CoexistenceInfo[securityName=public,contextEngineID=,contextName=,transportTag=]
Address passes filter, because source address filtering is disabled
Sending message to with length 70: ...... 

Address passes filter, because source address filtering is disabled
No PDU handler found for request CommandResponderEvent[securityModel=2, securityLevel=1, maxSizeResponsePDU=2147483647, pduHandle=PduHandle[590255578], stateReference=StateReference[msgID=0,pduHandle=PduHandle[590255578],securityEngineID=null,securityModel=null,securityName=public,securityLevel=1,contextEngineID=null,contextName=null,retryMsgIDs=null], pdu=INFORM[requestID=590255578, errorStatus=General variable binding error(5), errorIndex=0, VBS[ = 0:00:14.31; =]], messageProcessingModel=1, securityName=public, processed=true, peerAddress=, transportMapping=org.snmp4j.transport.DefaultUdpTransportMapping@dc843e, tmStateReference=null]

Can you please advice on, what is co-existence?

P.S: When Only one of these addresses are configured, it works file.


Coexistence means: “coexistence between the various SNMP versions and message processing models”. See RFC 3584.

If there is no PDU handler is defined for PDU type in the CommandProcessor associated with a context engine ID.

Hi Frank,

Another question popped up. Is there any listener or a method hook exposed which is called to signal that the execution of current activity is complete?

For example, my agent is receiving GET /WALK command. A listener can be registered whose methods would be called after the GET/GETNEXT response is sent back.

Is there anything like this?

Hi Frank,

Thanks for your reply really appreciate. I shouldn’t have asked a question which is a part of my analysis. But any ways I have already figured it out and fixed it.

The bottom line is, “You cannot listen to 162 port in an agent” using TransportMapping.

This statement alone is not true. There must be something else that prevented that use case to match your expectations.

I listened to port:161 and 162 both. The agent was infinitely sending and receiving messages (V1 Cold Start Traps) between those ports.