Hi all,
I am running 5.2.4 and am having a problem indexing a table with fixed octet
string indexes.
A GetNext of the table returns the proper encoding (see below) get a get or set
on a column fails with No Such instance.
After digging though table code and ultimately getting down into
mib.c:get_one_index_oid(). I think I have found the problem.
Since the ASN_PRIV_IMPLIED_OCTET_STR does not have an encoded length for the
oid, the routine is taking the entire oid length.
The table in question has 3 indexes and therefore the last two are not parsed
and the result is No Such Instance.
The calling tree is as follows
netsnmp_call_handler() in agent_handler.c
table_helper_handler() in table.c
parse_one_index_oid() in mib.c
The oid is table.entry.1.18bytesOfIndex.5BytesOfIndex.1byte where
18 bytes is ASN_PRIV_IMPLIED_OCTET_STR
5 bytes is ASN_PRIV_IMPLIED_OCTET_STR
1 byte is ASN_UNSIGNED.
parse_one_index_oid() just takes 24 bytes as the index but the algorithm is
expecting 3 indexes - so it fails.
The netsnmp_table_registration_info_s (created at init time in the table
handler code) sets the index types but there is no info about the individual
index lengths, the table_info->number_indexes == 3 (that is correct)
The question is - how to split the index apart properly and get this to work?
Is this something that has been fixed in later versions?
Thanks,
Adam
-----Original Message-----
From: Bell, Adam [mailto:[email protected]]
Sent: Friday, February 27, 2009 9:35 AM
To: Bell, Adam; Dave Shield
Cc: [email protected]
Subject: RE: Question on SNMP version
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.
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
