On 2015/10/07 23:41, Stuart Henderson wrote: > Moving post from misc@. > > On 2015-10-07, Denis Fondras <open...@ledeuns.net> wrote: > > Hello, > > > > I'm using snmpd from base on 5.8 and while playing with snmpbulkget (from > > net-snmp), I noticed a weirdness. > > > > * 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.1' is ok > > * 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.31.1.1' is ok > > > > By "ok", I mean it returns the correct MIB results. However, > > > > * 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.31.1.1 > > iso.3.6.1.2.1.1' is not ok : > > -----8<----- > > iso.3.6.1.2.1.31.1.1.1.1.1 = STRING: "em0" > > iso.3.6.1.2.1.1.1.0 = STRING: "OpenBSD test.my.domain 5.8 GENERIC#3 i386" > > iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.30155.23.1 > > iso.3.6.1.2.1.1.3.0 = Timeticks: (217) 0:00:02.17 > > iso.3.6.1.2.1.1.4.0 = STRING: "r...@test.my.domain" > > iso.3.6.1.2.1.1.5.0 = STRING: "test.my.domain" > > iso.3.6.1.2.1.1.6.0 = "" > > iso.3.6.1.2.1.1.7.0 = INTEGER: 74 > > iso.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00 > > iso.3.6.1.2.1.1.9.1.1.1 = INTEGER: 1 > > iso.3.6.1.2.1.1.9.1.1.2 = INTEGER: 2 > > -----8<----- > > > > As you can see, only the first sub-OID of iso.3.6.1.2.1.31.1.1 is returned. > > To make it clear, that last command is meant to return 10x results starting > from iso.3.6.1.2.1.1 and 10x results starting from iso.3.6.1.2.1.31.1.1. > > There are two parameters involved in GetBulkReq, "non-repeaters" > (snmpbulkget -Cn# which defaults to 0) and "max-repetitions" > (-Cr# defaulting to 10). > > The response should be single results for the first "non-repeaters" > requests (allowing you to fetch e.g. the uptime and maybe some other > individual values of interest without a bunch of unwanted extras), > followed by "maxrep" number of values for any subsequent requests. > > $ snmpbulkget -Cn2 -Cr4 -v2c -c public 127.0.0.1 SNMPv2-MIB::sysDescr > IP-MIB::ipForwarding IF-MIB::ifName IF-MIB::ifInOctets > SNMPv2-MIB::sysDescr.0 = STRING: some host description > IP-MIB::ipForwarding.0 = INTEGER: notForwarding(2) > IF-MIB::ifName.1 = STRING: em0 > IF-MIB::ifName.2 = STRING: em1 > IF-MIB::ifName.3 = STRING: enc0 > IF-MIB::ifName.4 = STRING: lo0 > IF-MIB::ifInOctets.1 = Counter32: 4019922211 > IF-MIB::ifInOctets.2 = Counter32: 0 > IF-MIB::ifInOctets.3 = Counter32: 0 > IF-MIB::ifInOctets.4 = Counter32: 1433448428 > > (the answers don't have to be in the same order as the query, I have > just formatted them that way for the example to make it clearer).
Ohhhh. And now I find Gerhard Roth's post.... https://marc.info/?l=openbsd-tech&m=143375327425321&w=2 In a nutshell: the mps_getbulkreq() calls subsequent to the first one link the elements to the *first* element of the previous call, not the last element. Gerhard's diff passes in the address of the last element so it can be linked correctly. I'll look at it again tomorrow but that looks correct for the -Cr case, nonreps and I think also len counting are still a problem but I'll look at those again on top of Gerhard's diff.
