The test team where I work found that my new MQX-based firmware was failing SNMP MIB walks for them. The problem was that when using SNMPv2 "get bulk" requests rather than the slower "get next" MIB walk, some of my tables had data larger than the response buffer set aside in RTCS, so RTCS was returning the "too big" error. Except, that's not the way a bulk request is supposed to work.
What's supposed to happen is described in RFC 1905, section 4.2.3. It's OK for RTCS to not be able to provide all the varbinds requested (there's nothing to stop users from asking for lots of these!), but it should return as many as it can rather than calling it an error. (That RFC section lists three reasons why the response can have fewer varbinds than requested; reason 1 is exactly what is happening in RTCS.)
I have a proposed fix for the RTCS code; I would welcome any comments on whether this change is a good idea. Within .../snmp/snmp.c, function "SNMP_parse_varbindlist", I modified the following code:
while (snmp->inlen) {
varp = snmp->inbuf;
varlen = snmp->inlen;
index++;
for (varcount = 0; varcount < snmp->reps; varcount++) {
if (!SNMP_request(snmp, varp, varlen, outp, outlen, &varlen)) {
if (snmp->errstat == SNMP_ERROR_tooBig)
break;
if (SNMP_ERROR_USEINDEX(snmp->errstat)) {
snmp->errindex = index;
} /* Endif */
return FALSE;
} /* Endif */
varp = outp;
outp += varlen;
outlen -= varlen;
*writelen += varlen;
} /* Endfor */
ASN1_READ_TYPELEN_EXPECT(snmp, ASN1_TYPE_SEQUENCE, varlen);
ASN1_READ_IGNORE(snmp, varlen);
} /* Endwhile */
The statement in bold ("if (snmp->errstat == SNMP_ERROR_toobig) break;") is my addition to the code. If I understand things properly, it says that if a "get next" operation performed on the repeated portion of the request fails with the specific error of being out of room, then it breaks out of the loop with only the successfully written varbinds included in the response (rather than returning FALSE).
I tested this fix using the MG-Soft MIB browser, and also examined the reply packets in Wireshark, and this seems to successfully address the problem (as opposed to trying to guess a better buffer size, which would only push the problem out to a larger repeat count or larger data).
Comments welcome!
