1
votes

I have some strage behaviour of SNMP4J which I can't explain. It is likely is due to my misunderstanding of snmp basics.

I deal with server which receives snmp traps. Everything is going on well. Now I need to change traps to inform. The issue is my server is trying to handle received message twice. I occured with duplicating of INFORM message.

Trying to explain... I've enabled logger to DEBUG level. When INFORM is arrived I see in log file two same records from class org.snmp4j.transport.DefaultUdpTransportMapping.ListenThread which has following code in run() method:

if (logger.isDebugEnabled()) {
    logger.debug("Received message from "+packet.getAddress()+"/"+
            packet.getPort()+
            " with length "+packet.getLength()+": "+
            new OctetString(packet.getData(), 0,
            packet.getLength()).toHexString());
}

Also I have class which implements interface org.snmp4j.CommandResponder. His method void processPdu(CommandResponderEvent event) is invoked twice for inform and once for a trap.

@Override
public void processPdu(final CommandResponderEvent evt) {
    final Address address = getAgentAddress(evt);
    final PDU command = evt.getPDU();
    boolean isInform = command.getType() == PDU.INFORM // this is true for both invocations of this method while receiving INFORM
}

Details about versions: snmp v2, snmp4j version 2.3.0

Help me to realize: Does exist some bug here of I should filter second invocation of processPdu method by command.getRequestID(), for example?

1

1 Answers

3
votes

The INFORM must be acknowledged by Receiver.

I believe the problem is that the sender have not received the RESPONSE PDU back for this INFORM REQUEST for some reason. So it sends it once again according to the number of retries. Make sure you send RESPONSE PDU to the sender to confirm that you've received REQUEST PDU (INFORM). The API should do it for you. So make sure you call the default handler.