Snmp4j-agent 3.7.0 issues

Hi!

We’re seeing an issue with the new snmp4j-agent 3.7.0 release whenever a client issues a request for an OID that is not present.

For example, if a client issues a GET request for three OIDs, the third of which is not present, the new 3.7.0 snmp-agent release generates a response PDU with an error-status of “genErr(5)”, with variable-bindings containing values of the two present OIDs and the third OID with “noSuchObject”.

Prior snmp-agent releases generated an identical response PDU (same variable-bindings containing values of the two present OIDs and the third OID with “noSuchObject”), except with an error-status of “noError(0)”.

Logging messages from 3.7.0 show a NullPointerException being generated with the CommandProcessor class, which is triggering the response PDU to have it’s error-status set to “genErr(5)” when the NullPointerException caught and handled:

java.lang.NullPointerException: Cannot invoke "org.snmp4j.agent.ManagedObject.get(org.snmp4j.agent.request.SubRequest)" because "mo" is null
at org.snmp4j.agent.CommandProcessor$GetHandler.processPdu(CommandProcessor.java:1220)
at org.snmp4j.agent.CommandProcessor$GetHandler.processPdu(CommandProcessor.java:1173)
at org.snmp4j.agent.CommandProcessor.processRequest(CommandProcessor.java:425)
at org.snmp4j.agent.CommandProcessor.processRequest(CommandProcessor.java:381)
at org.snmp4j.agent.CommandProcessor.dispatchCommand(CommandProcessor.java:335)
at org.snmp4j.agent.CommandProcessor$Command.run(CommandProcessor.java:613)
at org.snmp4j.agent.CommandProcessor.processPdu(CommandProcessor.java:162)
at org.snmp4j.MessageDispatcherImpl.fireProcessPdu(MessageDispatcherImpl.java:791)
at org.snmp4j.MessageDispatcherImpl.dispatchMessage(MessageDispatcherImpl.java:439)
at org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:513)
at org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:477)
at org.snmp4j.transport.AbstractTransportMapping.fireProcessMessage(AbstractTransportMapping.java:121)
at org.snmp4j.transport.DefaultUdpTransportMapping.fireProcessMessage(DefaultUdpTransportMapping.java:497)
at org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:409)
at java.base/java.lang.Thread.run(Thread.java:840)

java.lang.Exception: Error 'General variable binding error' generated at: 1.3.6.1.2.1.2.2.1.20.3 = noSuchObject
at org.snmp4j.agent.request.SnmpRequest$SnmpSubRequest.requestStatusChanged(SnmpRequest.java:684)
at org.snmp4j.agent.request.RequestStatus.fireRequestStatusChanged(RequestStatus.java:89)
at org.snmp4j.agent.request.RequestStatus.setErrorStatus(RequestStatus.java:52)
at org.snmp4j.agent.CommandProcessor$GetHandler.processPdu(CommandProcessor.java:1232)
at org.snmp4j.agent.CommandProcessor$GetHandler.processPdu(CommandProcessor.java:1173)
at org.snmp4j.agent.CommandProcessor.processRequest(CommandProcessor.java:425)
at org.snmp4j.agent.CommandProcessor.processRequest(CommandProcessor.java:381)
at org.snmp4j.agent.CommandProcessor.dispatchCommand(CommandProcessor.java:335)
at org.snmp4j.agent.CommandProcessor$Command.run(CommandProcessor.java:613)
at org.snmp4j.agent.CommandProcessor.processPdu(CommandProcessor.java:162)
at org.snmp4j.MessageDispatcherImpl.fireProcessPdu(MessageDispatcherImpl.java:791)
at org.snmp4j.MessageDispatcherImpl.dispatchMessage(MessageDispatcherImpl.java:439)
at org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:513)
at org.snmp4j.MessageDispatcherImpl.processMessage(MessageDispatcherImpl.java:477)
at org.snmp4j.transport.AbstractTransportMapping.fireProcessMessage(AbstractTransportMapping.java:121)
at org.snmp4j.transport.DefaultUdpTransportMapping.fireProcessMessage(DefaultUdpTransportMapping.java:497)
at org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:409)
at java.base/java.lang.Thread.run(Thread.java:840)

It seems unlikely to us that internally generating a NullPointerException was intended, so we think this maybe a fault in some of the changes in 3.7.0?

Thanks!
Jeremy

To help better illustrate the difference between response PDU being generated:

3.6.8:

DefaultUDPTransportMapping_0:0:0:0:0:0:0:0/52553 DEBUG Request done in 48.985125 ms: GET[requestID=24888780, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.2.2.1.1.3 = Null; 1.3.6.1.2.1.2.2.1.2.3 = Null; 1.3.6.1.2.1.2.2.1.20.3 = Null]]->RESPONSE[requestID=24888780, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.2.2.1.1.3 = 3; 1.3.6.1.2.1.2.2.1.2.3 = ETHERNET ACCESS PORT; 1.3.6.1.2.1.2.2.1.20.3 = noSuchObject]]

3.7.0:

DefaultUDPTransportMapping_0:0:0:0:0:0:0:0/62981 DEBUG Request done in 50.268166 ms: GET[requestID=1224639452, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.2.2.1.1.3 = Null; 1.3.6.1.2.1.2.2.1.2.3 = Null; 1.3.6.1.2.1.2.2.1.20.3 = Null]]->RESPONSE[requestID=1224639452, errorStatus=General variable binding error(5), errorIndex=3, VBS[1.3.6.1.2.1.2.2.1.1.3 = 3; 1.3.6.1.2.1.2.2.1.2.3 = ETHERNET ACCESS PORT; 1.3.6.1.2.1.2.2.1.20.3 = noSuchObject]]

Thank you for reporting this issue. It has been fixed with the latest 3.7.1 snapshot at:
https://snmp.app/dist/snapshot/org/snmp4j/snmp4j-agent/3.7.1-SNAPSHOT/snmp4j-agent-3.7.1-20240405.200022-2-distribution.tar.gz

I will add the missing unit test to cover this cases and then I am going to release 3.7.1. Is the snapshot working for you?

I’ve confirmed the 3.7.1 snapshot works, thanks!

3.7.1-snapshot

DefaultUDPTransportMapping_0:0:0:0:0:0:0:0/57774 DEBUG Request done in 51.559916 ms: GET[requestID=1692169043, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.2.2.1.1.3 = Null; 1.3.6.1.2.1.2.2.1.2.3 = Null; 1.3.6.1.2.1.2.2.1.20.3 = Null]]->RESPONSE[requestID=1692169043, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.2.1.2.2.1.1.3 = 3; 1.3.6.1.2.1.2.2.1.2.3 = ETHERNET ACCESS PORT; 1.3.6.1.2.1.2.2.1.20.3 = noSuchObject]]

3.7.1 has been released which includes another fix too fixing the OID returned for MOScalar objects for some noSuchInstance and noSuchObject exception condition.

Great, thank you for the quick turnaround on a fix!