Add Telekom Glasfaser-Modem 2 ONT provider

[Optic00]

Motivation

I run Network Optimizer on my own network (Telekom FTTH in Germany, UCG-Fiber). The ONT is Telekom's own "Glasfaser-Modem 2", which none of the existing ONT providers can talk to. This adds a provider for it, so its optical stats show up in ONT Device Monitoring like any other supported ONT.

What it does

New TelekomModem2OntProvider (ProviderKey: telekom-modem2), registered in DI and selectable in the Settings ONT dropdown.

• Polls /ONT/client/data/Status.json over plain HTTP - the same endpoint the device's own web UI uses for its Status view. No login or session is needed; the device serves this openly.
• Maps TX/RX power, BIP errors (rxbip_crc), link uptime (stability), serial number, and hardware revision. Up/Down is derived from hardware_state + ploam_success, following the semantics of the device's own status.js.
• Parsing is defensive: missing or malformed fields fall back to OntStats defaults instead of throwing.

One firmware quirk worth knowing about: the device rejects any request that has no Accept-Language header at all, with a malformed 400 response (a raw UNKNOWN 400 Bad Request status line that strict HTTP clients refuse to parse). The provider always sends Accept-Language: en. Confirmed against real hardware, and consistent with Netzwerkfehler/hass-GFM2, a working Home Assistant integration for this device, which sets exactly this header.

Testing

• Unit tests parse a fixture captured verbatim from a real device (serial scrambled), plus degraded-link, malformed-JSON, and header cases.
• Verified end-to-end on my live Glasfaser-Modem 2 behind the UCG-Fiber's WAN port: Test Connection returns real values (Connected (HTTP) - RX: -16.13 dBm, TX: 2.39 dBm), and polling has been running against the device.
• Full solution test suite is green.

Heads-up: on my network the ONT shares its management IP (192.168.100.1) with a Starlink dish on the other WAN, so reliably testing this provider needed the duplicate-IP alias support in #963. The two PRs are independent code-wise (both add one line to Program.cs, that's the only overlap).

Tooling disclosure

Per CODING_STANDARDS.md: this was built with heavy AI assistance (Claude Code - Sonnet/Opus/Fable - for implementation, GPT-5.5/Codex as an independent adversarial reviewer). Design decisions, every review round, and all live hardware verification were driven and checked by me. Happy to adjust anything that doesn't meet the bar.

🤖 Generated with Claude Code

[tvancott42]

Pulled in to the v2.0 beta. Available on v2.0.0-beta.5

[Optic00]

Usage note for anyone wiring this up on a UniFi PPPoE / Telekom FTTH WAN, since it tripped me up and isn't obvious from the PR itself.

Like the other ONT providers, this one only talks HTTP(S) to the configured host and parses the response - it does not set up any routing or firewall plumbing on its own. On a UniFi WAN running PPPoE (my Telekom FTTH setup), the GFM2's management IP 192.168.100.1 is typically not reachable from the gateway until you add an interface/route for it: the physical WAN port is consumed by the PPPoE session and carries no address in 192.168.100.0/24, so the poll just hits a timeout / no data.

The reachability piece is the existing Monitoring Interface feature (#833, here since v1.21.0). It puts a macvlan on the WAN parent - the physical port, or the configured VLAN subinterface, never the PPPoE interface itself - gives it an IP in the ONT subnet, adds a host route, and optionally SNATs so LAN clients can reach it too. So the full setup for a GFM2 is two steps:

1. Monitoring Interface on the WAN port: gateway-local IP e.g. 192.168.100.2/24, target 192.168.100.1, SNAT on, then deploy. On my GFM2 the management plane is untagged (VLAN 7 carries only the PPPoE Internet session), so leave the Monitoring Interface VLAN unset.
2. ONT provider (new in this PR): pick Telekom Modem 2, host 192.168.100.1.

Only step 2 is new here; step 1 has been around since v1.21.0. Might be worth a line in the docs / dropdown help so people don't select the provider and hit a timeout with no obvious cause.

(Unrelated aside: #963 is only needed for duplicate management IPs across WANs - e.g. an ONT and a Starlink dish both answering at 192.168.100.1 - not the common single-device case.)

[tvancott42]

This was merged outside of the PR, closing out