All, I have made the changes suggested below and the getnext functionality works as expected. I see the proper index values when I fetch the table. Changing the index type as suggested in netsnmp_table_helper_and_indexes() did the trick. (test_handler.c)
The index values without byte length encoding are as follows
table.entry.1.firstIndexBytes.secondIndexBytes.integer .
I have a follow on problem, when I do a GET or SET on a specific column
the oid = table.entry.column.firstIndexBytes.secondIndexBytes.integer
This looks correct
net-snmp is returning no such instance, I do not get control in the registered
table handler. It is never called.
I do not get to the line
data_context = netsnmp_extract_iterator_context(request);
(test_handler.c)
I also tried changing this to use the ASN_PRIV_IMPLIED_OCTET_STR type, but that
failed horribly, net-snmp did not recognize this type.
case COLUMN_TESTString1NAME:
{
char *retval;
size_t retval_len = 0;
retval = get_TEST_str1(data_context, &retval_len);
if (retval)
snmp_set_var_typed_value(var, ASN_OCTET_STR,
(const u_char *) retval, retval_len);
}
break;
Is there some other TYPE change I need to make to allow this to function
properly?
I believe my issue will be deep in the oid handler/recognition against
registered OIDs but could you point at where to start looking. Is there some
code to be added for this new type that would parse the OID without the length
bytes in the encoding?
Attached is some code for the current condition.
Thanks so much,
Adam
-----Original Message-----
From: Bell, Adam [mailto:[email protected]]
Sent: Wednesday, February 25, 2009 12:26 PM
To: Dave Shield
Cc: [email protected]
Subject: RE: Question on SNMP version
Thanks for the pointer,
will try it.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Dave Shield
Sent: Wednesday, February 25, 2009 5:56 AM
To: Bell, Adam
Cc: [email protected]
Subject: Re: Question on SNMP version
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
The information contained in this electronic mail transmission may be
privileged and confidential, and therefore, protected from disclosure. If you
have received this communication in error, please notify us immediately by
replying to this message and deleting it from your computer without copying or
disclosing it.
------------------------------------------------------------------------------
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
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
test_handler.h
Description: test_handler.h
test_handler.c
Description: test_handler.c
test_handler_access.c
Description: test_handler_access.c
test_handler_checkfns.c
Description: test_handler_checkfns.c
------------------------------------------------------------------------------ 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
