How to read the router architecture (fast path vs slow path)

A home gateway is best understood as a packet pipeline. Most traffic should stay on a fast path where the SoC’s NPU/flow engine uses cached flow entries and tables to forward packets at high pps with low CPU. Traffic falls back to a slow path when it misses flow tables or triggers features that cannot be fully offloaded.

• Fast path (offload): flow lookup → NPU forwarding → egress shaping (limited) → LAN/Wi-Fi.
• Slow path (CPU): Linux stack processing → complex policies → flow learning (if possible) → forwarding.

Common SoC partitions (what each block consumes and what it breaks)

Control plane

• CPU cores + OS: runs routing stack, management UI, policy orchestration. Failure pattern: CPU saturation causes high latency, UI stalls, or timeouts under many short flows.

Data plane

• NPU / flow offload: enables high pps and stable throughput when flows remain offloaded. Failure pattern: feature toggles push traffic to CPU and halve speed.
• Flow tables / caches: bound concurrent sessions and lookup complexity. Failure pattern: session exhaustion shows as selective “some apps fail” timeouts.

Security primitives

• Crypto + TRNG + secure storage: supports WPA3 baseline, secure boot, and protected credentials. Failure pattern: unsafe updates/rollback, identity loss, or weak defaults.

Connectivity + memory

• Ethernet MAC/PHY + switch fabric: LAN ports, VLAN/guest segmentation, IGMP handling at L2. Failure pattern: multicast flooding or segmentation leaks.
• Wi-Fi radios + FEM: airtime scheduling and RF calibration shape real user experience. Failure pattern: high retries and rate fallback under interference or thermal limits.
• DDR + flash (SPI-NOR / eMMC / NAND): buffers, queues, logging, and OS. Failure pattern: bufferbloat-like jitter, watchdog resets under memory pressure, or slow management response.
• USB/storage: NAS and peripherals add power/EMI stress. Failure pattern: hot-plug reboots or 2.4 GHz degradation during USB3 activity.

Integrated vs discrete design (decision criteria)

Router platforms span from highly integrated SoCs to split designs (external switch/PHY, external Wi-Fi modules). The best choice depends on thermal margin, upgrade flexibility, and board-level risk.

• Prefer higher integration when cost, BOM count, and idle power dominate and the enclosure has limited airflow.
• Prefer discrete switch/PHY when port count, multi-gig combinations, or VLAN/multicast behavior must be tightly controlled.
• Prefer discrete Wi-Fi modules when RF/antenna isolation and upgrade cadence (Wi-Fi generation changes) outweigh the added integration complexity.
• Thermal & EMI reality: more chips can spread heat, but also add clocks, rails, and coupling paths—layout and PMIC margin become decisive.

WAN handoff is a “contract”: what enters the gateway and what it costs

From the gateway’s perspective, the WAN side is a handoff contract: a link type plus session behavior. This matters because the handoff can change offload eligibility, MTU/MSS, and keepalive behavior—all of which can move traffic from hardware acceleration to CPU processing.

• Ethernet handoff: simplest datapath; often easiest to keep traffic on offload fast path.
• Integrated DSL gateway: adds a power/thermal and driver coupling point (system view only).
• Fiber ONT handoff: typically Ethernet from an ONT; treat as handoff-only (no access-network internals here).

Integrated DSL vs external modem + router (system-level differences)

The key trade is not “speed” but coupling: how tightly the access termination, router SoC, power rails, and thermal budget are tied together.

• Thermal headroom: integrated designs concentrate heat; sustained load can trigger throttling or instability if enclosure conduction is weak.
• Power rail stress: access termination peaks can align with Wi-Fi transmit peaks and USB activity; PMIC margin becomes decisive.
• Update coupling: integrated platforms often have unified firmware paths; external modem splits responsibility but can reduce risk by isolating failures.
• Failure patterns: integrated boxes often show heat/time-correlated drops; split designs more often show negotiation/MTU/session mismatches.

PPPoE vs DHCP/IPoE (why session type affects fast path)

PPPoE adds encapsulation and frequently changes effective MTU. If MSS clamping is not aligned, fragmentation or retransmissions can appear as “mystery slowness.” On some platforms, PPPoE (or specific feature combinations with it) also narrows offload conditions, increasing CPU work for session handling and packet processing.

• PPPoE: watch MTU/MSS, keepalives, and CPU utilization under load; offload may be more conditional.
• DHCP/IPoE: typically cleaner datapath; more likely to remain on accelerated forwarding when policies are simple.
• Quick validation: if throughput drops and CPU rises after enabling PPPoE or a feature, treat it as a datapath mode change (fast→slow).

What really defines “good Wi-Fi” in a home gateway

Home Wi-Fi performance is limited less by peak PHY rate and more by airtime: how much time the channel is available after contention, retries, management overhead, and interference. A design that looks “fast on paper” can feel slow if it spends airtime on retransmissions or on backhaul links that compete with client traffic.

• Coverage: stable MCS at typical distances matters more than a near-router speed test.
• Concurrency: many clients + bursts of short flows increase contention and scheduling pressure.
• Backhaul occupancy: mesh backhaul is a “hidden client” that can consume a large airtime share.
• Coexistence: thermal drift and self-interference can silently increase retries and jitter.

Multi-band strategy: dedicated backhaul vs shared backhaul

Mesh systems must decide where backhaul traffic lives. The key difference is whether backhaul has dedicated airtime (a separate radio/band) or shares airtime with user devices on the same band.

• Dedicated backhaul: more stable sustained throughput and lower jitter, especially with multiple nodes and dense clients.
• Shared backhaul: lower cost, but throughput drops quickly with distance and interference because clients and backhaul compete for the same airtime.
• Design sizing: a “good” mesh platform budgets airtime for backhaul explicitly, rather than assuming peak PHY rates.

2.4 / 5 / 6 GHz roles (home-oriented tradeoffs)

Each band should have an intentional role to avoid pathological contention. A balanced design aligns device classes, distances, and channel conditions to the band where it is most resilient.

• 2.4 GHz: best reach for IoT and long-range coverage; common failure mode is congestion and interference → higher retry rate → latency spikes.
• 5 GHz: primary capacity band in many homes; common failure mode is distance/obstructions → rate fallback and unstable throughput.
• 6 GHz: high capacity and cleaner spectrum at short range; common failure mode is weak penetration → performance collapses outside near-line-of-sight zones.

Coexistence & drift (system-level “symptom → cause” mapping)

Many “Wi-Fi is unstable” reports are not protocol problems but system-level drift and coexistence: temperature, power limits, and self-interference can reduce effective SNR and raise retries.

• Speed degrades after warm-up → thermal rise triggers RF/PA efficiency drop, calibration drift, or SoC throttling → retries increase.
• 2.4 GHz worsens during USB/NAS activity → broadband noise coupling and self-interference risk (layout, shielding, and rail noise).
• RSSI looks fine but jitter is high → contention + retries dominate airtime; aim to reduce interference and balance client/backhaul airtime.

Why home network “experience issues” often come from L2 and multicast

Many home complaints that look like “slow internet” are caused by local LAN behavior: incorrect segmentation, L2 flooding, or multicast flows that are replicated everywhere. When this happens, Wi-Fi airtime and LAN ports can be consumed by traffic that most devices never requested.

• Segmentation leaks: guest or IoT devices can discover and access private resources when bridges are mis-mapped.
• Multicast flooding: IPTV or discovery traffic can be replicated to all ports/SSIDs, degrading Wi-Fi stability.
• Switch placement matters: whether isolation and snooping occur in switch silicon or in CPU changes stability under load.

Main / Guest / IoT: where to place the boundary (bridge vs routing vs ACL)

Reliable isolation is not just “separate SSIDs.” The boundary must be placed intentionally so that discovery and broadcast domains do not unintentionally merge.

• Bridge-domain separation (VLAN/bridge mapping): keeps broadcasts contained; failure mode is wrong port/SSID mapping causing leakage.
• Routing separation (different subnets): strongest default isolation; controlled exceptions are needed for a few home services.
• ACL at the L3 policy point: apply allow/deny where traffic crosses segments; do not rely on endpoints for isolation.

IPTV multicast: IGMP snooping/proxy as a system stability feature (gateway view)

IPTV and many discovery protocols rely on multicast. Without proper multicast control, traffic can be replicated broadly and behave like broadcast. The gateway’s job is to keep multicast on the minimum necessary ports and SSIDs.

• IGMP snooping: limits multicast to interested ports; without it, multicast can flood LAN and Wi-Fi.
• Proxy/querier behavior: maintains group membership state so multicast forwarding remains stable.
• Home symptom: “TV on → Wi-Fi slow” often points to multicast flooding consuming airtime.

Internal switch vs external switch/PHY: when discrete switching is worth it

Many gateways embed a basic switch fabric, but port mix, multi-gig support, and multicast/isolation behavior can justify an external switch/PHY. The trade is board complexity versus controllability.

• Internal switch: fewer chips, lower BOM, simpler rails; limits appear with port count, multi-gig combos, or richer isolation features.
• External switch/PHY: flexible port configurations and tighter multicast/VLAN control, but adds rails, clocks, layout, and thermal considerations.

Why “rated bandwidth is fine” but enabling features drops speed

A home gateway does not forward every packet the same way. Most platforms have a fast path (flow cache / NPU offload) and a slow path (CPU handling via the OS network stack). Throughput collapses when traffic moves from fast path to slow path, or when the flow cache hit-rate drops under real workloads.

• Fast path: best for simple, repetitive flows that match offload rules.
• Slow path: triggered by misses, complex policies, small packets, or high connection churn.
• What users observe: “turn on QoS / filters / VPN → speed drops” is usually a path-switch event.

Fast path eligibility: what typically keeps offload working

Offload is conditional. It usually depends on how “simple” the packet treatment is and whether the platform can classify a flow into a stable rule that can be executed in hardware without per-packet CPU involvement.

• NAT/conntrack (basic): often offload-friendly when rules are simple and flow tables have headroom.
• ACL/firewall: more complex matching can reduce offload; rule count and match diversity matter.
• QoS: fine-grained classification, shaping, or queue policies can force CPU participation.
• Encryption/tunnels: depends on crypto offload; without it, CPU becomes the bottleneck.
• Deep inspection (high-level only): richer inspection usually implies more CPU or dedicated engines.

The practical question is not “does it support hardware NAT,” but how often traffic stays in offload when real features are enabled.

Slow path triggers: the common reasons CPU hits 100%

Slow path is usually triggered by workloads that are hard to reduce to simple flow actions, or by conditions that overload the control plane with packet-rate and state updates.

• Small packets / high pps: 64B packets or chatty flows can saturate CPU even when Gbps is modest.
• High connection churn: many short-lived flows stress state creation and table maintenance.
• Complex policy chains: layered rules, multiple matches, and exception handling reduce offload hit-rate.
• Retries and abnormal patterns: retransmissions increase packet count and amplify CPU pressure.

Performance validation as an engineering dashboard (not a single speed test)

A reliable throughput claim should be validated with a minimal set of counters, so it becomes obvious whether the bottleneck is packet-rate, CPU, queues, or table pressure.

• Gbps (large packets): peak throughput potential.
• pps / Mpps (small packets): packet-rate stress and per-packet overhead.
• CPU load: evidence of slow-path processing or insufficient offload.
• Drop / error counters: queue drops, RX/TX errors, and policy drops reveal where the pipeline breaks.
• Flow/conntrack utilization: table headroom and hit-rate trends explain “feature-enabled drop” behavior.

Debug workflow: isolate the feature that forces the slow path

The fastest way to identify the limiting feature is to start from a minimal forwarding baseline and then add features one at a time, watching CPU and counters for step changes.

• Step 1: baseline forwarding (basic NAT) → record Gbps + pps + CPU + drops.
• Step 2: enable QoS → check for CPU jump and queue drop changes.
• Step 3: enable ACL/security filters → check flow hit-rate and policy drops.
• Step 4: enable VPN/encryption → check whether throughput becomes CPU-bound.
• Step 5: conclude from evidence: pps-bound vs CPU-bound vs queue-bound vs table-bound.

When “lag” is really queues and memory pressure (bufferbloat symptoms)

A gateway can look “fast” in throughput while still feeling slow in real usage. Deep queues and poor queue management can preserve throughput at the cost of latency and jitter. Under sustained load, buffer growth and memory pressure can increase drops and retransmissions, which further raises packet-rate and CPU work.

• Symptom: video calls/game lag during downloads even though speed tests remain high.
• Mechanism: packets wait in long queues; latency balloons before drops become visible.
• Evidence: queue drops, rising retry counts, and CPU spikes during mixed traffic.

DDR is a shared resource: bandwidth contention drives jitter

DDR is not only “capacity.” It is a shared bandwidth pool for CPU, offload engines, Wi-Fi buffering, encryption, and DMA traffic. Under bursty workloads, contention can reduce effective throughput and increase latency variance.

• Client concurrency increases buffer turnover and metadata updates.
• Feature enablement adds table lookups and state tracking.
• USB/NAS workloads add sustained DMA traffic and interrupt pressure.

Storage tiers: what each layer is for (and how it affects stability)

A typical gateway uses multiple storage layers. Stability issues often appear when sustained writes, logging, or external storage introduces power transients or timing noise into the platform.

• SPI-NOR: boot and critical firmware; low write frequency and high reliability expectations.
• NAND / eMMC: OS image, configuration, logs, plugins; write bursts can cause performance variance.
• USB storage: NAS/download use-cases; adds power and EMI coupling points into the system.

USB3 pitfalls in routers: power transients and 2.4 GHz self-interference

USB3 can destabilize a home gateway through two common system-level paths: power transients and EMI coupling. Both can look like “random” reboots or “mysterious” Wi-Fi instability.

• Power transient: external devices draw inrush or load steps → 5V rail dips → PMIC brownout or watchdog reset.
• EMI coupling: USB3 high-speed signaling and harmonics couple into the 2.4 GHz receive chain → retries increase → airtime collapses.
• Practical symptom: “plugging USB in” correlates with 2.4 GHz drops or reboot under sustained I/O.

Power is a stability system: why “random reboot” is usually a rail event

A home gateway is not powered by “one good 3.3 V rail.” It is a power tree with multiple domains that interact under burst load: CPU/NPU activity, Wi-Fi transmit peaks, Ethernet switching, and USB hot-plug events. Many “random” reboots are actually brownout/UVLO, protection trips, or watchdog recovery after a rail transient.

• SoC core: brief dips cause immediate reset or silent instability.
• DDR rail: small margin loss can look like unpredictable crashes.
• USB 5 V: hot-plug inrush and load steps can pull shared rails down.
• Wi-Fi/RF: power peaks can inject noise into sensitive domains and reduce link margin.

Typical router power domains (what must be separated and why)

The most common domains in a home gateway are grouped by “what breaks when this rail is unstable,” not by voltage labels. This helps size regulators and decide where protection and monitoring are required.

• SoC core + DVFS: dynamic voltage/frequency scaling changes current demand in fast steps.
• SoC I/O: interfaces and PHY links rely on a stable I/O supply for timing and signal integrity.
• DDR: one of the most stability-sensitive rails under load and temperature variation.
• Wi-Fi/RF: PA/LNA/radio blocks create burst loads and are sensitive to supply noise.
• Ethernet PHY: multi-port activity adds heat and can increase load on shared supplies.
• USB + peripherals: introduces external power uncertainty (inrush, cable quality, device behavior).

Sequencing: the difference between “boots” and “boots reliably”

Power-up is a controlled sequence. DDR training, PHY bring-up, and Wi-Fi calibration depend on rails reaching valid levels and reset being released at the right time. If the sequence is marginal, failures appear as cold-boot issues, intermittent boot loops, or “works after a reboot.”

• Enable order: I/O → core → DDR → PHY → Wi-Fi → optional USB power gating (system-level view).
• PG / reset gating: power-good signals should hold reset until rails and clocks are stable.
• Discharge behavior: incomplete rail discharge can cause “half states” and inconsistent restarts.

Brownout under load: inrush, load steps, and why it looks like a network problem

Many field issues occur only under burst conditions: simultaneous Wi-Fi transmit peaks, CPU spikes, and USB or storage I/O. These create load steps that can exceed regulator response or input adapter margin, leading to brownout, resets, or silent packet loss that users interpret as “ISP instability.”

• Inrush: USB hot-plug and peripheral startup cause sudden current draw on 5 V and shared paths.
• Load step: DVFS and radio bursts create fast current edges that expose poor transient response.
• Hold-up margin: weak adapters/cables or connector resistance reduce headroom during peaks.

Protections that improve safety—and how to make them explainable

Protection devices prevent damage but can also create cascading symptoms if a domain is shut down unexpectedly. The system needs both protection and evidence to prove what happened.

• eFuse / high-side switch: isolates USB/peripherals during shorts or overloads; avoids collapsing core rails.
• OCP/OTP: over-current/over-temperature actions can look like “random dropouts” without logging.
• Watchdog: converts unrecoverable hangs into a controlled reboot—only useful if reset cause is recorded.
• Reset-cause logging: brownout vs watchdog vs thermal vs manual reboot should be distinguishable.

Clocks as a link-stability resource (not a “spec sheet detail”)

In a gateway, clocks show up as stability. Jitter and drift reduce link margin in PHY and radio chains, which can increase errors and retries under temperature and load variation. The result is often not “a constant slowdown,” but bursty throughput, reconnections, or higher latency variance.

• What changes with temperature: PLL behavior and timing margin across SoC/PHY/radio subsystems.
• What users see: retries increase, rate drops, and “random” link events become more frequent.

EMI in home gateways: the practical noise sources

Self-interference is common because high-speed digital blocks and sensitive RF chains live in the same enclosure. The outcome depends on coupling paths, not only on the presence of noise.

• Switching power (PMIC/DC-DC): fast edges and current loops inject noise into supply rails.
• USB3: high-speed signaling can couple into 2.4 GHz receive paths.
• Ethernet PHY + magnetics: port-side energy can radiate into antenna regions if poorly isolated.
• Antenna/RF front-end: often the victim; sensitivity loss shows up as retries and rate fallbacks.

Coupling paths: how “USB plugged in” becomes “Wi-Fi unstable”

Practical EMI problems can be described as source → path → victim → symptom. This framing keeps the analysis system-level and helps isolate what changed when a cable or device is added.

• Conducted: rail noise or ground bounce reduces RF/PLL margin → errors/retries rise.
• Near-field / radiated: USB3 and port regions couple into antenna keep-out areas → 2.4G RX noise floor rises.
• Return path: poorly controlled return currents can turn structures into unintended antennas.

Thermal: throttling can masquerade as a network issue

Heat is dynamic. As the enclosure reaches steady state, hotspots drive protective behavior: frequency reduction, transmit power limiting, or regulator derating. The user experience is often “the internet is bad,” but the cause is local thermal control.

• Hotspots: SoC, PMIC, Wi-Fi PA, and multi-port PHY regions.
• Typical pattern: fast after boot → degrades after minutes under sustained load.
• Symptoms: throughput drops, latency rises, and Wi-Fi rate falls back under heat.

Stability triage: separate thermal, EMI, and clock-margin effects

A stable troubleshooting approach is to look for “step changes” that correlate with temperature, cable/device insertion, or workload state transitions.

• Thermal-first check: if performance degrades with time under load, suspect throttling or derating.
• EMI-first check: if instability appears immediately when USB3 is connected, suspect coupling into 2.4G RX.
• Margin-first check: if link events correlate with temperature swings, timing margin may be shrinking.

Home-gateway security is a lifecycle problem (not a single feature)

In residential gateways, security failures rarely look like “a clean hack.” They look like persistent compromise, unwanted remote control, privacy leaks, or devices joining botnets. A practical design focuses on three outcomes: only trusted firmware runs, updates are recoverable, and each device has a unique identity.

• Integrity: reject unsigned or tampered firmware at boot time.
• Recoverability: survive power loss and bad images without bricking.
• Identity: bind management and updates to a per-device credential.

Secure boot chain (ROM → bootloader → OS → applications)

Secure boot is a chain of verification steps. The goal is not “encryption” but authorization: every stage must verify the next stage before execution. The chain is only as strong as its first immutable link.

• ROM / immutable root: contains a small verifier and a trusted key reference.
• Bootloader: verifies kernel/firmware images and selects the boot slot (A/B).
• OS image: verified before execution; optional measured-boot logging can be added later.
• Apps/services: should not be able to overwrite verified boot components.

Implementation note (system-level): use a hardware-backed key store or secure element so verification keys are not trivially replaced by software compromise.

Updates that do not brick: A/B images, health checks, and anti-rollback

The most common real-world failure mode is an interrupted or faulty update. A robust gateway uses dual images (A/B) and only commits the new image after a short health-check window. Anti-rollback prevents downgrades to known vulnerable versions.

• Download into the inactive slot (B) while running from (A).
• Verify signature and integrity before scheduling a boot switch.
• Boot trial into (B) and run health checks (WAN/LAN/Wi-Fi basics, watchdog stability).
• Commit (B) only if checks pass; otherwise rollback to (A).
• Anti-rollback: maintain a monotonic version rule to block unsafe downgrades.

Device identity (minimum viable practice for home gateways)

A serial number labels a device; it does not authenticate it. Minimum viable identity is a per-device credential (key or certificate) stored in hardware-backed storage and used for secure management and update authorization.

• Uniqueness: each device must have its own secret (no “shared factory key”).
• Rotation: credentials should be replaceable during lifecycle (service or security response).
• Non-export: secrets should not appear in plaintext config backups or logs.

Remote management and privacy (home view): enforce first-boot credential change, avoid exposing admin UI on WAN by default, and redact sensitive fields in diagnostic logs.

Example BOM part numbers (non-exhaustive, router-class)

The list below provides concrete reference part numbers commonly used in home gateway designs. Final selection depends on SoC ecosystem, cost targets, supply, and regulatory constraints.

• Router / gateway SoC examples (platform reference): Qualcomm IPQ8074A, IPQ4019; MediaTek MT7621A, MT7986; Broadcom BCM6750.
• Secure element / TPM examples (identity + secure boot assist): Microchip ATECC608B; NXP SE050; Infineon OPTIGA TPM SLB9670.
• SPI NOR (boot / A-B images): Winbond W25Q128JV, W25Q256JV; Macronix MX25L12835F; Micron MT25QL128.
• USB power switch / eFuse (hot-plug inrush + protection): TI TPS2553 (USB power switch), TI TPS25982 (eFuse).
• Watchdog timer (controlled recovery): TI TPS3431.
• Reset supervisor (clean reset on brownout): TI TPS3839; Microchip MCP130.
• Rail telemetry (current/voltage monitor for field evidence): TI INA219, INA226.
• Temperature sensor (thermal throttle evidence): TI TMP102, TMP117.
• LAN switch / PHY examples (home segmentation / ports): Microchip KSZ9477; Realtek RTL8367S.

Validation is a three-stage checklist: R&D → production → field

Troubleshooting becomes fast when the same core behaviors are validated at three stages. The test items stay consistent; only the depth and tooling differ.

• R&D: WAN↔LAN throughput (big+small packets), pps/Mpps, session/conntrack, Wi-Fi coverage + backhaul load, USB hot-plug, thermal steady-state, brownout tests.
• Production: basic port bring-up, Wi-Fi link sanity, quick thermal screen, reset-cause logging presence.
• Field: reproduce with a minimal scenario and capture counters + timestamps, not anecdotes.

Always measure Gbps and pps (why “night slowdown” is often not WAN bandwidth)

Many gateways meet headline Gbps numbers with large packets but collapse on small packets, heavy QoS/ACL, or high connection churn. When performance drops at peak hours, the limiting factor is frequently packet rate, CPU slow path, queue drops, or Wi-Fi retries rather than WAN bandwidth itself.

• Big packets validate raw throughput; small packets validate per-packet overhead and acceleration.
• CPU load + drops reveal whether traffic fell from fast path to slow path.
• Retries reveal Wi-Fi margin loss and airtime starvation.

Key counters and logs (the “readable signals” that end guesswork)

A stable troubleshooting workflow relies on a small set of counters and reason codes that can be captured in a support bundle. These signals map symptoms to root causes with minimal ambiguity.

• Drop reason: queue overflow, policy drop, interface errors.
• Retries / retrans: Wi-Fi retry rate trend and burst events.
• CPU load: sustained high load suggests slow-path processing.
• Fast-path hit/miss (if available): acceleration engagement vs fallback.
• Reset cause: brownout / watchdog / thermal / manual.
• Thermal throttling flag: confirms performance loss is self-protection.

Reference instrumentation BOM examples: TI INA226 (rail telemetry), TI TMP102 / TMP117 (temperature), TI TPS3431 (watchdog), TI TPS3839 (supervisor).

Typical symptom-to-cause splits (fast filters that save hours)

• “Speed drops”: check if fast-path disengaged (CPU ↑, hit ↓) vs Wi-Fi airtime contention (retries ↑, rate fallback).
• “Packet loss spikes”: check queue drops vs interface errors vs retry bursts (Wi-Fi margin loss).
• “Frequent disconnects”: check Wi-Fi retry storms vs WAN session instability indicators (gateway-side keepalive events).
• “Random reboots”: check reset cause first (brownout vs thermal vs watchdog) before changing any network settings.

Prove the fix (actions that must be validated)

• Slow-path bound → reduce complex features or optimize rules → verify CPU load drops and pps headroom returns.
• Airtime contention → adjust backhaul strategy/band split → verify retries drop and stable throughput returns.
• Power transient → USB power gating/eFuse tuning/adapter upgrade → verify reset cause no longer reports brownout.
• Thermal derating → improve heat path/limit sustained load → verify throttling flag no longer appears.
• EMI coupling → cable/placement/isolation changes → verify Wi-Fi retry bursts disappear when USB3 is active.