[SNMP4J] V3 Not In Time Window and Client Clock Drift
Elise Atkins
eatkins at tavve.com
Thu Jun 6 15:48:10 CEST 2013
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