I am running into an issue where the Net-SNMP Agent (version 5.8) running on my device is placing the length of a fixed-length index string into the OID.
For context: I have a MIB that has defined a textual convention (being used as the type for the index) as having SYNTAX OCTET STRING(SIZE (18)), making it a fixed-length octet string. The index is of that type in the table's entry. I am wondering if this is the correct way to define a fixed-length string and, if so, is there a work around for this to correct the Agent to not place the length in the OID.
Looking in the Agent code (note I am using the Net SNMP style for the implementation), as it calls the get_next_data_point function, it uses the snmp_set_var_value function to fill out these values. I wonder if there is another function to call instead or if I can change the type somehow of the index to force SNMP to handle the string correctly.
For further context: According to RFC 2578 section 7.7, a variable-length string appearing in an OID (not preceded by the IMPLIED keyword) must be encoded with n+1 sub-identifiers, where the first sub-identifier is the value n itself (the length of the string) followed by n sub-identifiers, each one encoding one octet from the string. A fixed-length string is done the same way, but without the length of the string being encoded in the OID (I might just be confused how a fixed-length string is defined in a MIB).
For more context, I was using the mib2c tool to generate C code for the mib module. It turns out that the code was registering the indexes as OCTET strings
netsnmp_table_helper_add_indexes(table_info, ASN_OCTET_STR, ...)
Changing that to ASN_PRIV_IMPLIED_OCTET_STR made it a fixed length string and fixed the OID. One must also set the lengths for each of the indexes as otherwise, NetSNMP will assume they are an IMPLIED length string and not a fixed length one.