Bug #67015 for Net-SNMP: SNMPv3 authentication failures, but data gets retrieved

The Net::SNMP module uses the discovery process described in Section 4 of RFC 3414 when first communicating with a SNMPv3 agent. In this section, it is recommended that two distinct and intentionally invalid messages be sent for discovery, if authentication is being used. My guess is that the second message being sent by the module is triggering the "authentication failures". == From RFC 3414 == The User-based Security Model requires that a discovery process obtains sufficient information about other SNMP engines in order to communicate with them. Discovery requires an non-authoritative SNMP engine to learn the authoritative SNMP engine's snmpEngineID value before communication may proceed. This may be accomplished by generating a Request message with a securityLevel of noAuthNoPriv, a msgUserName of zero-length, a msgAuthoritativeEngineID value of zero length, and the varBindList left empty. The response to this message will be a Report message containing the snmpEngineID of the authoritative SNMP engine as the value of the msgAuthoritativeEngineID field within the msgSecurityParameters field. It contains a Report PDU with the usmStatsUnknownEngineIDs counter in the varBindList. If authenticated communication is required, then the discovery process should also establish time synchronization with the authoritative SNMP engine. This may be accomplished by sending an authenticated Request message with the value of msgAuthoritativeEngineID set to the newly learned snmpEngineID and with the values of msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime set to zero. For an authenticated Request message, a valid userName must be used in the msgUserName field. The response to this authenticated message will be a Report message containing the up to date values of the authoritative SNMP engine's snmpEngineBoots and snmpEngineTime as the value of the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields respectively. It also contains the usmStatsNotInTimeWindows counter in the varBindList of the Report PDU ==== I know that the (UCD) NET-SNMP utilities only sends the first message. I would like to keep the Net::SNMP module inline with RFC 3414, so it sends both messages. You can modify the module to only send the first message by overriding the discovered() method in the Net::SNMP::Security::USM module. Declare the following after specifically loading the Net::SNMP::Security::USM module: use Net::SNMP; use Net::SNMP::Security::USM; ... sub Net::SNMP::Security::USM::discovered { my ($this) = @_; return $this->{_discovered}; }

Thanks David for your reply, but it isn't working correctly. If I put the lines you mentioned into my script, it returns: Subroutine Net::SNMP::Security::USM::discovered redefined at ./iftraffic_test.pl line 80. $VAR1 = '1.3.6.1.2.1.2.2.1.5.1000'; $VAR2 = '1.3.6.1.2.1.2.2.1.8.1000'; $VAR3 = '1.3.6.1.2.1.2.2.1.10.1000'; $VAR4 = '1.3.6.1.2.1.2.2.1.16.1000'; Host: 10.176.201.129 SNMP version: 3 SNMPv2 community: public WARNING: SNMP error: Received usmStatsNotInTimeWindows.0 Report-PDU with value 510 The general output is generated by the script, populated by $session->error which was triggered by if ( !defined( $response = $session->get_request(@snmpoids) ) ) How fix this issue? Secondly, the devices are still logging "Authentication Failed" messages. Kind Regards Christian

In order to eliminate the second message from being sent during the SNMPv3 discovery/synchronization process you will have manually edit the installed "Net/SNMP/Security/USM.pm" and add the following line of code at line 461: $this->_synchronize($msg_engine_boots, $msg_engine_time); 454 } else { 455 456 # Handle authoritativeEngineID discovery 457 if (!defined $this->_engine_id_discovery($msg_engine_id)) { 458 return $this->_error(); 459 } 460 461+ $this->_synchronize($msg_engine_boots, $msg_engine_time); 462 463 } The line numbers apply to "$Id: USM.pm,v 4.1 2010/09/10 00:01:22 dtown Rel $" packaged with Net-SNMP v6.0.1.

The Net::SNMP module is following the discovery process described in RFC 3414. A work around was provided to reduce the "perceived" authentication failures by short circuiting part of the discovery process. The vendor of the agent generating the authentication failures must be contacted to determine the reason these errors are being logged.