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 <[email protected]>: > 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 > [email protected] > http://lists.agentpp.org/mailman/listinfo/snmp4j _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
