--===============0647622949==
Content-Type: multipart/alternative;
boundary="----=_Part_112114_20432710.1178888777837"

------=_Part_112114_20432710.1178888777837
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks a lot, Dave, for the reply

On 5/11/07, Dave Shield wrote:
>
> On 11/05/07, cpnr Reddy wrote:
> > Tables are registered as follows:
> >
> > 1.my_handler = netsnmp_create_handler_registration(buf,
> > my_table_handler,
> > my_table_oid,
> > table_oid_len,

>
> > HANDLER_CAN_RWRITE);
> > snmp_varlist_add_variable(&table_info->indexes,
> > table_oid, table_oid_len,
> > ASN_UNSIGNED, /* index:

> someTable */
> > (char * ) &index1, 4 );

>
> That looks unusual.
> I would expect this to be simply:
>
> netsnmp_table_helper_add_indexes(table_info, ASN_UNSIGNED, 0);



yes, simple. But we want to register for *selective interfaces *and not for
all.

And what is the value of 'table_oid'?


Examples says Tables should be register with up to Table OID, in this case
when we try with eg., RFC1213-MIB::ipRouteEntry; RFC1213-MIB::ipAddrEntry;
RFC1213-MIB::ifEntry, the SNMP-GET request works but only when snmpget is
given oid*s from *same table. when given OIDs from multiple tables the
variable from first different table netsnmp_extract_table_info() fails in
the handler.

> table_info->min_column = range_subid;
> > table_info->max_column = upperbound;
> >
> > netsnmp_register_table(my_handler, table_info)

>
>
>
>
> > Example for the above scenario is:
> >
> > The following example snmpget is quering one object from
> > "RFC1213-MIB:ifTable" and another from "RFC1213-MIB:ifRouteTable"
> >
> > snmpget -v3 -u tester -a MD5 -A user1 -l authNopriv localhost
> > 1.3.6.1.2.1.2.2.1.1.101 1.3.6.1.2.1.4.21.1.1.172.20.3.0

>
> And how does this relate to your registration code?
> Which table(s) are registered in this way, and which are handled by
> other MIB modules?
>
> BTW, we use 5.4 and have disable all standard mibs and the mibs mentioned
> above are to supported through a subagent.





> Case 2: When registered the tables with OID upto table position:
> >
> > The APIs are as above only, except for the table_oid_len in
> > netsnmp_create_handler_registration() which is less 1 than the above.


But you haven't said what the first registration OID was,
so that doesn't really help us.

The OIDs are standards RFC1213-MIB::ipAddrTable; RFC1213-MIB::ifTable;
RFC1213-MIB::ipRouteTable. The only problem is
if we follow as per document, we end up getting response, but handler itself
is not invoked. But if we register till *Entry we see it working unless get
is not mixed up. We would like to know if there is anything missed. I had a
look are the ifTable registration and there seems to some other handlers
registered. Is those needed?

BTW, as mentioned netsnmp_extract_table_info() fails for some of the
variables in request as request_info->parent_data is NULL.


If you are registering a table using one of the netsnmp_register_table*()
routines, then you must supply the OID of the 'xxxTable' MIB object - not
the 'xxxEntry' object or one of the column objects.

So for the two tables you mention above, the registrations should use
the OIDs .1.3.6.1.2.1.2.2 and .1.3.6.1.2.1.4.21 respectively.

Yes. But it doesn't even reach my handler. Is there anything missed out?

Thanks a lot
cpn Reddy


Dave

PS: Please do *not* send the same query to both mailing lists.
Choose one or the other. Thanks

------=_Part_112114_20432710.1178888777837
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks a lot, Dave,  for the reply


On 5/11/07, Dave Shield <.T.Shield@csc.liv.ac.uk">D.T.Shield@csc.liv.ac.uk> wrote:
On 11/05/07, cpnr Reddy <cpnrece@gmail.com> wrote:
> Tables are registered as follows:

>
>   1.my_handler = netsnmp_create_handler_registration(buf,
>                                                       my_table_handler,
>                                                       my_table_oid,

>                                                       table_oid_len,
>                                                       HANDLER_CAN_RWRITE);
>  snmp_varlist_add_variable(&table_info->indexes,

>                                    table_oid, table_oid_len,
>                                    ASN_UNSIGNED,         /* index: someTable */
>                                    (char * ) &index1, 4 );


That looks unusual.
I would expect this to be simply:

    netsnmp_table_helper_add_indexes(table_inf o, ASN_UNSIGNED, 0);

 

yes, simple. But we want to register for selective interfaces and not for all.


And what is the value of 'table_oid'?

 

Examples says Tables should be register with up to Table OID, in this case when we try with  eg., RFC1213-MIB::ipRouteEntry; RFC1213-MIB::ipAddrEntry; RFC1213-MIB::ifEntry, the SNMP-GET request works but only when snmpget is given oid
s from same table. when given OIDs from multiple tables  the variable from first different table netsnmp_extract_table_info() fails in the handler.


>        table_info->min_column = range_subid;
>        table_info->max_column = upperbound;

>
> netsnmp_register_table(my_handler, table_info)




> Example for the above scenario is:
>
>  The following example snmpget is quering  one object from
> "RFC1213-MIB:ifTable" and another from "RFC1213-MIB:ifRouteTable"

>
>  snmpget -v3 -u tester -a MD5 -A user1  -l authNopriv   localhost
> 1.3.6.1.2.1.2.2.1.1.101  1.3.6.1.2.1.4.21.1.1.172. 20.3.0

And how does this relate to your registration code?
Which table(s) are registered in this way, and which are handled by

other MIB modules?

BTW, we use 5.4 and have disable all standard mibs and the mibs mentioned above are to supported through a subagent.

 

 


> Case 2: When registered the tables with OID upto table position:
>
> The APIs are as above only, except for the table_oid_len in

> netsnmp_create_handler_registration() which is less 1 than the above.

But you haven't said what the first registration OID was,
so that doesn't really help us.

 

The OIDs are standards RFC1213-MIB::ipAddrTable; RFC1213-MIB::ifTable; RFC1213-MIB::ipRouteTable. The only problem is

if we follow as per document, we end up getting response, but handler itself is not invoked. But if we register till *Entry we see it working unless get is not mixed up. We would like to know if there is anything missed. I had a look are the ifTable registration and there seems to some other handlers registered. Is those needed?

 

BTW, as mentioned netsnmp_extract_table_info() fails for some of the variables in request as request_info->parent_data is NULL.



If you are registering a table using one of the netsnmp_register_table*()
routines, then you must supply the OID of the 'xxxTable' MIB object - not
the 'xxxEntry' object or one of the column objects.


So for the two tables you mention above, the registrations should use
the OIDs  .1.3.6.1.2.1.2.2   and  .1.3.6.1.2.1.4.21  respectively.

 

Yes. But it doesn't even reach my handler. Is there anything missed out?

 

Thanks a lot

cpn Reddy
 


Dave

PS: Please do *not* send the same query to both mailing lists.
      Choose one or the other.   Thanks
 



------=_Part_112114_20432710.1178888777837--


--===============0647622949==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--===============0647622949==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders

--===============0647622949==--