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
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
