#2626 snmpbulkwalk fails to return all mibs while snmpwalk works fine.

[Sowrabha]

I am using net-snmp 5.4.1
And this bug occurs only for two Appliance kit specific mibs .ie

Sun FM

view fishview included .1.3.6.1.4.1.42.2.195

Sun AK

view fishview included .1.3.6.1.4.1.42.2.225

zs3-2-blr03-a# snmpwalk -v 2c -c public 127.0.0.1
.1.3.6.1.4.1.42.2.225.1.6.1.2
SNMPv2-SMI::enterprises.42.2.225.1.6.1.2.1 = STRING: "pool-a/vishwa/fs2"
SNMPv2-SMI::enterprises.42.2.225.1.6.1.2.2 = STRING: "pool-a/sid/share1"
SNMPv2-SMI::enterprises.42.2.225.1.6.1.2.3 = STRING:
"pool-a/project_name/share_name"
SNMPv2-SMI::enterprises.42.2.225.1.6.1.2.4 = STRING: "pool-b/vishwa/fs1"

zs3-2-blr03-a# snmpbulkwalk -v 2c -c public 127.0.0.1
.1.3.6.1.4.1.42.2.225.1.6.1.2
SNMPv2-SMI::enterprises.42.2.225.1.6.1.2.1 = STRING: "pool-a/vishwa/fs2"
SNMPv2-SMI::enterprises.42.2.225.1.6.1.2.1 = No more variables left in this
MIB View (It is past the end of the MIB tree)

snmpbulkget also fails to get the mib and responds in the similar way as snmpbulkwalk.

I see that this bug is similar to the bug "#1426 snmpbulkwalk fails to return all MIBs when polling net-snmp " which is closed but it is only specific to the above mentioned mibs.

Can i please have your suggestions on how i can proceed with this bug?!

[Bill Fenner]

You don't give much information about how your extension modules are implemented. If you can't fix their getbulk handling (to be any more specific here you would have to provide details of how the modules are implemented), you can inject the bulk_to_next helper. (In fact, if you don't explicitly claim that you can getbulk using the HANDLER_CAN_GETBULK flag, netsnmp_create_handler_registration explicitly adds it for you.)

So, if you're calling netsnmp_register_handler, turn off HANDLER_CAN_GETBULK. If you're building up a handler manually, insert bulk_to_next with, e.g.,

        netsnmp_inject_handler(reginfo,
                               netsnmp_get_bulk_to_next_handler());

[Bill Fenner]

No response from originator.