I am writing an agent using 5.2.1 and mib2c/mfd. If my agent
receives a GET request, but the column has not been implemented yet, I
return MFD_SKIP. If I use snmpget to kick off a GET request, the
*_interface.c code returns ASN_PRIV_RETRY and no error. This ends up
causing retries, until snmpge
Is it "legal" to define a MIB with holes in the oid numbering to
allow for features that are unknown today to be added at a later date???
I.e., a table with oids:
.1.3.6.1.23.1.1
.1.3.6.1.23.1.2
.1.3.6.1.23.1.3 <- 4,5,6,7,8,9 skipped.
.1.3.6.1.23.1.10
.
Dave Shield wrote:
The cardinal rule of MIB design is that you should never have two
definitions with different behaviour sharing the same OID.
We're continually adding new features to our product, and that's in
conflict with the cardinal rule above. The process that I'm considering
is t
Right now our MFD based agent returns MFD_SKIP if an object doesn't
exist, and that's gets translated by net-snmp into a value being
returned who's type is, SNMP_NOSUCHINSTANCE (which is really
ASN__CONTEXT | ASN_PRIMITIVE | 0x1). This seems correct according to the
RFC (A snippet follows).