get_lldp_neighbors() was never implemented, so the switch reported no
neighbours and NetOrk's network map had nothing to draw for the site it
serves — on the reference installation two APs, a firewall and a Proxmox host
behind a 1820 8G PoE+ (J9982A) all stood unconnected.
The web UI does carry the data. /htdocs/pages/switching/lldp_remote.lsp is
served with the rows embedded in the page's aDataSet, so the existing _rows()
helper reads it with no new plumbing:
['7', '3', '00:...:44', '00:...:46', 'enp3s0', 'host.example.com',
'bridge, WLAN access point, router, station only', 'bridge', '192.0.2.10']
Column 3 is the neighbour's port ID, which on many peers is a MAC, while
column 4 is its port description — a name a person can read. The description
wins, with the ID used only when it is missing. The chassis ID is passed
through as `mac` when it looks like one, since netOrk resolves a neighbour by
MAC before falling back to its name.
Fixture captured from the live switch and anonymised in the style of the
existing ones.
Closes#1
These switches have no CLI at all — no SSH, no Telnet and no ArubaOS-Switch
REST API — so the ProCurve driver cannot serve them despite the shared
vendor. The only management surface is the web UI, which ships its table
data as JavaScript array literals; those parse with ast.literal_eval, so
the driver needs no HTML parser and no dependency beyond napalm/requests.
Read-only by design: the platform exposes a single administrator account
with no privilege levels, and serves HTTPS only after a certificate has
been uploaded, so the polling credential is necessarily the admin
credential over a plain channel.
Implements get_facts, get_interfaces, get_vlans, get_vlans_detail and
get_mac_address_table, plus HTTP/SNMP fingerprints for discovery.
Tested against an HPE OfficeConnect 1820 8G PoE+ (65W), J9982A, PT.02.19.
Christian Manivong