Packets suddenly use Incorrect msgAuthoritativeEngineTime

SNMP4J
1

Hi all,

I’m encountering an issue using SNMP4J (version 2.8.7) with SNMPv3 when polling a network device.

Problem Summary

After the engine ID is discovered and polling begins successfully, SNMP4J suddenly sends a get-next-request with an incorrect and much higher msgAuthoritativeEngineTime. This causes the remote device to drop the packet.

Observed Behavior (from Wireshark)

  1. Initial discovery works:

    • Sent “empty” SNMPv3 request → received usmStatsUnknownEngineIDs (1.3.6.1.6.3.15.1.1.4.0) with engineID, boots, and time. Engine time is 422,336 (seconds)

  2. Sent again with contextName → got the same unknownEngineIDs response.

  3. Sent proper get-next-request for OID 1.3.6.1.2.1.1.2 → received correct response (1.3.6.1.2.1.1.2.0 with a value)

  4. Next get-next-request (1.3.6.1.2.1.1.2.0) → received 1.3.6.1.2.1.1.3.0 which is sysUpTimeInstance with value of 1.3.6.1.2.1.1.3.0: 44758458 (in hundredths of a second) → 447,584.58 seconds

  5. Suddenly, next request is sent with a large msgAuthoritativeEngineTime (27,222,514), which the agent rejects.

Questions

  • What could cause SNMP4J to reset or recompute msgAuthoritativeEngineTime incorrectly after previous success?
  • Is it possible that internal USM cache is cleared or reset unexpectedly?
  • How can I ensure that engine time tracking persists reliably between requests?

Any insights would be greatly appreciated.
If more info is needed, let me know. I will try my best to provide it. I can’t share IPs and other

Thanks

2
  1. SNMP4J does not “recompute” the engineTime of a remote engine.
  2. No.
  3. Make sure engine IDs are unique in your network. Use SNMP4J 3.9.x or later and use the LocalizationGrant.outgoing attribute of the UsmUser to selectively allow engine ID discovery. This can avoid pollution of the UsmTimeTable with engineTimes of trap senders.

You should check with Wireshark if there are packets with the wrong engineTime send on behalf of the agent’s engineID in your network. If command sender (SNMP4J) and receiver (“the agent”) have the same engine ID or if the agent is not properly increasing engineBootsCounter, then this can cause what you observed.

3

Thanks for the response!
So the flow I described is from a Wireshark recording. It only had a single SNMP communication with a single device. Nothing else seem to be running
engineTime from the agent seem to be fine. It all breaks right after we grab the system object ID and get a “bad” response for 1.3.6.1.2.1.1.2.0.
Saying “bad” cause it just means this is the next OID in the tree, but I assume the system should treat this as the end of the tree branch. I just wondered if this could break this somehow

I will check potential duplicate engine IDs