> Do you know what's the meaning of "No more variables left in this MIB View"
> Could it be the "access control" prohibiting the access to my private mib
> tree? Or the registration and binding of my mib tree is actually failed?
Those are the two most likely causes.
It basically means:
"there's no information that comes later than the OID you asked for"
This could be because there's no information at all, or there is some
information but you're not allowed to know about it. From your point
of view, the two look identical.
What happens if you try a getnext request on something like "ip" ?
If you get another "end of MIB View" error, then that's almost certainly
down to access control.
> Do you know a way to trace/decode he dump code from the snmpd? I ran
> agent with the command line provided in the checklist such as -
> "agent/snmpd -f -L -d -p 9999".
You could try '-Ddump' instead of '-d', but the purpose of that
suggestion was really just to see whether you get request-response
exchanges, or just a series of requests (with no returned packets).
I doubt whether dumping the contents of the packets is likely to
be very helpful.
> The following is the snmpd.conf I tried to play around.
>
> ###################################
> com2sec local localhost private
> com2sec mytopmib 192.168.75.0/24 public <== for testing
> com2sec mytopmib 192.168.8.0/24 public <== for testing
> #com2sec mytopmib 192.168.0.0/16 public
> com2sec public default public
I would *VERY* strongly suggest that you don't use the same community
string for several "com2sec" entries. You really need to be familiar
with the details of the access control implementation to be sure of
which combinations work as expected.
It would be much safer to configure separate community strings for
your two testing networks - mapping both of them into the same
security name is fine, but start with different communities.
Even better, start with a more open setting such as
rocommunity mytesting
to allow access to the *whole* tree.
When you're sure that you can view your new module correctly,
*then* try tightening the restrictions to exclude external networks.
But to start with, make things as open as possible to make sure
that the basic module code works.
> group mytopmibgroup v1 mytopmib
> view genie included .iso.org.dod.internet.private.enterprises.mytopmib fc
> access geniegroup "" any noauth exact mib2 none none
> access geniegroup "" any noauth exact mytopmib none none
Errr... you seem to have that the wrong way round.
The name of the group is "mytopmibgroup", not "geniegroup"
and the name of the view is "genie" not "mytopmib"
That also won't help!
Dave
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
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
