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.
