[SNMP4J] V3 Not In Time Window and Client Clock Drift
Frank Fock
fock at agentpp.com
Tue Jun 4 23:25:25 CEST 2013
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