Open mtadeu opened 1 year ago
Hi @mtadeu , there is currently no way to configure a plugin exemption for a specific device, and it might be better to just make a proper workaround for a buggy response (the code is fine with no response, but doesn't always handle buggy responses well).
Thanks for the traceback log and SNMP output! According to the traceback you are likely looking at the wrong SNMP traffic, though.
The buggy response seems to come when querying either the dot1qVlanCurrentEgressPorts
or dot1qVlanCurrentUntaggedPorts
objects (both in the dot1qVlanCurrentTable
from RFC 4363).
The dot1qVlanCurrentTable
should have a two-value index (dot1qVlanTimeMark
, dot1qVlanIndex
), but the error message from you log excerpt seems to indicate that the device responds with values that have only a single value index. What does it look like when you do an snmpwalk of dot1qVlanCurrentTable
?
That's the problem: dot1qVlanCurrentTable: Unknown Object Identifier (Sub-id not found: (top) -> dot1qVlanCurrentTable)
There are Proprietary MIB. Maybe can help us. G5328P-MIB.zip
snmpwalk full: snmpwalk-tenda.zip
That's the problem: dot1qVlanCurrentTable: Unknown Object Identifier (Sub-id not found: (top) -> dot1qVlanCurrentTable)
This message isn't a statement about your switch. This error just means that the snmp command on your system could not locate a MIB file that defined an object named dot1qVlanCurrentTable
, so the snmp command did not know what kind of query to send to the switch. You need to have the MIB definition files available on your system for the snmp command line programs to be able to look up things based on names.
snmpwalk full: snmpwalk-tenda.zip
Now that was more helpful, and served to confirm my suspicion that your switch has a buggy implementation of RFC 4363. These are the salient lines from your log:
iso.3.6.1.2.1.17.7.1.4.2.1.1.1 = Gauge32: 0
iso.3.6.1.2.1.17.7.1.4.2.1.2.1 = Gauge32: 1
iso.3.6.1.2.1.17.7.1.4.2.1.3.1 = Gauge32: 1
iso.3.6.1.2.1.17.7.1.4.2.1.4.1 = Hex-STRING: FF FF FF F0
iso.3.6.1.2.1.17.7.1.4.2.1.5.1 = Hex-STRING: FF FF FF F0
iso.3.6.1.2.1.17.7.1.4.2.1.6.1 = INTEGER: 2
iso.3.6.1.2.1.17.7.1.4.2.1.7.1 = Timeticks: (0) 0:00:00.00
These responses represent the 7 columns of the dot1qVlanCurrentTable
(aka. dot1qVlanTimeMark
, dot1qVlanIndex
, dot1qVlanFdbId
, dot1qVlanCurrentEgressPorts
, dot1qVlanCurrentUntaggedPorts
, dot1qVlanStatus
, and dot1qVlanCreationTime
).
However, the output clearly shows that one index element is missing from this response. The dot1qVlanTimeMark
value should be the first element of the index, while dot1qVlanIndex
should be the second. It seems the dot1qVlanTimeMark
is missing from your switch's response. The correct output should look like this:
iso.3.6.1.2.1.17.7.1.4.2.1.1.0.1 = Gauge32: 0
iso.3.6.1.2.1.17.7.1.4.2.1.2.0.1 = Gauge32: 1
iso.3.6.1.2.1.17.7.1.4.2.1.3.0.1 = Gauge32: 1
iso.3.6.1.2.1.17.7.1.4.2.1.4.0.1 = Hex-STRING: FF FF FF F0
iso.3.6.1.2.1.17.7.1.4.2.1.5.0.1 = Hex-STRING: FF FF FF F0
iso.3.6.1.2.1.17.7.1.4.2.1.6.0.1 = INTEGER: 2
iso.3.6.1.2.1.17.7.1.4.2.1.7.0.1 = Timeticks: (0) 0:00:00.00
We could potentially make a workaround in NAV that ignores a broken index and assumes that the missing bit is the dot1qVlanTimeMark
(which I don't think NAV uses for anything, anyway). This heuristic would break down horribly if a device comes along that instead dropped the dot1qVlanIndex
value in favor of the former ;-)
In any case, you should really file a bug report with TENDA for this buggy behavior.
@mtadeu if you can't spot the error, note that there are 14 "columns" in your log and there should be 15. Before that last column before the equals sign there is a missing column of 0's.
These switch have an workarounded access MIB !!!! It modify the output on dot1qVlanCurrentEntry See walk: tenda.dot1qVlanCurrentEntry.zip
The inventory run ok. But I got error on topo:
2023-05-08 17:50:56,697 [ERROR jobs.jobhandler] [topo 192.168.0.2] Caught exception during save. Last manager = CamManager(<class 'nav.ipdevpoll.shadows.cam.Cam'>, 'ContainerRepository'(...)). Last model = <class 'nav.ipdevpoll.shadows.cam.Cam'> Traceback (most recent call last): File "/opt/venvs/nav/lib/python3.7/site-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type macaddr: "8a:e1:dc:41:5c" LINE 1: ...05-08T17:50:56.696643'::timestamp, 'infinity', 0, '8a:e1:dc:...
2023-05-08 17:50:56,702 [ERROR jobs.jobhandler] [topo 192.168.0.2] Job 'topo' for 192.168.0.2 aborted: Job aborted due to save failure (cause=DataError('invalid input syntax for type macaddr: "8a:e1:dc:41:5c"\nLINE 1: ...05-08T17:50:56.696643\'::timestamp, \'infinity\', 0, \'8a:e1:dc:...\n ^\n'))
We could potentially make a workaround in NAV that ignores a broken index and assumes that the missing bit is the
dot1qVlanTimeMark
(which I don't think NAV uses for anything, anyway). This heuristic would break down horribly if a device comes along that instead dropped thedot1qVlanIndex
value in favor of the former ;-)
Maybe do it only if type is .1.3.6.1.4.1.8072.3.2.10
In any case, you should really file a bug report with TENDA for this buggy behavior.
I open bug report on TENDA suport
HI,
Do you see that dot1qVlanCurrentTable can be accessed with other community? The tenda switch has an workaround !!!
But this cause other problem. See https://github.com/Uninett/nav/issues/2610#issuecomment-1539038475
Thanks for these great software!
NAV 5.6.1 On SW tenda TEG5328P Type: [.1.3.6.1.4.1.8072.3.2.10 (tenda@switch from netsnmp)
Additional context The last SNMP traffic:
I try remove juniperdot1q with
dot1q=
Error too Then, remove dot1q#dot1q=
Then, run without errorWorkaround: How can I configure to do not use dot1q on switchs that type ?
TIA