[tvancott42]

Monitoring - Cable Modem Stats

• Netgear CM1000 on firmware V7.01.01 - This firmware puts the DocsisStatus page behind the Netgear Genie sign-in form, not HTTP Basic, so every poll failed with "Could not reach" the modem. The Netgear / Nighthawk CM (HTTP) provider now signs in through that form and reads the status page. It needs the modem's username and password. (thanks @tweexter for the traces)

This ships in v2.11.1-preview1, and the CM1000 issue closes with that release.

How it works

• The Genie login joins the provider's existing fallback matrix. It runs only when credentials are set, and only after the Basic attempts fail. A modem that already works with Basic or with the CM2050V form login resolves the same way as before and never reaches it.
• The modem binds the session to the source IP and sets no cookie. While that session is live, a poll is one GET of the status page and does not sign in again.
• The sign-in uses the same lenient raw HTTP reader as the CM700 path, because the login's redirect response carries bytes that strict HTTP clients reject.
• Credentials go only to a Genie login form the modem serves. A modem without one moves on to the next attempt with nothing posted.
• When every attempt fails, the error shown now comes from the login for the configured page extension. Before, the CM2050V login's connection reset was shown on .asp models. A refused password on a Genie modem now reads as a sign-in failure.

Tests

Loopback fakes of the CM1000 V7.01.01, the CM2050V and a Basic-auth modem run the full attempt matrix:

• Genie sign-in, including the malformed redirect
• A cached combo with a live session (one request)
• An expired session, which signs in again with a fresh token
• Wrong password, and no credentials
• The CM2050V (default and .htm paths) and a Basic-auth modem resolve as before without any Genie request

Parser tests cover quoted and unquoted tokens and every form-action shape.