Reusing the Snmp object

I want to create the Snmp object only once and then reuse it. When the first GET request is sent, the engineID, the number of boots, and time are discovered. I don’t want to rediscover them again and again with each new request. This happens if a new Snmp object is created for each request.
Reusing the Snmp object works - WireShark confirms that the report containing engineID, number of boots, time is sent by the device only once and then reused successfuly.
The problem is when the device is restarted. Then the Snmp object carries the old data which needs to be rediscovered and updated. What would be the easiest way to do it? Detect for a timeout and create a new object? Thanks you!

The easiest and best way would be to fix the device. When the device reboots, it has to increase its engineBoots counter and the time synchronisation would work automatically. That is a SNMPv3 standard requirement and a device that does not increase the boots counter violates the standard and is not interoperable with standard conforming/secure SNMPv3 tools.

1 Like

The device does increase the number of boots with each restart. I see it in WireShark, but the Snmp object that I am caching can no longer be used for this device.

Then the device is not sending back the right REPORT PDU when it detects the “engine time not in time window”. Otherwise (because you wrote that engine ID discovery is activated in your Snmp instance), the communication would still work.

With the DEBUG log of the command sender, it would be easier to name to concrete issue.

1 Like

I don’t see the device sends any REPORT PDU after it is restarted. I see only my GET requests in WireShark, but no response. I see the REPORT PDU only after sending the very first request.

OK, then this is the bug in the device. The device should send a REPORT PDU with its new engine boots counter and engine time. Without that the sender cannot send a valid request. See the USM RFC 3414 for details.

1 Like

I suspect that even if it is a bug in the device, the manager developers will get asked to “fix” it anyway. The way I did it in the past when I had misbehaving V3 agents was that if I got a complete timeout for a V3 device (in similar conditions to the OP) I used a small hash keyed on agent IP addresses with the value of the agent’s engineID to delete the USM record for that engineID/user tuple. NOTE: I was able to corroborate that only SNMP to the agent was failing, but that isn’t expressly required.

Assuming your process to build the target will re-populate the V3 credential sets into USM, this should establish the communication as if the agent was brand new.

I am sure that people are going to tell me that is unsafe security practices because changing the agent properties dynamically could be opening up an attack vector, but sometimes you can’t wait years for the vendor to abide the standards.

2 Likes