On 2015/04/24 17:16, Andy Lemin wrote: > > I tried this, but I don't see all of the OID's, I only see > OPENBSD-PF-MIB at iso.org.dod.internet.private.enterprises.openBSD;
Hmm. What is printed at the bottom of OPENBSD-PF-MIB for you? I think there is some broken stuff in at least table printing that would stop the client from moving on to the next oid correctly. For example if I have a table containing both someaddress/32 and someaddress/31 (ok so this is useless, but still) I get this (the values should be increasing all the time and this hits snmpwalk's loop detection): OPENBSD-PF-MIB::pfTblAddrTblIndex.3.XX.XXX.92.23.32 = INTEGER: 3 OPENBSD-PF-MIB::pfTblAddrTblIndex.3.XX.XXX.114.56.29 = INTEGER: 3 OPENBSD-PF-MIB::pfTblAddrTblIndex.3.XX.XXX.8.161.32 = INTEGER: 3 OPENBSD-PF-MIB::pfTblAddrTblIndex.3.XX.XXX.40.194.32 = INTEGER: 3 OPENBSD-PF-MIB::pfTblAddrTblIndex.3.XX.XXX.40.194.31 = INTEGER: 3 Error: OID not increasing: OPENBSD-PF-MIB::pfTblAddrTblIndex.3.XX.XXX.40.194.32 >= OPENBSD-PF-MIB::pfTblAddrTblIndex.3.XX.XXX.40.194.31 - this mib with the IPs as part of the OID seems a bit odd to me, I'd have thought it would be better to have something like pfTblAddrTblIndexIP.<tableid>.<objectid> = 192.0.2.0, with another table for pfTblAddrTblIndexNetmask.<tableid>.<objectid> = 255.255.255.0 or something.. Anyway: if I then remove that address from the table, I get a false "noSuchName" for the getnextrequest, snmpe_parse: 10.15.5.2: SNMPv2 'public' context 1 request 1293928296 snmpe_parsevarbinds: 10.15.5.2: oid iso.org.dod.internet.private.enterprises.openBSD.pfMIBObjects.pfTables.pfTblAddrTable.pfTblAddrEntry.pfTblAddrTblIndex.3.XXX.XXX.155.84.32 snmpe_parse: 10.15.5.2: SNMPv2 'public' context 1 request 1293928297 snmpe_parsevarbinds: 10.15.5.2: oid iso.org.dod.internet.private.enterprises.openBSD.pfMIBObjects.pfTables.pfTblAddrTable.pfTblAddrEntry.pfTblAddrTblIndex.3.XXX.XX.187.0.24 snmpe_parsevarbinds: 10.15.5.2: invalid varbind element, error index 1 > I.e. Run snmpd on 127.0.0.1:161, and run net-snmp on the interface IP, > and then add proxy directives to net-snmp to forward all the branches > snmpd provides to 127.0.0.1:161 (snmpd). > https://www.packetmischief.ca/2012/02/26/ > net-snmp-and-snmpd-coexistence-on-openbsd/ Net-SNMP really isn't great. There is years worth of compatibility crap with old OS releases that they don't want to remove, and ifdefs all over the place, making the code very hard to follow. IMHO it would be a much better idea to identify any important things missing from snmpd and see if it's possible to add them there instead. Yes snmpd has bugs and missing parts but it is significantly less scary code and those problems won't be fixed if people defer to Net-SNMP :)
