Yes, the UsmTimeTable
is a private member in USM
and therefore cannot be easily changed. The intention for this was indeed trying to increase security, but of course modifying the source code of USM
would be an option too.
Hello,
I decided to return to this post, because currently the trap transmitter, from which I receive traps, works in accordance with the SNMPv3 standard and after each reload it correctly increments engineBoot
and engineTime
.
For creating the USM I use the command:
usm = new USM(SecurityProtocols.getInstance(), getEngineId(), 0)
The listening dispatcher is defined as follows:
dispatcher.addMessageProcessingModel(new MPv3(usm))
In addition, I no longer set engineBoot
or engineTime
in the receiver, and the engineID
should match, although I no longer use the setLocalEngine
command when initializing the listener.
The receiver defined in this way does not receive traps correctly, probably due to different engineBoot
and engineTime
parameters.
I would like to ask if the engineBoot
and engineTime
parameters should be automatically synchronized via the SNMP protocol, or should something be manually set in the code? Maybe EngineBootsProvider
is necessary?
Best regards,
Michael
Hi,
if you always create the USM with engineBoot
value 0
, your application can only be the non authoritative engine in a communication. So it can only send out get/getnext/set/inform,ā¦ requests and receive traps. It cannot receive an inform request. Sending out traps will not work.
If any engine just increases the engineBoot
value at each startup, everything will work. The non authoritative receiver can then synchronize to the engineBoot
and engineTime
value of the authoritative engine through the normal message exchange (this is part of the SNMP RFC). There is no need to set the engineTime
manually.
Kind regards,
Jochen
Hello,
Ok, because I thought that remembering and synchronizing engineBoot
might have to be done manually.
But what if there is a restart of the transmitter and increasing engineBoot
, and the receiver is still running? Do I also need to restart the receiver then to synchronize?
And another question, how to initialize the USM without engineBoot
which is equal to zero? What value should I set in the constructor?
Best regards,
Michael
Hi Michael,
I think there is still a misunderstanding: every SNMP entity has engineTime
and engineBoots
.
Thus, the constructor above defines the local notions of both values - not any remote values. And these values are not synchronized with the values local to any remote instance. The synchronization is done in a separate engine times table.
As consequence from the above, you always have to increase the engineBoots
value on each restart. Otherwise, communication will need a manual reset of the engine time table entry on all remote peers for this target.
Hope this helps.
Frank
Hello,
The above answer explained me the concept of working SNMP.
In my case, the devices from which I received traps can be independently rebooted many times and after a few reboots my trap receiver starts listening for traps from these devices. My receiver is also restarted any number of times in the meantime, so I canāt manually keep the engineBoot
parameter matched. Isnāt this engineBoot
synchronization automatically done when the protocol detects an engineBoot
value mismatch? How to implement this in my case?
Best regards
Michael
Hi,
as long as each involved engine (trap sender, trap receiver, agent, manager,ā¦) increases its own engineBoots
value with each restart, everything will work. There is no need that all engines have the same engineBoots
value.
Kind regards,
Jochen
I am trying to implement this mechanism, but logs from LogFactory
when receiving traps show me error 1411 (SNMPv3_USM_NOT_IN_TIME_WINDOW). The trap transmitter correctly increments engineBoot
and engineTime
. When I start my trap receiver, the received traps have an initial engineBoot
value of eg 20 and incremented engineTime
, and my receiver on startup starts with engineBoot
and engineTime
= 0.
When initializing the receiver, I use the following commands with engineBoot
and engineTime
parameters:
usm = new USM(SecurityProtocols.getInstance(), localEngineID, 0);
usm.addUser(user, localEngineID, createUsmUser());
usm.setEngineDiscoveryEnabled(true);
dispatcher.addMessageProcessingModel(new MPv3(usm));
snmp=new Snmp(dispatcher, transport);
snmp.setLocalEngine(localEngineID, 0 ,0);
snmp.listen();
Could you please give me a hint where the problem lies?
Best regards,
Michael
The problem ist the hard coded 0 for the engineBoots
. Whenever you restart your receiver, the sender will have a different engineBoots
value remembered for your receiver from the last run with the same local engine ID.If the boots of the sender is greater than the one of the receiver, then a usmNotInTimeWindow
error is reported.
Currently traps received from the transmitter have engineBoot=40
and engineTime
e.g. 200.
In the receiver, I made several attempts with engineBoot
, setting:
usm = new USM(SecurityProtocols.getInstance(), localEngineID, 40);
snmp.setLocalEngine(localEngineID, 40, 0);
or
usm = new USM(SecurityProtocols.getInstance(), localEngineID, 41);
snmp.setLocalEngine(localEngineID, 41, 0);
However, I had error 1411 each time.
Please consult the SNMPv3 USM RFC 3414 about the engine time synchronisation. I do not think that we can solve it here anymore.
As explained before, trying to use the same value for the local engineBoots as the sender uses for its engine has no use and is the wrong approach.
I seem to have solved the engineBoot
issue.
Traps are correctly received only when the receiver has a different engineId
than the transmitter, and in the receiver I set e.g.
snmp.setLocalEngine(receiverEngineID, 0, 0);
So I suppose that I must have two engineId
values defined, and if I want to send traps, I will include the receiverās local engineId
in the sent trap, and engineBoot
incremented after each receiver restart for a given fixed receiver engineId
.
Yes, the following sentence should be part of every SNMPv3 FAQ:
The first sentence of the following quote is not correct, because the trap sender is authoritative. Thus, the engineID relevant for the authenticity is the engine ID of the sender (= authoritativeEngineID
in UsmParameters
of the SNMPv3 ScopedPDU). The second part about the need of incrementing the engineBoots counter on each restart (=reset of the egineTime) is true:
Yes, thatās what I thought, only I worded it wrong above, because I was thinking about my receiver becoming a transmitter .
Thanks all for help in solving the problem.