[SNMP4J] V3 Not In Time Window and Client Clock Drift
Frank Fock
fock at agentpp.com
Tue Jun 11 19:28:48 CEST 2013
Elise,
Please use the now released version 2.2.2. You can download it from
https://oosnmp.net/dist/release/org/snmp4j/snmp4j/2.2.2/
The SNAPSHOT release did not work for single CPU environments.
This has been fixed in the final version.
The SNMP4J Web Site will be updated later today when the 1.10.5
release is ready too.
Best regards,
Frank
Am 11.06.2013 17:03, schrieb Elise Atkins:
> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
--
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax: +49 7024 8688231
More information about the SNMP4J
mailing list