RE: I don't know why the table iterator works well on snmp v1 but it doesn't work on snmp v2c or v3!

First of all, thank you for your rapid reply, Dave.

> There are 3 tables in my MIB and I implemented the sub-agent to retrieve
> these tables through the table iterator helper. (mib2c.iterate.conf)
>
> When I get the table via snmp v1, it works well.
>
> But if I try to get those via snmp v2c or v3, the values of the first 2
> tables are destroyed and the last table is fine.

Hmmm...   that doesn't really make sense.

When you say the first two tables are "destroyed",
do you mean that the the contents are actually removed
  (i.e. a subsequent v1 walk also fails), or is it simply
that you can't see them using v2c or v3?

==> 
No, the contents is safe, 
but the result of the snmptable operation shows wrong value. 
They look like garbage. 

What are the access control settings in your snmpd.conf file?
==>
These are the part of the settings.
------------
com2sec private         localhost           private
...
group MyRWGroup v1         private
group MyRWGroup v2c        private
group MyRWGroup usm        private
...
view all    included  .1                               80
view  system   included    system
fe
...
access MyROSystem ""      any       noauth    exact  system none   none
access MyROGroup ""      any       noauth    exact  all    none   none
access MyRWGroup ""      any       noauth    exact  all    all    none
...
createUser jupiter MD5 "single pass phrase" AES
rwuser jupiter
rocommunity public
rwcommunity private
------------


> The followings are the result of snmptable operation via v1
> and the log from the sub-agent that I implemented.

I would suggest that you investigate this problem using a
simpler query.   Try

     snmpget  -v 1  .....   RADFINDER-MIB::rfcEngineAirIFType.1
     snmpget  -v 2c .....   RADFINDER-MIB::rfcEngineAirIFType.1

(ignore SNMPv3 for now - concentrate on why v1 works but v2c doesn't).

What results/debug output do you get?
==>
The results and debug output are...
----
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: RADFINDER-MIB::rfcEngineAirIFType.1
----
snmpd -f -Le
NET-SNMP version 5.4.2.1

[103] rfcEngineTable_get_first_data_point
[129] rfcEngineTable_get_next_data_point
[129] rfcEngineTable_get_next_data_point
[129] rfcEngineTable_get_next_data_point
----

> Why are get_first_data_point and get_next_data_point
> called so many times like this?

That's normal.
"snmptable" actually sends a sequence of GETNEXT requests,
one for each entry in the table.
For *each* GETNEXT request, the agent will call 'get_first_data_point'
(once)
followed by 'get_next_data_point' (once per row of the table)
   During a complete walk, this adds up to a large number of invocations.

==> 
When I compare the numbers of get_first_data_point called via v1 and
v2c/v3, in the v2c and v3 cases, they are exactly same. 
But the number of v1 case is smaller than v2 or v3 cases.
Is this also normal?
I think the reason why the result of snmptable shows the rubbish values may
be related to this...
I attached the full debug outputs from each cases to my first post.

Thank you very much for your help.

Catherine




------------------------------------------------------------------------------
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users