Hi all,

GETBULK always fills the returned buffer, so if your request does not 
completely "fill" the returned buffer, the agent will read further in the OID 
tree to fill the buffer.

(please have a look at http://jmjmon.eu/LaSupervisionDeReseau/SNMP_Mon-V010.pdf 
page 74 and further)

>From my understanding, the problem does not come from GETBULK, either from 
>snmptable that do not "clean-up" the "overhead " used to fill the buffer.

When I use GETBULK I always (see same URL page 81 and 115) check that the last 
returned information is an answer to the requested OID, and not used-to-fill 
information.

Hope this helps

Best regards
JMJ


-----Message d'origine-----
De : Turbo Fredriksson [mailto:tu...@bayour.com] 
Envoyé : dimanche 12 juillet 2015 21:46
À : net-snmp-users@lists.sourceforge.net
Objet : perl pass_persist && getnext/getbulk - no end of MIB

I've been fixing some issues with my MIB (or at least tried to, see the 
"Integer64 support" thread).

In doing so, I discovered some minor issues and one that's . "irritating".


The log file is from the output of the pass_persist script
(https://github.com/FransUrbo/snmp-modules/blob/master/zfs/zfs-snmp-stats.pl)

----- s n i p -----
DebianZFS-Jessie64-Devel-Daily:/usr/src# snmpwalk -uro -v2c -cpublic localhost 
zfsPoolStatusTable
BAYOUR-COM-MIB::zfsPoolStatusIndex.1 = INTEGER: 1
BAYOUR-COM-MIB::zfsPoolStatusIndex.2 = INTEGER: 2
BAYOUR-COM-MIB::zfsPoolName.1 = STRING: rpool
BAYOUR-COM-MIB::zfsPoolName.2 = STRING: rpool 2
BAYOUR-COM-MIB::zfsPoolGUID.1 = STRING: 4977845871582736322
BAYOUR-COM-MIB::zfsPoolGUID.2 = STRING: 3787144349319647945
BAYOUR-COM-MIB::zfsPoolSize.1 = Opaque: Int64: 8256506880
BAYOUR-COM-MIB::zfsPoolSize.2 = Opaque: Int64: 8256506880
BAYOUR-COM-MIB::zfsPoolAlloc.1 = INTEGER: 132096
BAYOUR-COM-MIB::zfsPoolAlloc.2 = INTEGER: 111616
BAYOUR-COM-MIB::zfsPoolFree.1 = Opaque: Int64: 8256374784
BAYOUR-COM-MIB::zfsPoolFree.2 = Opaque: Int64: 8256395264
BAYOUR-COM-MIB::zfsPoolCap.1 = INTEGER: 0
BAYOUR-COM-MIB::zfsPoolCap.2 = INTEGER: 0
BAYOUR-COM-MIB::zfsPoolDedup.1 = STRING: 1.00
BAYOUR-COM-MIB::zfsPoolDedup.2 = STRING: 1.00
BAYOUR-COM-MIB::zfsPoolHealth.1 = INTEGER: online(4)
BAYOUR-COM-MIB::zfsPoolHealth.2 = INTEGER: online(4)
BAYOUR-COM-MIB::zfsPoolAltRoot.1 = STRING: -
BAYOUR-COM-MIB::zfsPoolAltRoot.2 = STRING: -
BAYOUR-COM-MIB::zfsPoolUsedBySnaps.1 = INTEGER: 0
BAYOUR-COM-MIB::zfsPoolUsedBySnaps.2 = INTEGER: 0
BAYOUR-COM-MIB::zfsPoolUsed.1 = INTEGER: 282624
BAYOUR-COM-MIB::zfsPoolUsed.2 = INTEGER: 111616 
DebianZFS-Jessie64-Devel-Daily:/usr/src# egrep '[0-9] \.[0-9]' /tmp/zfs-snmp.log
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.1.1 = 1
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.1.2 = 22015-07-12 21:29:06 
.1.3.6.1.4.1.8767.2.6.5.1.2.1 = rpool
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.2.2 = rpool 2
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.3.1 = 4977845871582736322
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.3.2 = 3787144349319647945
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.4.1 = 8256506880
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.4.2 = 8256506880
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.5.1 = 132096
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.5.2 = 111616
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.6.1 = 8256374784
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.6.2 = 8256395264
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.7.1 = 0
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.7.2 = 0
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.8.1 = 1.00
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.8.2 = 1.00
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.9.1 = ONLINE
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.9.2 = ONLINE
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.10.1 = -
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.10.2 = -
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.11.1 = 0
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.11.2 = 0
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.12.1 = 282624
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.5.1.12.2 = 111616
2015-07-12 21:29:06 .1.3.6.1.4.1.8767.2.6.6.1.1.1 = 1 
DebianZFS-Jessie64-Devel-Daily:/usr/src#
----- s n i p -----

Here a "snmpwalk" work just fine. It outputs the whole zfsPoolStatusTable and 
as soon as "snmpwalk" finds the first entry of the next branch, it cancels (?) 
the continuing requests.

However:

----- s n i p -----
DebianZFS-Jessie64-Devel-Daily:/usr/src# snmptable -uro -v2c -cpublic localhost 
zfsPoolStatusTable                                                            
SNMP table: BAYOUR-COM-MIB::zfsPoolStatusTable
 zfsPoolName         zfsPoolGUID zfsPoolSize zfsPoolAlloc zfsPoolFree 
zfsPoolCap zfsPoolDedup zfsPoolHealth zfsPoolAltRoot zfsPoolUsedBySnaps 
zfsPoolUsed
       rpool 4977845871582736322  8256506880       132096  8256374784          
0         1.00        online              -                  0      282624
     rpool 2 3787144349319647945  8256506880       111616  8256395264          
0         1.00        online              -                  0      111616
BAYOUR-COM-MIB::zfsPoolStatusTable: WARNING: More columns on agent than in MIB 
DebianZFS-Jessie64-Devel-Daily:/usr/src# egrep '[0-9] \.[0-9]' 
/tmp/zfs-snmp.log2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.1.1 = 1
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.1.2 = 2
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.2.1 = rpool
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.2.2 = rpool 2
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.3.1 = 4977845871582736322
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.3.2 = 3787144349319647945
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.4.1 = 8256506880
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.4.2 = 8256506880
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.5.1 = 132096
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.5.2 = 111616
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.6.1 = 8256374784
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.6.2 = 8256395264
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.7.1 = 0
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.7.2 = 0
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.8.1 = 1.00
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.8.2 = 1.00
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.9.1 = ONLINE
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.9.2 = ONLINE
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.10.1 = -
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.10.2 = -
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.11.1 = 0
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.11.2 = 0
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.12.1 = 282624
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.5.1.12.2 = 111616
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.1.1 = 1
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.2.1 = 1198736
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.3.1 = 1194848
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.4.1 = 393386496
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.5.1 = 524515328
2015-07-12 21:30:29 .1.3.6.1.4.1.8767.2.6.6.1.6.1 = 1194848
----- s n i p -----

Here, "snmptable" claims that there's more columns, not part of the MIB. But 
they're really not part of that table.

But why isn't "snmptable" stops when it receives the 
".1.3.6.1.4.1.8767.2.6.6.1.1.1" entry like "snmpwalk" do (I only have one 
entry/line in the next table, the zfsARCUsageTable)?

And this is the same of ALL my tables. If I add "-CB" to the "snmptable" 
command it works.


Is there a special "END OF MIB" entry I need to output to make it know that 
it's done? I tried "NONE\n", but that didn't work. Tried "END\n" as well, but 
no luck there either.

I guess, from finding the "-CB" option in the manpage, that the "problem" have 
something to do with GETBULK...
--
Life sucks and then you die


------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you need 
to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to