Identical communities for read and write about pysnmp HOT 10 OPEN

You will have to show your code and reveal how you configured PySNMP.

You also need to show which OID you tried to SET.

from pysnmp.

The GET and SET works when the read community is set to 'read' and the write community is set to 'write' so this is a PySNMP internal problem. Looks like an issue with having both communities set to the same value.

from pysnmp.

Verbose debug of issue attached...

PySNMP GET and SET error with identical community names.txt

from pysnmp.

Like I commented earlier, you need to show your code. But anyway, the verbose log indicated the same,

2024-04-04 15:36:00,561 pysnmp: StatusInformation: {'errorIndication': NotInView()}
[D 240404 15:36:00 debug:53] StatusInformation: {'errorIndication': NotInView()}

that you didn't configure the view properly.

from pysnmp.

You can use the standard example 'multiple-snmp-communities.py' to replicate, just set the read and write communities to the same value.
The 'NotInView()' error is only generated when the communities are the same.

from pysnmp.

My team are the new maintainers of this project (read #429 for more), so we clearly know what you meant.

What we suggest is that you go through the documentation and sample code with more patience, because the MIB view related configuration is less known but critical in cases like this. You can refer to code like to see how a test SNMP agent should be configured (since you don't want to share your own code),

https://github.com/lextudio/pysnmp/blob/main/tests/agent_context.py#L57

from pysnmp.

I am using your sample code from here : examples/v3arch/asyncio/agent/cmdrsp/multiple-snmp-communities.py

It works when you use different community strings, as the example:

config.addV1System(snmpEngine, 'my-read-area', 'read')
config.addV1System(snmpEngine, 'my-write-area', 'write')

And fails when you make them the same:

config.addV1System(snmpEngine, 'my-read-area', 'same')
config.addV1System(snmpEngine, 'my-write-area', 'same')

I cannot do any other tests as this is as simple as you can get.

from pysnmp.

Those were the legacy samples written by Ilya and we don't really consider them extensive or up-to-date, compared to the unit test cases which are live and tested.

In the next few months we will revise the documentation on PySNMP.com further to eliminate the gaps.

from pysnmp.

Be they legacy examples or not the issue can still be demonstrated with your example code which was tested at some point in the past.
This is a problem with PySNMP so some constructive support would be welcome.

from pysnmp.

Only @etingof can confirm if those "were tested at some point in the past", but he won't be able to.

As new maintainers we clearly pointed out what you missed (even with line numbered code from live unit test case), and if that's not "constructive" I wonder what exactly you were looking for.

BTW, you keep refusing to show your code, and that actually blocked the discussion.

from pysnmp.