HydraIssues

The network a client is connected to has real diagnostic value: at cloud-seven the WiFi name alone (FDG vs CS Op) separated the private residence Sonos from venue gear (#554), and the DHCP segment/SSID also narrows where a device physically is. Surface it end to end.

Scope

1. hydraneck model: network field (string, omitempty) on router.Client and store.UnmanagedClient: the best available human-meaningful name for what the client is connected to. Per backend:
   • MikroTik (REST + legacy): decode the DHCP lease server field (named DHCP server per segment; Citymesh names them per network).
   • GL.iNet: decode ssid/iface from clients.get_list (fields exist in the raw payload, we only read mac/ip/name/online/tx/rx today); prefer ssid, fall back to iface. Defensive decoding, firmware fields vary.
   • Omada: skip (decommission pending, #535).
2. hydraneck UI/API: Network column in the venue page Audio Devices and Unmanaged Devices tables; field flows through /api/v1/venues/{id}/network automatically.
3. hydravenues: carry network on neck clients; show it in the unmanaged device hints (class - network - room - model) and in the MAC-linked asset live section next to the IP.
4. Future backend (separate ticket when access exists): the true per-SSID and per-AP data at cloud-seven lives in the venue's UniFi CloudKey (11.0.0.101), Citymesh-managed. Read-only controller API access would give SSID + AP name per wireless client, which also enables rough physical placement (AP names are per-room). Ask alongside the #550 WG route conversation.

Acceptance

• cloud-seven scan shows a network name per unmanaged client (DHCP server name from the MikroTik) on the neck venue page and in hydravenues hints.
• sint-niklaas scan shows ssid/iface for the GL.iNet clients.
• No field renames; additive only.

UPDATE 2026-08-27: shipped and deployed

hydraneck v0.14.0 (via the built-in updater) and hydravenues v0.6.1 (scale rebuild). network now flows client -> scan -> /network API -> venue pages -> hydravenues hints and asset live info.

Verified live at cloud-seven: the MikroTik DHCP server name separates the segments exactly as hoped: the two venue Sonos Ports report DHCP_0001, the three private-residence players DHCP_0002 (91 clients across DHCP_0001/0002/0003/0103/0110).

Remaining in this issue:

1. Friendly names: MikroTik reports generic DHCP server names (DHCP_0001...). Add an optional per-venue networks: label map in hydraneck config (e.g. DHCP_0002: "FDG / private residence") applied at scan time, or ask Citymesh to name their DHCP servers.
2. GL.iNet verify: the ssid/iface decode is deployed but unverified; glinet-sintniklaas was unreachable at deploy time (tunnel down, see #533). Check the network values on the next successful sint-niklaas scan.
3. UniFi CloudKey backend for true SSID + per-AP data at cloud-seven: blocked on read-only controller access from Citymesh; raise with the #550 WG route conversation.

Classifier bug found 2026-09-10: 78:45:01 is Biamp, not Ubiquiti

The seed ouiTable maps 78:45:01 -> network/Ubiquiti; that was an unverified guess. Evidence it is BIAMP: two known Biamp devices at cloud-seven share it - the TEC-1 wall panel (78:45:01:10:66:43, TEC1-04796952) and the Tesira server main (78:45:01:09:68:a0, 11.0.0.201, confirmed by the owner on site). Fix: change 78:45:01 to av/Biamp in classify.go (supersedes the earlier plan to add a TEC1 hostname rule; the OUI catches TEC panels, Tesira servers and expanders alike). Verify against IEEE before shipping.