[SNMP4J] V3 Not In Time Window and Client Clock Drift
Elise Atkins
eatkins at tavve.com
Tue Jun 11 17:03:55 CEST 2013
Frank,
We have some test tools for generating SNMP requests and traps that use
the SNMP4J library. I dropped in the new jar and sometimes I get the
following stack trace:
Exception in thread "AWT-EventQueue-0"
java.lang.IllegalArgumentException: Pool size must be >= 1
at org.snmp4j.security.CipherPool.<init>(CipherPool.java:59)
at org.snmp4j.security.CipherPool.<init>(CipherPool.java:48)
at org.snmp4j.security.PrivDES.<init>(PrivDES.java:58)
at
org.snmp4j.security.SecurityProtocols.addDefaultProtocols(SecurityProtocols.java:151)
It is caused by: SecurityProtocols.getInstance().addDefaultProtocols();
It there an API change I need to be aware of?
Elise
Elise Atkins wrote:
> Hi Frank,
>
> The fix seems to work great.
>
> Thanks,
> Elise
>
> Frank Fock wrote:
>> Hi Elise,
>>
>> The latest snapshot release contains the fix. Please try it. You can
>> find
>> it at:
>>
>> https://oosnmp.net/dist/snapshot/org/snmp4j/snmp4j/2.2.2-SNAPSHOT/snmp4j-2.2.2-20130604.002021-21.jar
>>
>>
>> Best regards,
>> Frank
>>
>>
>> Am 03.06.2013 21:43, schrieb Elise Atkins:
>>> Thank you. Look forward to the new release.
>>> Elise
>>>
>>> Frank Fock wrote:
>>>> Elise,
>>>>
>>>> OK, I am convinced. I reservley checked the implementation with
>>>> RFC3414 and
>>>> overseen your initial point about the order of checks.
>>>>
>>>> I will provide a fix for it (ticket ID is SFJ-75).
>>>>
>>>> The SNMP4J 2.2.2 release (with that fix) is then planned for next
>>>> week.
>>>>
>>>> Best regards,
>>>> Frank
>>>>
>>>>
>>>> Am 03.06.2013 17:52, schrieb Elise Atkins:
>>>>> Frank,
>>>>>
>>>>> After looking at RFC 3414, I have a different interpretation. In
>>>>> the case 1) the RFC states that the local notion of the value of
>>>>> the snmpEngineTime is to be updated to the
>>>>> msgAuthoritativeEngineTime. This should mean that the response is
>>>>> in time regardless of how slow or fast the authoritative engine's
>>>>> time is running as long as it moves in the forward direction when
>>>>> the time check is done in 2).
>>>>>
>>>>> b) If the extracted value of msgAuthoritativeEngineID is not
>>>>> the
>>>>> same as the value snmpEngineID of the processing SNMP engine
>>>>> (meaning this is not the authoritative SNMP engine), then:
>>>>>
>>>>> 1) if at least one of the following conditions is true:
>>>>>
>>>>> - the extracted value of the msgAuthoritativeEngineBoots
>>>>> field is greater than the local notion of the value of
>>>>> snmpEngineBoots; or,
>>>>>
>>>>> - the extracted value of the msgAuthoritativeEngineBoots
>>>>> field is equal to the local notion of the value of
>>>>> snmpEngineBoots, and the extracted value of
>>>>> msgAuthoritativeEngineTime field is greater than the
>>>>> value of latestReceivedEngineTime,
>>>>>
>>>>> then the LCD entry corresponding to the extracted
>>>>> value of
>>>>> the msgAuthoritativeEngineID field is updated, by
>>>>> setting:
>>>>>
>>>>> - the local notion of the value of snmpEngineBoots to the
>>>>> value of the msgAuthoritativeEngineBoots field,*
>>>>> *
>>>>> *- the local notion of the value of snmpEngineTime to the
>>>>> value of the msgAuthoritativeEngineTime field, and*
>>>>>
>>>>> - the latestReceivedEngineTime to the value of the
>>>>> value of
>>>>> the msgAuthoritativeEngineTime field
>>>>>
>>>>> 2) if any of the following conditions is true, then the
>>>>> message is considered to be outside of the Time Window:
>>>>>
>>>>> - the local notion of the value of snmpEngineBoots is
>>>>> 2147483647;
>>>>>
>>>>> - the value of the msgAuthoritativeEngineBoots field is
>>>>> less than the local notion of the value of
>>>>> snmpEngineBoots; or,
>>>>>
>>>>> - the value of the msgAuthoritativeEngineBoots field is
>>>>> equal to the local notion of the value of
>>>>> snmpEngineBoots and the value of the
>>>>> msgAuthoritativeEngineTime field is more than 150
>>>>> seconds less than the local notion of the value of
>>>>> snmpEngineTime.
>>>>>
>>>>> From the above, I think if the reboots are the same and the
>>>>> msgAuthoritativeEngineTime is greater then the
>>>>> latestReceivedTimeEngineTime, the latestReceivedEngineTime should
>>>>> be updated. At that point if you fall down into 2) then the since the
>>>>>
>>>>> From release 2.1.2 UsmTimeTable starting at line 174
>>>>> if ((entry.getEngineBoots() < time.getEngineBoots()) ||
>>>>> ((entry.getEngineBoots() == time.getEngineBoots()) &&
>>>>> (time.getTimeDiff() + now >
>>>>> entry.getLatestReceivedTime() + 150)) ||
>>>>> (time.getEngineBoots() == 2147483647)) {
>>>>> if (logger.isDebugEnabled()) {
>>>>> logger.debug(
>>>>> "CheckTime: received message outside time window (non
>>>>> authoritative)");
>>>>> }
>>>>> return SnmpConstants.SNMPv3_USM_NOT_IN_TIME_WINDOW;
>>>>> }
>>>>> else {
>>>>> if ((entry.getEngineBoots() > time.getEngineBoots()) ||
>>>>> ((entry.getEngineBoots() == time.getEngineBoots()) &&
>>>>> (entry.getLatestReceivedTime() >
>>>>> time.getLatestReceivedTime()))) {
>>>>> /* time ok, update values */
>>>>> time.setEngineBoots(entry.getEngineBoots());
>>>>> time.setLatestReceivedTime(entry.getLatestReceivedTime());
>>>>> time.setTimeDiff(entry.getLatestReceivedTime() - now);
>>>>> }
>>>>>
>>>>> Frank Fock wrote:
>>>>>> Hi Elise,
>>>>>>
>>>>>> I would like to give you an update on the issue below.
>>>>>> I have checked the implementation, your findings, and the current
>>>>>> RFC 3414
>>>>>> and found out, that RFC 3414 precised the description of the
>>>>>> incoming
>>>>>> message handling (section 3.2.7 pages 27-28).
>>>>>>
>>>>>> SNMP4J follows that description and is therefore conforming.
>>>>>> No changes will be applied.
>>>>>>
>>>>>> Could you please verify this on your side, too?
>>>>>>
>>>>>> Best regards,
>>>>>> Frank
>>>>>>
>>>>>> Am 23.05.2013 17:52, schrieb Elise Atkins:
>>>>>>> We have been successfully using snmp4j using v3 for both
>>>>>>> requests and traps but have recently run into a problem with a
>>>>>>> client whose engine time clock runs slow.
>>>>>>>
>>>>>>> Initial time synchronization goes ok and the SNMP v3 requests
>>>>>>> and responses flow properly. Eventually this client's engine
>>>>>>> time becomes more 150 seconds behind the time SNMP4j is
>>>>>>> expecting and the responses are marked as Not In Time. I have
>>>>>>> looked at RFC 2574 Section 3.2 subsection 7b and the code in the
>>>>>>> UsmTimeTable class, checkTime method and have questions about
>>>>>>> the order of testing for timeliness.
>>>>>>>
>>>>>>> Based on the RFC, I would expect the code to test for the
>>>>>>> conditions in 1 first and update if needed before testing the
>>>>>>> conditions in 2 but the code seems to test in the reverse order.
>>>>>>> Testing 1 and updating reboots and time first will allow the
>>>>>>> client's clock to drift (fast or slow) as long as it is always
>>>>>>> increasing and remain in the time window. Am I missing something
>>>>>>> here?
>>>>>>>
>>>>>>> Elise Atkins
>>>>>>>
>>>>>>> The RFC says:
>>>>>>>
>>>>>>> 3.2. Processing an Incoming SNMP Message
>>>>>>> 7) If the securityLevel indicates an authenticated message, then
>>>>>>> the local values of snmpEngineBoots, snmpEngineTime
>>>>>>> and latestReceivedEngineTime
>>>>>>> corresponding to the value of the msgAuthoritativeEngineID
>>>>>>> field are extracted from the Local Configuration Datastore.
>>>>>>>
>>>>>>> b) If the extracted value of msgAuthoritativeEngineID is
>>>>>>> not the
>>>>>>> same as the value snmpEngineID of the processing SNMP
>>>>>>> engine
>>>>>>> (meaning this is not the authoritative SNMP engine), then:
>>>>>>>
>>>>>>> 1) if at least one of the following conditions is true:
>>>>>>>
>>>>>>> - the extracted value of the
>>>>>>> msgAuthoritativeEngineBoots
>>>>>>> field is greater than the local notion of the
>>>>>>> value of
>>>>>>> snmpEngineBoots; or,
>>>>>>>
>>>>>>> - the extracted value of the
>>>>>>> msgAuthoritativeEngineBoots
>>>>>>> field is equal to the local notion of the value of
>>>>>>> snmpEngineBoots, and the extracted value of
>>>>>>> msgAuthoritativeEngineTime field is greater than the
>>>>>>> value of latestReceivedEngineTime,
>>>>>>>
>>>>>>> then the LCD entry corresponding to the extracted value
>>>>>>> of the msgAuthoritativeEngineID field is updated, by
>>>>>>> setting:
>>>>>>>
>>>>>>> - the local notion of the value of
>>>>>>> snmpEngineBoots to
>>>>>>> the value of the msgAuthoritativeEngineBoots
>>>>>>> field,
>>>>>>> - the local notion of the value of snmpEngineTime to
>>>>>>> the value of the msgAuthoritativeEngineTime field,
>>>>>>> and
>>>>>>> - the latestReceivedEngineTime to the value of the
>>>>>>> value of the msgAuthoritativeEngineTime field.
>>>>>>>
>>>>>>> 2) if any of the following conditions is true, then the
>>>>>>> message is considered to be outside of the Time Window:
>>>>>>>
>>>>>>> - the local notion of the value of snmpEngineBoots is
>>>>>>> 2147483647;
>>>>>>>
>>>>>>> - the value of the msgAuthoritativeEngineBoots field is
>>>>>>> less than the local notion of the value of
>>>>>>> snmpEngineBoots; or,
>>>>>>>
>>>>>>> - the value of the msgAuthoritativeEngineBoots field is
>>>>>>> equal to the local notion of the value of
>>>>>>> snmpEngineBoots and the value of the
>>>>>>> msgAuthoritativeEngineTime field is more than 150
>>>>>>> seconds less than the local notion of the value of
>>>>>>> snmpEngineTime.
>>>>>>>
>>>>>>> If the message is considered to be outside of the Time
>>>>>>> Window then an error indication (notInTimeWindow) is
>>>>>>> returned to the calling module.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> SNMP4J mailing list
>>>>>>> SNMP4J at agentpp.org
>>>>>>> http://lists.agentpp.org/mailman/listinfo/snmp4j
>>>>>>
>>>>>
>>>>
>>>
>>
More information about the SNMP4J
mailing list