How to Monitor Home Fiber: ONT Signals, Optical Power, and Failover

You can monitor a home fiber connection well without touching the fiber plant. The useful customer-side signals are the optical network terminal's documented lights or approved status page, the Ethernet handoff, the router's WAN state and counters, repeated latency and loss measurements, power state, and a documented failover test. Together they can distinguish local power, Ethernet, router, DNS, upstream, and provider-access failures.

Direct answer: Observe the ONT only through labels, LEDs, the provider app, or a provider-approved interface. If that interface exposes receive optical power, record its dBm value and trend against the exact provider/model limits; do not apply a generic internet chart. Monitor the router and a wired client separately, protect the ONT and router power path, and test backup WAN plus failback from router controls. Do not open an ONT or fiber enclosure, disconnect or inspect optical connectors, replace provider optics, probe hidden management pages, or attach an unauthorized ONU/ONT, transceiver, splitter, tap, or meter.

The Safe Monitoring Baseline

• Start at the demarcation. Record the provider, service tier, ONT or gateway model, where power enters, which Ethernet port is the handoff, and which equipment the provider owns.
• Read, do not modify. Photograph normal ONT lights and record approved status fields. A model-specific provider guide is the authority for LED colors and labels.
• Measure in layers. Check local gateway reachability, a stable numeric internet target, DNS resolution, and one real application. One green ping is not an internet health certificate.
• Trend before alerting. Collect normal idle and busy-period behavior before setting thresholds. Alert on sustained deviation and user impact, not one slow response.
• Power the whole customer path. An energized router cannot use an unpowered external ONT. Include the required switch or access point only when it is part of the essential path.
• Test failover and recovery. A backup link is unfinished until DNS, IPv4, IPv6 where required, application sessions, metering, alerting, and return to fiber have been observed.

Documented fact: ONT indicators are not standardized as one consumer vocabulary. For example, AT&T's current support page documents different POWER/PON/ALARM/DATA and PWR/FAIL/LAN/NTWK patterns across ONT models, while Verizon documents a separate ONT power indicator. Read the guide for the installed model rather than assuming that every red, green, flashing, or dark light means the same thing.

TechGeeks recommendation: Keep a one-page baseline with a normal-light photo, approved status screenshot, router export date, WAN handoff description, monitor targets, UPS load, backup-WAN limits, ISP account contact, and ticket history. Store it somewhere reachable when the home network is down.

1. Power + ONTIs customer-premises optical equipment powered and registered?

2. Ethernet handoffIs the electrical link to the router up and error-free?

3. Router WANDoes the router have a usable session, route, DNS, and counters?

4. End-to-end pathDo numeric, DNS, and application tests agree?

5. Backup WANCan essential traffic fail over and return predictably?

ONT status evidence

Record model-specific LED state, uptime or registration state if approved, alarm text, power state, and the time. A normal PON indication narrows the problem but does not prove routing, DNS, or application health.

Optical power evidence

Use only an approved read-only value. Record receive power in dBm, the provider/model warning limits if shown, and change from the same baseline. A number without the access class and threshold source is incomplete.

Router evidence

Record WAN link, negotiated Ethernet rate, DHCP or PPP session, public or carrier-facing address, default route, DNS servers, uptime, CPU/load, and counter deltas. A reboot can reset counters.

Path evidence

Compare gateway, numeric internet, DNS, and application outcomes from a wired client. Keep target, interval, packet size, address family, VPN state, and time window consistent.

Failover evidence

Record detection time, route change, public address, DNS, IPv4/IPv6 behavior, metered use, session disruption, alert delivery, failback time, and the final preferred-WAN state.

Provider boundary: stop here

Do not open equipment, expose a connector, look into fiber, replace optics, clone an ONT identity, discover hidden credentials, or add optical hardware. Preserve observations and escalate through the provider.

The strongest diagnosis is agreement between independent layers, with timestamps that match the user's symptom and the provider ticket.

Map The Provider Boundary Before Monitoring

Fiber-to-the-home can arrive as a separate provider ONT with Ethernet to your router, an ONT integrated into a provider gateway, or another managed handoff. The customer-visible boundary therefore varies. Your service agreement, install record, equipment labels, and provider support documentation decide which cables and controls are customer-serviceable. A wall-mounted ONT can remain provider equipment even when it is inside your home; AT&T's return guidance, for example, tells customers not to remove or unplug wall-mounted fiber jacks or ONTs.

Observation	Safe customer action	What it can establish	What it cannot establish
ONT or gateway LEDs	Read labels; compare with the exact provider guide; take a timestamped photo	Power, registration, alarm, or Ethernet state as documented for that model	Every provider-side condition or application health
Provider app or approved portal	Save sanitized status, outage, and diagnostic results	What the provider exposes for the account and device	Hidden OLT state, physical fault location, or an independent measurement
Ethernet handoff	Read link speed and counters at your router; replace only the customer-serviceable Ethernet patch lead if permitted	Electrical link and local error trend	Optical health beyond the ONT
Approved optical reading	Record the displayed dBm value and documented limits without changing settings	Reported receive power at that device and time	Connector cleanliness, exact loss location, or every PON impairment
Router and wired-client tests	Measure gateway, numeric internet, DNS, and an application separately	Which customer-visible layer first shows failure	Provider root cause from one target or one test

Hard stop: If the safe workflow reaches an optical connector, sealed enclosure, provider-only login, undocumented API, serial console, replacement optic, or added optical device, stop. Monitoring does not create authorization. Report visible damage, construction, an exposed enclosure, persistent optical alarm, or out-of-range approved telemetry without touching the plant.

Build A Normal-State Record

A baseline makes a later ticket more useful. Record it when service is normal, first at an idle time and again during a representative busy period. Use a wired client connected to the router or a managed switch for the primary baseline; Wi-Fi adds radio conditions that can obscure the fiber path. Keep a separate Wi-Fi measurement if the household experience also matters.

1. Record UTC time plus local time zone, service tier, ONT/gateway/router models, firmware shown in approved interfaces, topology, and whether IPv4, IPv6, VPN, or secure DNS is active.
2. Photograph normal ONT and power-supply lights without opening anything. Save the provider page that defines those lights.
3. From the router, record WAN link state and rate, session/lease state, address, gateway, resolver addresses, uptime, reboot reason if shown, and interface error/discard counters.
4. Measure the local default gateway, one stable numeric internet target, the configured DNS resolver, and one HTTPS service. Use the same targets for comparisons.
5. Collect small, periodic probes long enough to show normal variation. Run bulk speed tests manually and sparingly because active throughput tests consume available bandwidth and can distort concurrent measurements.
6. Record UPS input state, load in watts if available, battery charge, estimated runtime, battery age, and which exact devices use battery-backed outlets.
7. Document the backup link's carrier, data allowance, expected address/NAT behavior, power source, monitor target, and manual recovery path.

The Broadband Forum's TR-143 measurement model separates test endpoints and warns that multiple active tests can consume capacity and skew results. The FCC's fixed-broadband methodology similarly used dedicated customer-premises measurement devices and defined the measured segment. The practical lesson is to name the source, destination, protocol, timing, and load state for every number.

Read ONT Status Without Managing The ONT

Treat the ONT as a provider-managed boundary device unless the provider explicitly documents otherwise. The high-value observations are simple: power present, normal network/PON registration indication, no model-defined alarm, and an active Ethernet/data handoff. If the provider app reports an outage or runs an approved line test, save its exact wording and time.

Do not turn LED names into universal protocol states. On one documented AT&T ONT, a solid PON light indicates connection to the provider network; on another, NTWK and MGMT indicators carry related information. Other providers and models differ. An ONT can also be registered while internet traffic fails later at IP assignment, routing, DNS, peering, or an application.

Power deserves its own check. Verizon states that its ONT needs premises electricity for Fios services. Its consumer battery guidance also notes that some provider battery options preserve basic voice but not internet or television. Do not infer data-service runtime from a battery icon or voice-backup specification. Verify what your exact power arrangement supports.

Interpret Optical Power Only When It Is Exposed

Documented fact: dBm expresses power relative to one milliwatt on a logarithmic scale. A more negative receive-power value represents less received power: for example, -25 dBm is lower power than -20 dBm. That relationship does not make either number good or bad for a particular service.

The applicable limits depend on the access system, optical distribution network class, receiver, provider design, and alarm policy. ITU-T G.984.2 contains different GPON sensitivity and overload values for different classes and directions. Other PON generations have their own specifications. A generic "healthy fiber is between X and Y dBm" graphic strips away the information needed to interpret the reading.

TechGeeks recommendation: Prefer the approved interface's own high/low warning state or the provider's limit for the exact ONT and access profile. Keep three fields together: current receive power, documented warning/alarm boundaries, and change from a known-good baseline. Preserve the displayed precision, but do not assume that extra decimal places mean the sensor is equally accurate.

Pattern	Careful interpretation	Next safe step
Stable reading, normal provider status, clean Ethernet and path tests	Useful baseline for this device and interface	Retain it; do not "improve" a working optical path
Reading moves lower and latency/loss or ONT alarms begin at the same time	Correlated evidence of an access-side change, not proof of its physical location	Save timestamps and escalate to the ISP
Reading is outside a provider/model warning boundary but service appears normal	Possible reduced margin, sensor/reporting issue, or provider policy concern	Open a non-emergency ticket with the exact value and source
Optical reading looks normal but Ethernet handoff flaps or errors rise	The visible problem may be at the ONT Ethernet port, patch cable, router port, power, or reporting layer	Compare both Ethernet ends and use only permitted copper substitution
No optical reading is exposed	The customer does not have this measurement	Use LEDs, approved diagnostics, router evidence, and provider support; do not manufacture access

Optical power is not latency, throughput, bit-error rate, registration state, or internet reachability. It can remain steady during an upstream routing outage. It can also change without proving whether a bend, splice, splitter, connector, transmitter, receiver, sensor, or maintenance event caused the change. Customer telemetry is evidence for escalation, not permission to locate the optical fault physically.

Use Router Telemetry To Separate The Handoff From The Internet

The router is the most useful customer-controlled observation point because it sees the ONT's Ethernet handoff and the IP service above it. Record both physical and logical state. Physical state includes link up/down, negotiated rate, duplex if exposed, and error/discard deltas. Logical state includes DHCP or PPP status, lease/session age, WAN address, default route, DNS servers, and IPv4/IPv6 state.

Interface counters need context. RFC 2863 defines common operational state and traffic/error/discard counters, but a counter total without uptime and sampling interval is weak evidence. A reboot, interface recreation, or counter rollover can break the series. Save the starting and ending values, timestamps, router uptime, and whether the interface flapped.

• Link down at the router: Check customer-accessible power and the permitted Ethernet patch path. Do not move to the fiber connector.
• Link up, no WAN address or session: Save the DHCP/PPPoE error and lease/session history before rebooting. This is stronger ISP evidence than "Wi-Fi has no internet."
• WAN up, errors rising: Compare router port counters, ONT data light, negotiated rate, and a known-good customer Ethernet lead if the provider boundary permits replacement.
• WAN up, no DNS: Test a numeric destination and query the configured resolver separately. DNS failure is not the same as optical failure.
• Router resources saturated: High CPU, exhausted sessions, thermal alarms, or queue drops can create latency even when the fiber access is healthy.

Use read-only telemetry and local management. If the router or managed switch supports SNMP, prefer authenticated and encrypted SNMPv3 with a restricted monitoring account and source address. Do not expose SNMP, the router UI, or an ONT page to the public internet for convenience.

Measure Latency And Loss In Layers

Round-trip delay is specific to a source, destination, path, packet pattern, and time. RFC 2681 formalizes that context; RFC 7680 does the same for loss. Your monitor should therefore store the target, address family, protocol, interval, timeout, packet size if configurable, source interface, VPN state, and timestamp. A daily average alone can hide a five-minute outage or busy-hour spike.

Test	Question answered	Failure meaning	Important limit
Local default gateway	Can the wired client reach the router?	Local client, Ethernet, switch, VLAN, or router issue	Does not cross the fiber service
Stable numeric internet target	Does IP traffic leave the home?	WAN, routing, upstream, or target-specific issue	The target or ICMP treatment can fail independently
Provider or chosen DNS resolver	Can the configured resolver answer?	Resolver, route, filtering, or DNS transport issue	Does not prove every domain or application
HTTPS transaction	Can DNS/TCP/TLS/HTTP complete for one service?	One or more application-path stages failed	One service and CDN path are not the whole internet
Manual idle and loaded comparison	Does delay/loss change when the link is busy?	Possible queueing, saturation, local workload, or provider congestion	A bulk test creates load and must be scheduled

Use at least two remote targets with different operational dependencies, but keep the target set small and respectful. Alert only after multiple failed probes or a sustained deviation suited to household needs. Router vendors may expose latency/loss thresholds for automatic gateway state; those are control inputs, not universal definitions of a bad fiber circuit.

ICMP also has evidence limits. Routers and destinations can filter or rate-limit echo and error responses. A silent intermediate traceroute hop followed by a healthy destination does not prove that hop is dropping transit traffic. Our Ping vs Tracert/Traceroute guide covers that interpretation in more detail. For escalation, prioritize repeated end-to-end impact that agrees with router counters, application behavior, and timestamps.

Put The Entire Essential Path On A UPS

For a separate ONT and router, both need backup power. Add a small switch or access point only if essential clients depend on it. Do not fill battery-backed outlets with nonessential servers, displays, printers, or entertainment gear when the goal is communications runtime. Label each plug so a future cleanup does not move the ONT to a surge-only outlet.

UPS runtime is load- and model-specific. Schneider Electric's UPS guidance recommends sizing from the connected load and checking the selected unit's runtime curve; its documentation also notes that estimated runtime varies with load, charge, and battery age. Measure the actual network load if the UPS exposes it and test under a maintenance window. Do not promise a runtime from volt-ampere branding alone.

• Verify ONT, router, and required switch/AP remain powered when the UPS transfers to battery.
• Confirm internet data continues; a provider voice-backup battery may not support internet service.
• Send on-battery, low-battery, battery-replace, and communication-lost alerts through a route that can survive the event.
• If using USB or network telemetry, confirm the exact UPS is supported. Network UPS Tools can expose status and coordinate shutdown, but a network-only load may be better served by alerting and controlled endurance than by an immediate shutdown.
• Record what happens when premises power returns: UPS online state, ONT registration, router WAN renewal, DNS, Wi-Fi, and preferred-WAN recovery.

A customer UPS cannot prove the provider's splitter, cabinet, remote electronics, or central-office path will remain available. Passive outside plant does not need local power, but other provider components and upstream facilities may. Treat continued fiber service during a neighborhood outage as a tested observation, not a guarantee.

Design Failover Around Usability, Not Link State

A router can have Ethernet carrier to the ONT while the internet beyond it is unusable. Failover health checks should therefore test a target beyond a local fiber CPE address. Netgate's current documentation makes this distinction explicitly: monitoring only a local fiber CPE or modem can leave the gateway marked up during an upstream failure, while an external monitor address can represent internet usability more accurately.

Do not depend on one monitor target. If one service blocks or rate-limits probes, the router can abandon a healthy fiber link. Use the failover platform's documented multi-target or policy options where available, conservative failure/recovery timing, and alerting that identifies which check changed state. Avoid aggressive flapping between WANs.

Failover question	Evidence to retain	Common surprise
Did the router detect an unusable fiber path?	Monitor targets, failure reason, first failed probe, declared-down time	Local gateway still responds during upstream outage
Did essential traffic move?	Route/gateway status, public address, DNS result, HTTPS test	Router-originated or policy-routed traffic stays on the failed WAN
Did existing sessions survive?	VPN, voice, meeting, stream, and remote-access outcomes	Public IP/NAT changes break sessions even when new connections work
Did both address families work?	Separate IPv4 and IPv6 tests and routes	IPv4 fails over while IPv6 remains broken or leaks to the old path
Was backup use controlled?	Bytes transferred, data-cap alert, update/backup pause state	Cloud backup or OS updates consume a metered plan
Did fiber recover cleanly?	Stable-up time, failback event, session impact, final preferred route	Repeated failback causes more disruption than staying on backup

A safe failover drill

1. Export the router configuration. Record current routes, DNS, WAN states, monitor targets, data-cap controls, and a manual way to reach the router.
2. Start continuous low-rate checks from one wired client: gateway, numeric internet, DNS, HTTPS, and any essential VPN or remote-access path.
3. Use the router's documented control to disable the primary WAN or force the test policy. Do not disconnect fiber, power-cycle the ONT, or alter provider equipment.
4. Record detection time, new public address, IPv4/IPv6, DNS, session impact, alert delivery, and backup data use.
5. Re-enable the primary WAN. Require a stable recovery interval, then record failback, session disruption, routes, and the final fiber-preferred state.
6. If behavior is ambiguous or unstable, restore the prior configuration and leave failover manual until the monitoring policy is understood.

Recovery warning: Automatic state clearing can help new sessions move but can also terminate working sessions. Product defaults and controls differ. Test the exact router release and traffic policy; do not copy a state-kill or failback setting from another platform.

Triage By The First Layer That Fails

Symptom	Evidence pattern	First action	Avoid
Everything dark	ONT/power supply and router have no power	Check the permitted outlet, UPS state, breaker, and power cords; preserve UPS event time	Opening ONT or assuming an optical outage
ONT alarm or no network/PON registration	Power normal; model-defined provider light abnormal	Check provider outage status and open a ticket with model, lights, and timestamp	Reseating fiber or attaching a meter
ONT looks normal, router WAN link down	Provider status normal; Ethernet carrier absent	Check permitted copper connections, router port, and power; compare a known-good customer Ethernet lead if allowed	Changing optical equipment
WAN link up, no address/session	Ethernet normal; DHCP/PPP repeatedly fails	Save logs, lease/session state, and outage status; escalate before broad resets	Factory-resetting the router or ONT without a recovery plan
Numeric target works, names fail	Gateway and internet IP reachable; DNS query fails	Check resolver addresses and DNS path from the same client	Calling it weak optical power
Latency/loss rises only under load	Idle path normal; busy-period delay rises; counters/load may show saturation	Identify upload/download source, router queueing, and whether backup or provider link is constrained	Running more simultaneous speed tests
Fiber fails, backup does not take over	Primary monitor remains up, backup unready, or policy misses traffic	Use manual backup, save gateway/policy logs, then restore the last known configuration	Changing targets, routes, DNS, and firewall together
Service returns but keeps flapping	Alternating WAN state, lease changes, ONT alarms, or unstable power	Hold the stable path manually, preserve event sequence, and escalate	Repeated reboots that erase the timeline

Escalate With A Provider-Ready Evidence Package

Start with the provider's outage page and support channel. State the user impact and the first failing layer, not a guessed root cause. A concise ticket is easier to route than a dashboard dump.

• Account/service location and callback information, shared only through the provider's protected channel.
• Incident start/end in UTC and local time, recurrence pattern, weather or nearby construction observed from a safe distance, and affected internet/voice/TV services.
• ONT/gateway model and documented LED state; approved optical value and provider/model limits only if exposed.
• Router WAN link/session/address state, uptime, event log, and error/discard counter deltas.
• Wired gateway, numeric internet, DNS, and HTTPS results using named targets and address families.
• Whether backup WAN worked, public address changed, and the fiber failback result.
• Steps already taken and explicit confirmation that no fiber, provider optics, hidden management, or unauthorized equipment was touched.

Ask for a ticket number, the next diagnostic owner, and what evidence the provider needs next. If frontline support asks for a reset, ask what settings, logs, voice service, or activation state it may affect and how recovery works. Do not factory-reset provider equipment merely to clear a script step when the current state is valuable.

For unresolved U.S. equipment, speed, latency, or service issues, the FCC Consumer Complaint Center describes the informal internet-complaint process. Contact the provider first and keep ticket history. Outside the United States, use the applicable telecom regulator or consumer process. A measurement package supports investigation; it does not itself establish breach of contract or provider liability.

Recovery After Fiber Service Returns

1. Confirm premises power and UPS state are stable. Do not start with repeated ONT reboots.
2. Confirm the model-defined normal ONT indicators or approved portal state.
3. Verify Ethernet handoff rate and that error counters are not rising.
4. Verify WAN address/session, default route, DNS, and both IPv4 and IPv6 if used.
5. Repeat gateway, numeric internet, DNS, HTTPS, and essential application checks from a wired client.
6. Verify the router returned to the intended fiber route and that the metered backup is idle.
7. Check VPNs, remote access, dynamic DNS, voice, cameras, and long-lived sessions that may retain the backup address or stale DNS.
8. Export post-recovery logs and update the baseline only when the new state is understood and stable.

Rollback is appropriate when new monitoring or failover settings create route flaps, DNS inconsistency, missing IPv6, excessive mobile data use, unreachable administration, or unexplained session termination. Restore the saved router configuration or disable only the new policy. Keep the known-good manual backup path until post-recovery checks pass.

How To Verify This Runbook

Documentation-backed facts: The ONT-light examples, premises-power dependency, provider battery limitation, dBm definition, PON class-dependent optical limits, interface-counter semantics, latency/loss context, active-test load warning, UPS runtime dependencies, and gateway-monitor behavior come from the official provider, standards, government, project, and vendor sources below.

Unperformed lab work: TechGeeks did not access a reader's ONT, read optical power, collect a week of latency/loss, transfer a UPS to battery, interrupt a WAN, consume a cellular plan, or observe failover/failback for this draft. The baseline and drills above are proposed reader procedures, not reported TechGeeks measurements. No screenshot or number in this article represents a tested home fiber deployment.

• Verify every ONT indicator against the installed model's current provider page.
• Verify any optical value has a named interface, direction, unit, model/profile limit, timestamp, and known-good baseline.
• Verify monitoring retains raw samples or event logs, not only a rounded dashboard average.
• Verify alerts fire and clear for a safe router-controlled test without touching fiber.
• Verify UPS transfer and restoration during a maintenance window with the exact network load.
• Verify failover and failback for DNS, IPv4, IPv6, essential applications, alerts, and metering.
• Verify config exports and incident notes are reachable when the router and primary WAN are unavailable.

What The Evidence Does Not Prove

• A normal ONT light does not prove IP assignment, DNS, internet routing, application health, or absence of intermittent optical errors.
• An approved optical-power reading does not locate a fault, validate connector cleanliness, reveal total margin, or prove the provider's transmitter, splitter, and OLT are healthy.
• A successful ping does not prove DNS, TCP, TLS, HTTP, VPN, voice, or real user workflows; a failed ping does not prove the path is down.
• Loss to one monitor target does not prove ISP loss because the destination or an intermediate device may treat probes differently.
• A wired baseline does not describe Wi-Fi quality; a Wi-Fi test cannot isolate the fiber service without radio context.
• A speed test does not prove sustained capacity, low loaded latency, or performance to every destination, and it can disturb the link it measures.
• A UPS runtime estimate does not prove actual outage endurance or provider-side power continuity.
• Successful backup-WAN connection does not prove existing sessions survive, both address families work, data caps are controlled, or failback is stable.
• Customer measurements can show correlated symptoms and narrow fault domains; they cannot by themselves establish an ISP's contractual fault or legal responsibility.

Useful Gear And Buyer Notes

Buy only against a measured gap. For a UPS, verify watt capacity, runtime curve at the actual load, battery replacement path, transfer behavior, and supported USB/network telemetry. For a failover or travel router, verify current firmware, WAN health checks, Ethernet and permitted tethering/modem support, IPv6 policy, data controls, config export, and failback behavior. For Ethernet monitoring, verify managed-port counters and secure read-only access. None of these purchases should connect to the provider's optical interface.

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

• Amazon search: UPS with USB monitoring for router and ONT
• Amazon search: dual-WAN travel router with USB tethering
• Amazon search: managed Ethernet switch with SNMP

Related TechGeeks Reading

• What Should You Monitor in a Homelab?
• Ping vs Tracert/Traceroute: Reachability vs Path Troubleshooting
• What Should Happen to Your Homelab During a Power Outage?
• UPS Buying Guide for Home Servers: Runtime Is Not the Main Point
• The 2026 Travel Router Kit
• Fiber Optic Cables Explained

Publication-Day Rechecks

• Reopen the AT&T and Verizon ONT/power pages and confirm that model light meanings and internet-versus-voice backup statements remain current.
• Confirm the cited ITU GPON recommendation and optical class tables are still in force or replace them with the current revision without turning class values into universal customer thresholds.
• Recheck Netgate gateway-monitor and recovery behavior, especially monitor-target and state-handling language.
• Recheck Schneider Electric UPS sizing/runtime guidance and Network UPS Tools documentation; do not add model-specific compatibility without verifying the current list.
• Reopen the FCC measurement and complaint pages, validate all external references, and confirm every TechGeeks related-reading URL resolves.
• Inspect the interactive model on desktop and mobile WordPress previews, including open details, wrapping, contrast, and overflow.
• Confirm the draft still contains no H1, JavaScript, downloadable quick card, optical intervention step, hidden-interface instruction, or unlabelled original measurement.

References

• ITU-T G.984.2: GPON physical media dependent layer
• NIST Technical Note 1850: Logarithmic power and dBm
• AT&T: Optical Network Terminal status lights
• AT&T: Equipment return and wall-mounted ONT guidance
• Verizon: Optical Network Terminal power
• Verizon: Battery backup information
• IETF RFC 2863: Interfaces Group MIB
• IETF RFC 3414: SNMPv3 User-based Security Model
• IETF RFC 2681: Round-trip delay metric
• IETF RFC 7680: One-way loss metric
• IETF RFC 1812: Requirements for IPv4 routers
• Broadband Forum TR-143 Issue 1 Amendment 1 Corrigendum 2: Throughput tests and statistical monitoring
• FCC: Technical Appendix to the Ninth Measuring Broadband America report
• Netgate: Gateway monitoring settings
• Netgate: Multi-WAN troubleshooting
• Schneider Electric: UPS sizing and load considerations
• Network UPS Tools: upsmon documentation
• FCC: Internet complaint issue descriptions