On 19 July 2012 15:55, <[email protected]> wrote:
> I am using VACM approach
> My snmpd.conf file without contextname
> createUser V3User MD5 "Password"
This really belongs in the /var/net-snmp/snmpd.conf file
> com2sec V3User default community
This is not relevant for SNMPv3
It's concerned with mapping from community strings to (internl)
security names - and hence only applies to SNMPv1/2c
> group v3_group usm V3User
> view v3_view included .1.3.6.1
> access v3_group "" any authNoPriv exact v3_view v3_view all
Those are the important bits.
> After reading the man page for snmpd.conf I modified the file as below
> createUser V3User MD5 "Password"
>
> com2sec –Cn context-name V3User default community
Not relevant (see above)
> group v3_group usm V3User
> view v3_view included .1.3.6.1
> access v3_group context-name any authNoPriv prefix v3_view v3_view all
Yes - that looks right.
The one thing that I'd suggest would be to have this
*as well* as the original access line - to allow the agent
to be queried without a context, as well as with it.
As it stands, the agent will *only* respond to requests
with this context - the default context is not authorised.
> proxy -Cn context-name -v 3 -u V3User -a md5 -A "Password" -l authnopriv
> localhost .1.3.6.1
Hmmm... you are taking any requests received for .1.3.6.1 (with the
specified context)
and passing them back to the same agent (but with the default (empty) context)
So it's the same agent answering with the same information.
The only difference is the lack of an explicit context.
Is that correct?
In which case, you almost certainly do need the access control settings
to allow requests with the default (empty) context.
Try with the two "access" lines.
> Now I modified the snmpd.conf file as above
> Now the application shows “ Timeout: No Response from 10.140.185.228.”
What *exactly* is the request that the application is sending?
Have you tried querying the agent using the Net-SNMP command-line tools?
That might be useful while you're trying to get things responding properly.
> The second line I think is SecEngineId Discovery.
Actually, I suspect the first packet is the engineID discovery,
and the second one is the request itself.
> The third line I believe it forwards the packet to itself and may be drops
> it inside.
Yes - that looks like the proxy forwarding the request to itself.
> If I remove the proxy part from snmpd.conf, this third line won’t be
> printed. But same timeout will happen
It's very difficult to suggest what's happening, without knowing
the exact SNMP requests that are being sent.
Dave
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
