We have a problem with our MIB module when accessing it with snmpwalk and doing iteration through the tree i.e. with getNextRequests. When using direct access of OIDs with getRequest, everything works fine.
I have already debugged it quite a lot so I can give my idea of what happens, but what I don't know is should it be fixed in snmpd or our module. We have fwCpuName table which SHOULD look like this with 2 cpus fwCpuName.0 = STRING: Cpu(s) fwCpuName.1 = STRING: cpu1 fwCpuName.2 = STRING: cpu2 Internally the function is simple, it just excepts that the index (0, 1, 2) is available inside the function so we can fetch the cpu name with it. The module expects that the index is passed in the netsnmp_table_request_info struct as per net-snmp examples, and then accessed with i = *(table_info->indexes->val.integer); But this is not what happens when iterating the table with snmpwalk. This is what happens: snmpwalk -c public -v 1 192.168.206.172:161 SNMPv2-SMI::enterprises.47565.1.1.1.11.1.1.2 fwCpuName.0 = STRING: dummy fwCpuName.1 = STRING: Cpu(s) fwCpuName.2 = STRING: cpu1 So the net-snmp code call our module, but the table_info struct is wrong. Here are some traces: 2023-05-03 19:38:51.777 syslog info: snmpd: table_helper_handler(): helpers/table.c, 243: 2023-05-03 19:38:51.777 syslog info: snmpd: helper:table:req: 2023-05-03 19:38:51.777 syslog info: snmpd: Got GETNEXT (161) mode request for handler table: base oid: 2023-05-03 19:38:51.777 syslog info: snmpd: SNMPv2-SMI::enterprises.47565.1.1.1.11.1 2023-05-03 19:38:51.777 syslog info: snmpd: SNMPv2-SMI::enterprises.47565.1.1.1.11.1.1.2 So here we get a getNextRequest for the cpu table, without the index as it should be, because we want the next from 11.1.1.2, i.e. 11.1.1.2.0. 2023-05-03 19:38:51.777 syslog info: snmpd: table_helper_handler(): helpers/table.c, 532: 2023-05-03 19:38:51.777 syslog info: snmpd: helper:table: 2023-05-03 19:38:51.777 syslog info: snmpd: not enough for indexes And here another trace where it says that the OID is not long enough for indexes, which is correct. But since this is a getNextRequest, the code should be able to figure out that the next OID in line is the .0 index, and that should be passed to our module, but instead this happens: 2023-05-04 12:57:39.063 syslog info: snmpd: netsnmp_call_handler(): agent_handler.c, 542: 2023-05-04 12:57:39.063 syslog info: snmpd: handler:calling: 2023-05-04 12:57:39.063 syslog info: snmpd: calling handler fwCpuStatsTable for mode GET 2023-05-04 12:57:39.064 syslog info: snmpd: colnum=2 number_indexes=0 i=0 ti=0 So here it calls our handler fwCpuStatsTable for GET. The last line is my own debug where the problem is that the table_info->number_indexes is zero. So net-snmp didn't add the index zero to table_info and therefore we can't fetch the correct string in our module. Then net-snmp sends this out as UDP 2023-05-04 12:57:39.068 syslog info: snmpd: SNMPv2-SMI::enterprises.47565.1.1.1.11.1.1.2.0 = STRING: "dummy" So here the OID is correct with the .0 in the end, but since the module was called without the .0, the string remains as dummy. Then the next request comes: 2023-05-04 12:57:39.080 syslog info: snmpd: Got GETNEXT (161) mode request for h 2023-05-04 12:57:39.080 syslog info: snmpd: SNMPv2-SMI::enterprises.47565.1.1.1.11.1.1.2.0 So this is the correct request since we want the next OID from the .0 i.e. .1. But here it seems that again net-snmp sends the .0 index to our module instead of .1 2023-05-04 12:57:39.082 syslog info: snmpd: colnum=2 number_indexes=1 i=0 index_oid_len=1 .0 2023-05-04 12:57:39.084 syslog info: snmpd: SNMPv2-SMI::enterprises.47565.1.1.1.11.1.1.2.1 = STRING: "Cpu(s)" Here the number_indexes is 1 as is expected, but the integer is 0 (i=0) instead of 1. Then it outputs the .1 index as "Cpu(s)", which is wrong. So as a summary the problem is that for GETNEXT requests, net-snmp puts the actual OID index to table_info, instead of the NEXT. Esa-Pekka
_______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
