2009/2/24 Bell, Adam <[email protected]>: > The table in question is using a Textual Convention definition for an > octet string that is fixed 18 bytes in length. > Therefore when encoding the index I expect > > table.entry.firstrow.18bytesOfOID > rather than > table.entry.18.18bytesOfOID.
That sounds right, yes. > I have used the code generation tool to 'iterate tables' and in the > get_next_data_point() routine we have some code that generates the row > index. > > ... > vptr = put_index_data; > snmp_set_var_value(vptr, 18bytearray, 18); > > but this yields the second encoding. I believe that the mib2c framework ought to recognise explicitly IMPLICIT index objects, and should handle them correctly. But it doesn't really surprise me if it fails to recognise that fixed-length non-IMPLICIT index objects need to be treated in the same way. (Actually, a quick look at the mib2c code leads me to suspect that it may not even spot IMPLICIT table indexes either!) This is probably something where you need to tweak the generated code, > Is there standard way to encode fixed length OCTECT Strings? Change the type definition from ASN_OCTET_STR to be ASN_PRIV_IMPLIED_OCTET_STR. That should result in the correct encoding. Dave ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
