Multiple SNMPv3 queries are not processed properly.

When Zabbix sends an requests to SNMPv3-enabled devices it incorrectly uses msgAuthoritativeEngineID, msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime parameters returned by those devices by authNoPriv or authPriv security level of auth process. The parameters are unique for each device and depend on:

msgAuthoritativeEngineID: depeds on the device used
msgAuthoritativeEngineBoots: depeds on number of engine reboots
msgAuthoritativeEngineTime: depends on device's uptime

SNMPv3 devices (security level of authNoPriv or authPriv) respond to a get_snmp request only if all three parameters are set up correctly and are the same as current parameters inside in the devices. Otherwise device answers "usmStatsNotInTimeWindows" error, and Zabbix writes "Network Error" in own logs.

Zabbix saves msgAuthoritativeEngineID parameter correctly for each device by auth process. However, two other parameters are not saved correctly. Zabbix uses these parameters saved for the first device to query other devices in the network. The result is only one SNMPv3 device is monitored correctly. It may be a bug in software.

This problem is described here (in Russian): http://www.zabbix.com/forum/showthread.php?t=16093
A bug with similar symthoms described here: https://support.zabbix.com/browse/ZBX-832
SNMPv3 query/response message exchange is described here: http://www.insanum.com/docs/usm.html

"As mentioned above, the USM requires that the snmpEngineID, snmpEngineBoots, and snmpEngineTime of the authoritative engine be placed in the msgSecurityParameters. This requires the non-authoritative engine (i.e. manager) to know these values for the authoritative engine (i.e. agent) before a GET, NEXT, or SET operation can be completed.

This is achieved by a discovery process. There are two discovery transactions that occur. The first is to discover the snmpEngineID of the agent. The second is to discover the snmpEngineBoots and snmpEngineTime. The second transaction is only needed if the manager wants to use a security level of authNoPriv or authPriv. This is because the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime are used by the timeliness module which is part of the authentication process.

The first discovery transaction is initiated by the manager sending an SNMPv3 packet with the msgAuthoritativeEngineID containing a bogus value. When the agent receives a packet where the msgAuthoritativeEngineID is different than its own, the packet is discarded and a discovery packet is returned to the manager. The returned discovery packet contains the correct snmpEngineID which must be used by the manager.

The second discovery transaction requires an authenticated packet be sent to the agent. This means that the authentication flag is set in the msgFlags, and the msgAuthenticationParameters contains the computed message digest for the packet. The secret key used for authenticating the packet is from the user specified in msgUserName. What makes this a discovery packet is that the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime contain bogus values. When the agent receives this packet, it is first authenticated. Once the authentication is completed, the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime values are checked. Since the values are bogus, the packet is discarded and a second discovery packet is returned to the manager. The returned discovery packet is authenticated, using the same user, and contains the correct values of the snmpEngineBoots and snmpEngineTime which must be used by the manager."

"Once a manager has learned the snmpEngineBoots and snmpEngineTime of an agent, the manager must maintain its own local notion of what these values are supposed to be. This requires the manager to increment the learned snmpEngineTime every second so the value will be very close to the master values maintained by the agent. If the snmpEngineTime rolls over, then the snmpEngineBoots must be incremented. A manager must keep local notions of these values for each agent in which it wishes to communicate.

The timeliness checks by an agent are considered part of the authentication process and are done right after the received packet has been authenticated. If the msgAuthoritativeEngineBoots is different than the agent's current value of the snmpEngineBoots, the packet is discarded and a discovery packet is sent back to the manager. If that check passes, then the msgAuthoritativeEngineTime is checked against the agent's current value of the snmpEngineTime. If the difference between the two is more or less than 150 seconds, the packet is discarded and a discovery packet is sent back to the manager. If both of the checks pass, then the packet is considered to have been received in a timely manner and processing continues.

The value of +/- 150 seconds for the comparison of the snmpEngineTime is the default value specified by the RFC. This value could be modified to something more suitable based on the speed and size of your network. "