Bug #75191 for Net-SNMP: Synchronize in SNMPv3

Tue Feb 21 08:14:40 2012 https://www.google.com/accounts/o8/id?id=AItOawk1HFsg_ZtNpUosijePsEL3G_I7ua-bL6w - Ticket created

Subject:

Synchronize in SNMPv3

Hi there. I'm not quite sure if this is actually a bug in Net::SNMP or just a bug in the HP ProCurve SNMPv3 engine but let's start at the beginning: We're using MRTG to generate some basic network graphs of our traffic. Recently we started to graph them on our internal network which is run with HP ProCurve switches (2510G). We're using SNMPv3 since a few years now without any problems and the ProCurve SNMPv3 users are set up properly. However after activating MRTG (which uses Net::SNMP) the switches are generating the following error message on every run: Show quoted text

> Feb 21 13:49:07 a.b.c.d snmp: SNMP Security access violation from e.f.g.h

The error message doesn't stop MRTG (or SNMPv3) from working. It just gets triggered and written to the error log on every SNMPv3 authentification. So digged into this and noticed that snmpwalk and the other tools from net-snmp are NOT triggering this error message. After digging deeper and parsing the SNMPv3 bytestreams I noticed that Net::SNMP is not putting the engineBoots- and engineTime-values received in the first paket (the one that's generating the usmStatsUnknownEngineIDs error) into the second, authentification paket. However net-snmp is doing that. So I decided to try to fix that and in fact the error message doesn't get triggered any more. Attached is a patch I've quickly put together. I'm not sure what RFC says about this. Just wanted to fix that annoying error message. A side effect of my patch is that usmStatsNotInTimeWindows won't get triggered any more on authentification. Additional I'm not sure about other side effects. I've tested my patch against all our SNMPv3 devices and authentification is still working. Regards, / manuel

Tue Feb 21 08:19:46 2012 https://www.google.com/accounts/o8/id?id=AItOawk1HFsg_ZtNpUosijePsEL3G_I7ua-bL6w - Correspondence added

From:

Manuel

hm. looks like the attachment got lost. trying again... or just use: http://manuel.mausz.at/coding/patches/net-snmp-synchronize.patch / manuel

Subject:

net-snmp-synchronize.patch

diff -Naur a/lib/Net/SNMP.pm b/lib/Net/SNMP.pm --- a/lib/Net/SNMP.pm 2011-12-24 00:41:27.000000000 +0100 +++ b/lib/Net/SNMP.pm 2012-02-21 13:17:04.000000000 +0100 @@ -2564,7 +2564,7 @@ if ($this->{_security}->discovered()) { DEBUG_INFO('discovery complete'); - return $this->_discovery_complete(); + $this->_discovery_complete(); } # "If authenticated communication is required, then the discovery @@ -2618,7 +2618,7 @@ # assume that the synchronization has failed. if (($this->{_security}->discovered()) && - ($this->{_error} =~ /usmStatsNotInTimeWindows/)) + ((!$this->{_error}) || ($this->{_error} =~ /usmStatsNotInTimeWindows/))) { $this->_error_clear(); DEBUG_INFO('discovery and synchronization complete'); diff -Naur a/lib/Net/SNMP/Security/USM.pm b/lib/Net/SNMP/Security/USM.pm --- a/lib/Net/SNMP/Security/USM.pm 2011-12-24 00:41:27.000000000 +0100 +++ b/lib/Net/SNMP/Security/USM.pm 2012-02-21 13:20:47.000000000 +0100 @@ -471,6 +471,16 @@ ); } + # Synchronize the time + if (!$this->_synchronize($msg_engine_boots, $msg_engine_time)) { + return $this->_error(); + } + + # Check for timeliness + if (!defined $this->_timeliness($msg_engine_boots, $msg_engine_time)) { + return $this->_error(); + } + if ($security_level > SECURITY_LEVEL_NOAUTHNOPRIV) { # Authenticate the message @@ -478,16 +488,6 @@ return $this->_error(); } - # Synchronize the time - if (!$this->_synchronize($msg_engine_boots, $msg_engine_time)) { - return $this->_error(); - } - - # Check for timeliness - if (!defined $this->_timeliness($msg_engine_boots, $msg_engine_time)) { - return $this->_error(); - } - if ($security_level > SECURITY_LEVEL_AUTHNOPRIV) { # Validate the msgPrivacyParameters length.

Tue Feb 21 08:19:47 2012 The RT System itself - Status changed from 'new' to 'open'

Thu Mar 15 14:27:27 2012 dtown [...] cpan.org - Correspondence added 5 min

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 "Access Violations". I would like to keep the Net::SNMP module inline with RFC 3414, so it sends both messages. I would consider a ticket to add a flag to toggle this functionality. == From RFC 3414 Section 4 == 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 == End ==

Thu Mar 15 14:27:28 2012 dtown [...] cpan.org - Given to DTOWN

Fri Dec 28 16:22:07 2018 joy [...] entuzijast.net - Correspondence added

Subject:	[rt.cpan.org #75191] possible duplicate
Date:	Fri, 28 Dec 2018 22:21:57 +0100
To:	bug-Net-SNMP [...] rt.cpan.org
From:	Josip Rodin <joy [...] entuzijast.net>

Possible duplicate: https://rt.cpan.org/Public/Bug/Display.html?id=127094 BTW I've tried applying only the lib/Net/SNMP/Security/USM.pm portions of the original patch posted here in 2012, but they don't make my use case work. It sounds more like the breaking of the logic with !$this->{_error} was the kicker. -- 2. That which causes joy or happiness.