On 31 March 2011 14:40, Boris Zweimueller <[email protected]> wrote:
> As I have an agent which only understands v2 with a specific community
> string I tried the following:
> (Just for testing proxy everything to the remote device)
>
> proxy -Cn context1 -v2c -c public remotehost .1.3
OK - so any request received by the proxying agent
with the context "context1" (either an explicit SNMPv3
context, or via an implicit community->context mapping)
will be passed on to 'remotehost'.
Note that the '-Cn' context here refers to the context
of the request *received* by the proxying agent.
It is not relevant to the request sent out *by* this
agent to the remote host.
> calling the remotehost directly with
>
> snmpget -v2c -c public remotehost sysContact.0
>
> works.
OK - that matches the settings in the "proxy" directive.
Things look good so far.
> without any setup of com2sec, as - how I understand it - this is not needed
> here.
The main purpose of 'com2sec' on the proxying agent (which I presume
is 'proxyhost'?), would be to set up the community->context mapping
mentioned above.
For example
com2sec -Cn context1 mySecName default community1
(plus corresponding "group", "view" and "access" entries)
would take any incoming request using the community name "community1"
and map this into the context "context1".
Hence (assuming that the access entries were configured correctly)
any such requests would be passed to the proxy module, and forwarded
to the remote host.
You could get much the same effect using
rocommunity community1 default .1 context1
which would also set up access for this context automatically?
> Howewer calling the proxy with
>
> snmpget -n context1 -v3 -u user proxyhost sysContact.0
>
> results in a timeout.
First of all - I assume that this SNMPv3 'user' has been set up
on proxyhost, and that the authentication (?and encryption)
settings are being set correctly.
The most likely cause of problems here would be access control.
Remember that if you are using a non-default context, then you
need an "access" line that will allow such requests to proceed.
This would typically take the form:
access {group} context1 any {level} exact {read} {write} {notify}
(to match *just* the context "context1"), or
access {group} "" any {level} prefix {read} {write} {notify}
(to match requests in *any* context).
The usual format
access {group} "" any {level} exact {read} {write} {notify}
will *only* match requests in the default context.
(that's the meaning of "exact" plus the empty string)
If things are still not working, then perhaps you should
post your full config file (suitably sanitised), so that we
can see exactly what you're working with
Dave
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
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
