This is a new fact, you did not mention so far: INFORM request is not a NOTIFICATION.
For INFORM, the command responder ( in this case the Java application) is authoritative.
This is correct. On the „out-of-time-window“ report, the command sender should follow the engine time discovery method to actually get the time and engine boots for the authoritative engine ID. The msgFlags field is 0 which indicates a trap (or response) but you wrote above to send an INFORM request. That does not make any sense.
Please be consistent when asking and trying out things, then we might be able to help.
Please note that the message in the image was sent with securityLevel noAuthNoPriv (field msgAuthenticationParameters is empty). In this case it does not make any sense to fill the engineBoots and engineTime fields, as the receiver cannot trust them.
@jkatz /@AGENTPP
sorry for not mentioning about the progress, Yes i started with trap and it works fine with the notification receiver as Java. I have started to validate the inform request and this where i was facing the problem.
So the inform request sender does try to discover the engine id , engine boot and engine time of the commander responder by firing the get request.
The response of the getrequest (Report) should contain the engineid, engineboot and engine time so that the command sender can synchronize it right? but i am seeing that the engineid, engineboot are blank so the subsequent request are sent with the enginetime and engineboot values as “0” and this fails?
As written before, the INFORM sender needs to discover the engine Time with the correct authoritative engine ID.
See RFC 3414 section 3.1 §5:
The securityEngineID is encoded as an OCTET STRING into the
msgAuthoritativeEngineID field of the securityParameters. Note
that an empty (zero length) securityEngineID is OK for a Request
message, because that will cause the remote (authoritative) SNMP
engine to return a Report PDU with the proper securityEngineID
included in the msgAuthoritativeEngineID in the securityParameters
of that returned Report PDU.
You should use/evaluate SNMP4J 3.9.2 if you want to test SNMP4J. Using the very old 2.x branch will not help you.
This report is sent with security level noAuthNoPriv and therefore engineBoots and engineTime are set to zero. But as the engineID is set, the command generator can then send a second request with securityLevel authNoPriv or authPriv (and zero values for engineBoots and engineTime). This request will trigger a notInTimeWindow report (with the same securityLevel as the request) that will have the correct values for engineBoots and engineTime.