Bug#908514: [rt.cpan.org #127094] possible duplicate, doubts about the patch and the original code

[Josip Rodin]

Hi,

If the logic is changed in line 2620 to assume empty _error to be a sign of
success, it would contradict the comment above that says "If another error
is returned, we assume that the synchronization has failed."

This might actually be a duplicate of https://rt.cpan.org/Public/Bug/Display.html?id=75191

Speaking of duplicate reports, I came across this by trying to use a Munin
plugin for access MikroTik's SNMP interface, which seems to work fine using
SNMP v3 from snmpwalk, but croaks in Net::SNMP with v3.
As it turns out, it's been many years now since this code path has been
confusing people, judging by mentions of it in numerous online forums,
like:
 * https://forum.centreon.com/forum/centreon-use/centreon-project/6646-centreon-and-snmp-v3/page2
   from 2008
 * http://www.perl-community.de/bat/poard/thread/13628 from 2009
 * https://www.sugarbug.fr/blog/files/supervision_switch_3com_snmpv3.html
   from 2011
 * https://forum.mikrotik.com/viewtopic.php?t=91863 from 2014
 * http://gojooz.blogspot.com/2013/10/snmpv3-error-perl-netsnmp-time.html
   from 2013
 * https://sourceforge.net/p/net-snmp/mailman/net-snmp-users/thread/alpine.BSF.2.20.1606121624280.60771%40freesbee.wheel.dk/
   from 2016
 * https://lists.oetiker.ch/pipermail/mrtg/2016-July/037451.html from 2016
 * https://community.opmantek.com/display/NMIS/Perl+Net%3A%3ASNMP+Error%3A+Time+synchronization+failed+during+discovery
   from 2018

Even if all those devices have not been RFC-compliant, I would still say
it's doubtful that the Net::SNMP approach of croaking with a single opaque
sentence -- and a code warning on top -- is the right thing to do.

-- 
     2. That which causes joy or happiness.