Missing support for SNMPv3 contexts, breaks dot1dTpFdbTable collection

[HON95]

Reported on behalf of NTNU.

We switched to SNMPv3 to use views to limit what NAV change (e.g. so users don't accidentally change the access VLANs for our zero-trust networks, but can still change the interface descriptions). We then noticed that users could no longer track MAC addresses for the network (using the Machine Tracker feature). We've narrowed the problem down to SNMPv3 support in NAV and verified that it works as intended when changing the management profile to SNMPv2 (MAC finally addresses appearing in Machine Tracker).

We've verified that the switches are configured correctly and return the MAC tables from the following commands:

• SNMPv2 (VLAN 1030): snmpwalk -v2c -c community@1030 sand-100av-sw BRIDGE-MIB::dot1dTpFdbTable
• SNMPv3 (VLAN 1030): snmpwalk -v3 -l authpriv -u nav -a SHA -A auth_pw -x AES -X priv_pw -n vlan-1030 sand-100av-sw BRIDGE-MIB::dot1dTpFdbTable

Looking at pynetsnmp.py, we can see that the wrapper doesn't take SNMPv3 contexts into account (using the -n parameter).

This seems to be related to the "Research how SNMPv3 contexts affect ipdevpoll's BRIDGE-MIB handling code for Cisco equipment" part in #1177.

[lunkwill42]

This seems to be related to the "Research how SNMPv3 contexts affect ipdevpoll's BRIDGE-MIB handling code for Cisco equipment" part in #1177.

You are indeed correct. This is not yet implemented, and we know it. Which is why this issue is tracked as "not done" in #1177, and why the SeedDB SNMPv3 profile forms still warn that SNMPv3 support is not fully complete yet.

The tracked issue in #1117 has been created as #2811

[lunkwill42]

This is a known issue, tracked by #2811, so closing this a duplicate