On Mon, 2022-01-03 at 15:09 +0100, Joel Carnat wrote: > Hello, > > I have just patched my snmpd from -current ; everything else is > 7.0-stable. I'm not sure what happens but I use the same snmpd.conf and > connects to snmpd from another machine using > > # snmpwalk -v 3 -a SHA -A "changeme" -l authPriv -u telegraf \ > -x AES -X "changeme" server > > But using the patched snmpd, I get the following error: > mib_2 = No Such Object available on this agent at this OID. Using the > 7.0 version, it works perfectly. > > I can send full snmpd logs if you think it's usefull.
Thanks for testing, unfortunately I can't reproduce your error: martijn$ snmpwalk -v3 -a SHA -A test1234 -l authpriv -u testsha1 -x AES -X test1234 127.0.0.1 | head SNMPv2-MIB::sysDescr.0 = STRING: OpenBSD martijn.office.cloudvps.nl 7.0 GENERIC.MP#213 amd64 SNMPv2-MIB::sysObjectID.0 = OID: OPENBSD-BASE-MIB::openBSDDefaultObjectID SNMPv2-MIB::sysUpTime.0 = Timeticks: (344136) 0:57:21.36 SNMPv2-MIB::sysContact.0 = STRING: Martijn van Duren SNMPv2-MIB::sysName.0 = STRING: martijn SNMPv2-MIB::sysLocation.0 = STRING: SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00 SNMPv2-MIB::sysORIndex.1 = INTEGER: 1 SNMPv2-MIB::sysORIndex.2 = INTEGER: 2 SNMPv2-MIB::sysORIndex.3 = INTEGER: 3 Also, your report doesn't make sense to me: snmpwalk is from net-snmp, while the name mib_2 is used (incorrectly) by snmp(1). And "No Such Object" should not happen on getnext requests (which is what a walk does): Something must have gone really weird to end up in such an error path. Could you please provide a minimal proof of concept snmpd.conf with full client command and output to allow me to reproduce this? > > Regards, > Joel C. > > On 1/3/22 13:57, Martijn van Duren wrote: > > On Sun, 2021-11-21 at 14:58 +0100, Martijn van Duren wrote: > > > On Sun, 2021-11-14 at 14:35 +0000, Stuart Henderson wrote: > > > > On 2021/11/14 11:49, Martijn van Duren wrote: > > > > > sthen@ found an issue when using this diff with netsnmp tools. > > > > > > > > > > The problem was that I put the requestID in the msgID, resulting > > > > > in a mismatch upon receiving the reply. The reason that snmp(1) > > > > > works is because msgID and requestID are the same. > > > > > Diff below fixes things. > > > > > > > > This version works for me, and the runtime increase with librenms > > > > fetches and polls (which use a mixture of get/bulkwalk) is acceptable > > > > (10% or so). > > > > > > > Anyone else put this through a test? I want to move forward with this. > > > > > > martijn@ > > > > > 2 month ping. > > So far I only have gotten test results from sthen@. > > Should I just put this in or is someone planning to actually look into > > the code? > > > > martijn@
