net-snmp

2009/2/24 Sathyanarayana Murthy, Harish Kolar <harish.ks@...>:
> My question here is this version is of the agent or the SNMP manager who is running this code?

Neither.
The version is of the protocol that is used between them.

The agent and the manager must agree how they will communicate.
Either they both use SNMPv1 or they both use SNMPv3.

In the same way, we have to agree what language we will use
to communicate.   Either you can ask me a question in English,
or you can ask me a question in Swahili.

Typically I will respond in the same language that you used for the
original question.   In the same way, the agent will respond using
the same version of the protocol as the original request.

Or if you ask me a question in a language that I don't understand
(like Swahili), then I'll probably just ignore you.



> One more question is how can we get to know the version of SNMP on local PC/remote PC.

   Read the documentation for the software that is running at either end.

Dave

Hi all,

I have a very specific question about the encoding of a multi-oid table
index.

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.

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.

Is there standard way to encode fixed length OCTECT Strings?

Thanks,
Adam
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.

2009/2/24 Bell, Adam <Adam.Bell@...>:
> 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

Thanks for the pointer,
will try it. 

-----Original Message-----
From: dave.shield@... [mailto:dave.shield@...] On Behalf Of Dave Shield
Sent: Wednesday, February 25, 2009 5:56 AM
To: Bell, Adam
Cc: net-snmp-coders@...
Subject: Re: Question on SNMP version

2009/2/24 Bell, Adam <Adam.Bell@...>:
> 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.

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:Adam.Bell@...] 
Sent: Wednesday, February 25, 2009 12:26 PM
To: Dave Shield
Cc: net-snmp-coders@...
Subject: RE: Question on SNMP version

Thanks for the pointer,
will try it. 

-----Original Message-----
From: dave.shield@... [mailto:dave.shield@...] On Behalf Of Dave Shield
Sent: Wednesday, February 25, 2009 5:56 AM
To: Bell, Adam
Cc: net-snmp-coders@...
Subject: Re: Question on SNMP version

2009/2/24 Bell, Adam <Adam.Bell@...>:
> 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
Net-snmp-coders@...
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.

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:Adam.Bell@...] 
Sent: Friday, February 27, 2009 9:35 AM
To: Bell, Adam; Dave Shield
Cc: net-snmp-coders@...
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:Adam.Bell@...]
Sent: Wednesday, February 25, 2009 12:26 PM
To: Dave Shield
Cc: net-snmp-coders@...
Subject: RE: Question on SNMP version

Thanks for the pointer,
will try it. 

-----Original Message-----
From: dave.shield@... [mailto:dave.shield@...] On Behalf Of Dave Shield
Sent: Wednesday, February 25, 2009 5:56 AM
To: Bell, Adam
Cc: net-snmp-coders@...
Subject: Re: Question on SNMP version

2009/2/24 Bell, Adam <Adam.Bell@...>:
> 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
Net-snmp-coders@...
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.

2009/2/28 Bell, Adam <Adam.Bell@...>:
> I am running 5.2.4 and am having a problem indexing a table with fixed octet string indexes.

> 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.

<nods>
Yes - that makes sense.



> 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,

Nope.
Since most string indexes are variable length, this information
typically isn't available
when the table is registered.   The handling of fixed-length strings
is not identical to
that of IMPLIED variable-length strings.
   The Net-SNMP toolkit probably needs augmenting to distinguish between these
two types.



> 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?

No.
I believe this is a new problem, and has not been addressed in any current (or
development) code.   I've logged this is an issue in the project bug tracker.

Dave

OK

I try a few things and submit my solution when I have it working.

Thanks,
Adam


-----Original Message-----
From: dave.shield@... on behalf of Dave Shield
Sent: Mon 3/2/2009 3:48 AM
To: Bell, Adam
Cc: net-snmp-coders@...
Subject: Re: ASN_PRIV_IMPLIED_OCTET_STR (formerly SNMP verion...)
 
2009/2/28 Bell, Adam <Adam.Bell@...>:
> I am running 5.2.4 and am having a problem indexing a table with fixed octet string indexes.

> 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.

<nods>
Yes - that makes sense.



> 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,

Nope.
Since most string indexes are variable length, this information
typically isn't available
when the table is registered.   The handling of fixed-length strings
is not identical to
that of IMPLIED variable-length strings.
   The Net-SNMP toolkit probably needs augmenting to distinguish between these
two types.



> 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?

No.
I believe this is a new problem, and has not been addressed in any current (or
development) code.   I've logged this is an issue in the project bug tracker.

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.

Hi,

How can i use net-snmp for discovering nodes in a specific IP Range (Ex: 16.138.37.1 - 16.138.38.34), their status (UP/ DOWN) and MAC address of each discovered node?

If possible please paste the code snippet.

Thanks
Harish

2009/3/2 Bell, Adam <Adam.Bell@...>:
> I have a working implementation that fixes the multi-index fixed length
> OCTET STRING decoding.

Could you please post a diff of your changes, rather than the whole mib.c file.
It's very difficult to work out exactly what you are proposing, since I'm not
sure what your starting point was.



> 1. in mib.c - minor algorithm mods (attached), if the index has only 1
> field, then it works as it did before and takes the entire OID.

How does it cope with a multi-indexed table, where the last
index is IMPLIED?


> 2. In the table helper creation, I set the each index variable with the
> expected OID length, that info is used in the mib.c fix.

More generally, how does it distinguish between the following two cases:

       aTable ....
           INDEX  {   IMPLIED  varString }
and
       bTable ....
           INDEX  {   fixedString }
?

Dave

2009/3/3 Bell, Adam <Adam.Bell@...>:
>
> The new code does special handling for the ASN_PRIV_IMPLIED_OCTET_STRING
> when parsing through the index OID.
> IMPLIED would be handled as before (var->name_length == 0) but there was no
> IMPLIED case in the block I modified.
>
> I made no change for the implied OID case, but a similar solution would work
> I imagine.

Thanks for that patch.
However, it appears that a similar (though subtly different) patch has already
been applied to the 5.4.x line.

See
    http://net-snmp.svn.sourceforge.net/viewvc/net-snmp?view=rev&revision=14012

I'm not sure why this wasn't back ported to the 5.3.x and 5.2.x lines as well.

Dave

Good to know,

I thought this morning that a better init implmenetation would be

    netsnmp_table_helper_add_indexes(table_info,
                                     ASN_PRIV_IMPLIED_OCTET_STR,  LENGTH1,
                                     ASN_PRIV_IMPLIED_OCTET_STR,  LENGTH2,
                                     ASN_UNSIGNED,                
                                     0);

but have not looked deeper into this solution

Thanks for the help,
Adam



-----Original Message-----
From: dave.shield@... on behalf of Dave Shield
Sent: Tue 3/3/2009 9:32 AM
To: Bell, Adam
Cc: net-snmp-coders@...
Subject: Re: ASN_PRIV_IMPLIED_OCTET_STR (formerly SNMP verion...)
 
2009/3/3 Bell, Adam <Adam.Bell@...>:
>
> The new code does special handling for the ASN_PRIV_IMPLIED_OCTET_STRING
> when parsing through the index OID.
> IMPLIED would be handled as before (var->name_length == 0) but there was no
> IMPLIED case in the block I modified.
>
> I made no change for the implied OID case, but a similar solution would work
> I imagine.

Thanks for that patch.
However, it appears that a similar (though subtly different) patch has already
been applied to the 5.4.x line.

See
    http://net-snmp.svn.sourceforge.net/viewvc/net-snmp?view=rev&revision=14012

I'm not sure why this wasn't back ported to the 5.3.x and 5.2.x lines as well.

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.