[SNMP4J] V3 Not In Time Window and Client Clock Drift

[Frank Fock]

Hi Elise,
I agree, that the code should check case 1) first. I have not yet verified the current code but will do so tomorrow. If it needs to be changed (which seems to be true, according to your analysis). I will provide a path (new release until 31.5.2013).
Best regards,
Frank


Am 23.05.2013 um 17:52 schrieb Elise Atkins <eatkins at tavve.com>:

> 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