On Tue, 17 Nov 2020 15:11:04 +0100 Simon Brown simon.brown@eiscat.se wrote:

I'm testing with two device types, an ordinary WLAN access point and a switch.

https://www.zyxel.com/products_services/802-11ac-Dual-Radio-Dual-optimized-A...

NAV does not have any specific support for WLAN access points, so there is no pre-existing framework to model that type of information in today's data model.

Normally, an AP will expose information about its ethernet ports using the standardised IF-MIB, which includes traffic counters and status of these ports. These might be its uplink port(s) and its "virtual" WLAN ports.

https://sevensols.es/index.php/index/timing-products/white-rabbit-switch/

Regarding basic information, I'm not really sure what to expect as I'm not that good yet at parsing MIB files. I don't know what is generic standard info and what is device specific. As a first step for the switch I see nothing in the Ports tab "No ports found" I was hoping for someway to setup VLANs.

The MIB file for the switch is here: https://ohwr.org/project/wr-switch-sw/blob/ 4df35933f51680e7497cb2b5b183905b374ed28e/userspace/snmpd/WR-SWITCH-MIB.txt

And it looks like individual port status is exposed, version information, temperatures and a host of other things. I don't know yet how much of this will be useful so I would like to make as much of it available as possible.

What is basic from your point of view?

To be blunt: I am asking "What do _you_ expect NAV to tell you about these devices that it isn't already telling you?"

If you have a network device, it will have the concept of network interfaces, whether they be physical or virtual. I expect to at least be able to see these interfaces listed in NAV - and there is only one definitive MIB to provide this information: IF-MIB (RFC 2863).

If you have an SNMP-enabled networking device and it does not support this MIB, it is useless for most network monitoring tools (maybe the vendor sells their own NMS and want to make money off of that?). Personally, I have never come across such a device before.

The MIB you pointed to seems to provide some proprietary information about ports, with an information model that seems to differ considerably from IF-MIB. I'm sure you can author support for this proprietary MIB and make some things work, but NAV's model for interfaces follows IF-MIB pretty closely, and I'm not sure how the concepts of WR-SWITCH-MIB will map into those.

These are the necessary steps I foresee:

1. Dump WR-SWITCH-MIB to a Python dictionary representation. 2. Write a MibRetriever to implement the abstractions necessary to fetch and make sense of the data in the MIB. As an example, here is the corresponding MibRetriever for the IF-MIB: [1].

These two steps more or less overlap with start of the howto for writing support for sensor equipment [2].

3. Write something that corresponds to the ipdevpoll interfaces plugin [3], which will use the abstractions provided by your MibRetriever implementation to fetch data from the device and map that data into NAV's interface model.

Worst-case scenario: You may want to store attributes that aren't part of NAV's standard interface model. Then you will need to propose changes to the generic model used by everyone, and that will take much longer to design and approve.

NB: I suggest moving this entire discussion to the nav-dev mailing list, rather than bother everyone on the users list with the low-level details. Cc: to nav-dev@uninett.no.

[1] https://github.com/Uninett/nav/blob/master/python/nav/mibs/if_mib.py [2] https://nav.uninett.no/doc/5.0/hacking/adding-environment-probe-support.html [3] https://github.com/Uninett/nav/blob/master/python/nav/ipdevpoll/plugins/inte...