Slow Wi-Fi on Windows: An End-to-End Diagnosis and Optimization Guide

Watch it

Video file size: 83 KB — may take a moment to buffer on slower connections.

Step by step

1. 1

   Overview

   Slow Wi-Fi on Windows: An End-to-End Diagnosis and Optimization Guide

   Case: ASUS laptop (Windows 11 Pro), Realtek 8852CE WiFi 6E adapter, Huawei HG8145V5 GPON router. Complaint: "Internet is slow on this laptop; the second laptop on the same router is much faster." Date: 2026-08-07

   This guide walks through exactly what was done in that case, step by step. Alongside each command is why it was run — so the process can be repeated on another machine.

   Result summary: All of the gain came from the laptop side. Average download went from 199 to 263 Mbps, but the real win was not speed — it was consistency: the spread between measurements dropped from 3.14× to 1.08×. The root cause was not the router's speed, but the laptop drifting between bands.

   • Ground rules

   • Preparation

   • Step 1 — Baseline measurement

   • Step 2 — Reading the data: diagnosis

   • Step 3 — Power management

   • Step 4 — Adapter advanced properties

   • Step 5 — The TCP/IP layer

   • Step 6 — Background traffic

   • Step 7 — Catching the root cause

   • Step 8 — The router side

   • Step 9 — Verification

   • Lessons from this case

   • Command reference

   ---

2. 2

   1. Ground rules

   Rules to impose on yourself during this work. Nothing broke in this case because they were followed.

   • 1: Read and record before changing — Never make a change you cannot undo. Every setting's old value must be written down.

   • 2: Measure first, change second — Without a baseline you cannot claim improvement.

   • 3: One variable at a time — Change two settings together and break something, and you won't know which one did it.

   • 4: Create a restore point — Free insurance.

   • 5: Fix your measurement conditions — Same server, same location, same band. Otherwise you'll mistake noise for gain.

   • 6: On error, stop and interpret — Skipping past an error makes every subsequent measurement suspect.

   • 7: Don't lock yourself out — When changing settings on the link you're working over, keep a recovery path.

   ---

3. 3

   2. Preparation

   2.1 Administrator privileges

   Almost every write operation requires elevation. Check:

   $id=[Security.Principal.WindowsIdentity]::GetCurrent() (New-Object Security.Principal.WindowsPrincipal($id)).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

   If it returns `False`, restart the terminal as administrator. In this case the first session was unelevated: `Checkpoint-Computer` returned "Access denied", and `Get-NetAdapterPowerManagement` returned a misleading "A device attached to the system is not functioning" — which was actually a permissions error.

   2.2 Location services

   This is mandatory on Windows 11. With it off, `netsh wlan show interfaces` returns nothing:

   Network shell commands need location permission to access WLAN information.

   Band, channel, signal %, RSSI, link rate — the core diagnostic data all comes from this command. `Settings > Privacy & security > Location` → turn on.

   2.3 Restore point

   Checkpoint-Computer -Description "Wi-Fi tuning baseline" -RestorePointType MODIFY_SETTINGS Get-ComputerRestorePoint | Select-Object SequenceNumber,Description,CreationTime

   This can fail silently. Always verify with the second command. If System Protection is disabled, no point is created — enable it first from `Settings > System > About > System protection`.

   Windows creates at most one restore point per 24 hours by default. If the last point is recent, a new one won't be created.

   2.4 Open a log file

   For every change, track these columns:

   | Setting | Old value | New value | Apply command | Rollback command |

   This table will become your rollback script at the end.

   ---

4. 4

   3. Step 1 — Baseline measurement

   Measure before changing anything. These numbers are your reference.

   3.1 Speed test

   winget install --id Ookla.Speedtest.CLI --scope user --accept-source-agreements --accept-package-agreements

   PATH is not refreshed, so use the full path:

   $exe="$env:LOCALAPPDATA\Microsoft\WinGet\Packages\Ookla.Speedtest.CLI_Microsoft.Winget.Source_8wekyb3d8bbwe\speedtest.exe" & $exe --accept-license --accept-gdpr -f json | ConvertFrom-Json

   Run it at least 3 times. A single measurement tells you nothing.

   ⚠️ Critical pitfall: Left to itself, it picks a different server each run, and you can no longer separate the source of variance. In this case the baseline hit three different servers (275.5 / 87.8 / 233.8 Mbps), and it was impossible to tell how much of that 3× spread came from the server versus the Wi-Fi.

   >

   Do this instead: get the server list, pick one, always connect to it.

   & $exe -L # server list & $exe -s 70970 -f json # pinned server

   3.2 Latency, jitter, packet loss

   foreach ($t in '192.168.100.1','1.1.1.1','8.8.8.8') { "=== $t ==="; ping -n 50 $t | Select-Object -Last 4 }

   Each of the three targets means something different:

   • Router IP: The Wi-Fi link only. Loss or latency here means the problem is definitely Wi-Fi.

   • 1.1.1.1: Wi-Fi + the ISP's nearby peering

   • 8.8.8.8: Wi-Fi + ISP + a long path

   In this case: 1 ms / 0% loss to the router → the Wi-Fi link was clean. The 75 ms to 8.8.8.8 was ISP routing and had nothing to do with the laptop.

   Look at `Maximum`, not the average. If the average is fine but the peak is high (1 ms avg / 16 ms max to the router in this case), that's usually the signature of power management — the adapter is sleeping between packets.

   3.3 Wi-Fi link state

   netsh wlan show interfaces

   This command's output is the center of the diagnosis:

   SSID : Elirehim AP BSSID : 7c:00:4d:1b:88:b4 <- which radio you're on Band : 5 GHz Channel : 36 Radio type : 802.11ac <- not ax? then the router isn't Wi-Fi 6 Authentication : WPA2-Personal Cipher : CCMP Receive rate (Mbps) : 585 Signal : 74% Rssi : -71 <- THE SINGLE MOST IMPORTANT NUMBER

   3.4 How to read RSSI

   • −30…−50 dBm: Excellent — Highest MCS, full rate

   • −50…−60 dBm: Good — High MCS

   • −60…−70 dBm: Fair — MCS drops, rate can halve

   • −70…−80 dBm: Weak — Low MCS, dropouts

   • Below −80 dBm: Unusable — —

   Don't trust the "Signal %", read the RSSI. The percentage is computed differently by each vendor. In this case "74%" looked fine, but the −71 dBm behind it was weak.

   3.5 Adapter and driver

   Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,LinkSpeed,MacAddress,ifIndex netsh wlan show drivers

   `netsh wlan show drivers` gives you the adapter's theoretical ceiling:

   Radio types supported : 802.11b 802.11g 802.11n 802.11ac 802.11ax 802.11a Number of supported bands : 3 (2.4 / 5 / 6 GHz)

   Compare that against the actual `Radio type` from `netsh wlan show interfaces`. In this case the adapter supported `ax` + 6 GHz but the connection was on `802.11ac` → the router was the bottleneck.

   3.6 Neighboring network scan

   netsh wlan show networks mode=bssid

   Two critical data points:

   • Channel Utilization — how busy the air is. 2–10% = empty, 50%+ = crowded.

   • Number of visible networks — neighbor density.

   In this case: the only visible network was the user's own router, and utilization was 2%. That immediately killed the "the channel is crowded, change channels" advice. There was no interference; the sole cause of the low rate was distance.

   💡 A scan returns a point-in-time result. If the router is dual-band, one scan may show the 2.4 GHz BSSID and the next the 5 GHz one. Run it several times.

   ---

5. 5

   4. Step 2 — Reading the data: diagnosis

   Measurements are done. Now think. Answer these before writing any more commands:

   Question 1: Is the problem the Wi-Fi or the internet?

   • Ping to the router clean (no loss, low latency) → the Wi-Fi link is sound

   • Speedtest low but link rate high → the bottleneck is the ISP or the router's WAN

   In this case link was 585 Mbps and throughput 254 Mbps → Wi-Fi was not the bottleneck, the ISP ceiling was.

   Question 2: Variance, or a low average?

   This distinction changes everything.

   • Low but steady → a capacity problem (ISP, distance, hardware)

   • Jumping around → something is changing: band drift, power management, background traffic

   In this case it swung between 87.8 and 275.5 Mbps. The real complaint was not "slow" but "inconsistent."

   Question 3: What is the theoretical ceiling?

   • 802.11n: 2x2, 40 MHz — 300 Mbps

   • 802.11ac: 2x2, 80 MHz — 867 Mbps

   • 802.11ac: 2x2, 160 MHz — 1733 Mbps

   • 802.11ax: 2x2, 80 MHz — 1201 Mbps

   Where does your link rate sit against the ceiling? In this case 585/520 Mbps against an 867 Mbps ac ceiling → roughly MCS7, not MCS9 → insufficient RSSI. MCS9 needs about −55 dBm.

   ---

6. 6

   5. Step 3 — Power management

   This is the most common software cause of slow Wi-Fi. The adapter sleeps to save energy, and waking it up costs latency.

   5.1 Read the current state

   Get-NetAdapterPowerManagement -Name 'Wi-Fi'

   Many fields may come back `Unsupported` — meaning those features are already off. In this case:

   ArpOffload : Unsupported <- already off NSOffload : Unsupported D0PacketCoalescing : Disabled <- already at target SelectiveSuspend : Unsupported

   5.2 "Allow the computer to turn off this device" — disable it

   This is the famous checkbox in Device Manager. In the registry it's `PnPCapabilities`:

   $key='HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0001' # SAFETY: is this the right adapter? (Get-ItemProperty $key).DriverDesc # record the old value (Get-ItemProperty $key -Name PnPCapabilities -ErrorAction SilentlyContinue).PnPCapabilities # apply New-ItemProperty -Path $key -Name PnPCapabilities -Value 24 -PropertyType DWord -Force

   ⚠️ `0001` is a different adapter on every machine. Verify with `DriverDesc` before writing. Write to the wrong key and you'll break your Ethernet or Bluetooth.

   >

   To find the right key: ```powershell $net='HKLM:\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}' Get-ChildItem $net | ForEach-Object { $p=Get-ItemProperty $.PSPath -ErrorAction SilentlyContinue if ($p.DriverDesc -match 'Wi-Fi|Wireless|WiFi') { "$($.PSChildName) = $($p.DriverDesc)" } } ```

   Value meaning: `24` (0x18) = power management off. If the value is absent, the default is on. To roll back, delete the value — do not write `0`.

   It only takes effect after an adapter restart (Step 9).

   5.3 powercfg — wireless power saving

   The classic advice is:

   powercfg /setacvalueindex SCHEME_CURRENT 19cbb8fa-5279-450e-9fac-8a3d5fea2145 12bbebe6-58d6-4636-95bb-3217ef867c1a 0

   ⚠️ On Modern Standby machines this subgroup does not exist. Check: ```powershell powercfg /a ``` If it says `Standby (S0 Low Power Idle)`, Microsoft has removed this setting. Even `-ATTRIB_HIDE` won't surface it. That's exactly what happened in this case — `PnPCapabilities` was used instead.

   5.4 Power plan

   On Modern Standby machines `powercfg /list` shows only `Balanced`. The others are hidden but can be created:

   powercfg -duplicatescheme e9a42b02-d5df-448d-aa00-03f14749eb61 # Ultimate Performance powercfg -duplicatescheme 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c # High Performance powercfg /setactive 175ba1eb-c0bc-4204-aed1-6a6cc85736ce

   💡 `/list` may still not show them, but `/query` proves they exist and `/setactive` works.

   ⚠️ On a laptop, Ultimate Performance noticeably hurts battery life and its contribution to Wi-Fi is usually near zero. `PnPCapabilities` does the real work. If you're not on mains power, skip it.

   5.5 USB selective suspend

   $g = '381b4222-f694-41f0-9685-ff5bb260df2e' # Balanced powercfg /setacvalueindex $g 2a737441-1930-4402-8d77-b2bebba308a3 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0 powercfg /setdcvalueindex $g 2a737441-1930-4402-8d77-b2bebba308a3 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0 powercfg /setactive $g

   ⚠️ Pitfall: When you create and activate a new power plan, that plan carries its own USB setting. In this case it was applied to Balanced, then Ultimate was activated — and in Ultimate the setting was still `Enabled`. Apply it to the active plan too, and verify.

   This only matters if you use an external USB Wi-Fi dongle; it's inert for an internal PCIe adapter.

   ---

7. 7

   6. Step 4 — Adapter advanced properties

   Get-NetAdapterAdvancedProperty -Name 'Wi-Fi' | Select-Object DisplayName,DisplayValue,RegistryKeyword | Sort-Object DisplayName

   First find out which settings actually exist. Guides on the internet assume Intel adapters; Realtek/Qualcomm/MediaTek expose far fewer knobs.

   In this case the Realtek 8852CE exposed only 13 properties, and most of the classic list was simply absent:

   • Preferred Band: ✅ present — already `5G first`

   • Channel Width / Bandwidth: ✅ present — already `Auto`

   • 802.11n/ac/ax Mode: ✅ present — already highest

   • Roaming Aggressiveness: ✅ present — already `Medium`

   • Transmit Power: ❌ absent

   • MIMO Power Save Mode: ❌ absent

   • Fat Channel Intolerant: ❌ absent

   • Throughput Booster: ❌ absent

   • Packet Coalescing: ❌ absent

   • ARP/NS Offload: ❌ absent

   • Large Send Offload v2: ❌ absent

   • Interrupt Moderation: ❌ absent

   Lesson: most guides that say "change these 10 settings" cannot be applied to your hardware. Take inventory first.

   Seeing the valid values

   Before changing a setting, check which values it accepts:

   $p = Get-NetAdapterAdvancedProperty -Name 'Wi-Fi' -RegistryKeyword 'WifiBandwidth_phy0' $p.DisplayValue $p.ValidDisplayValues

   In this case `Bandwidth` accepted only `20MHz Only | Auto` — meaning the "pin it to 80/160 MHz" advice was impossible on this hardware, and `Auto` was already the best available.

   Changing

   Set-NetAdapterAdvancedProperty -Name 'Wi-Fi' -RegistryKeyword 'WifiProtocol_2g' ` -DisplayValue 'Disabled' -NoRestart

   Use `-NoRestart` to make several changes and then restart the adapter once at the end.

   ---

8. 8

   7. Step 5 — The TCP/IP layer

   7.1 Read the current state

   netsh int tcp show global netsh int tcp show supplemental

   Target values:

   • Receive Window Auto-Tuning: `normal` — ✅ already normal

   • Receive-Side Scaling (RSS): `enabled` — ✅ already enabled

   • Congestion Provider: `cubic` — ✅ already cubic

   • ECN Capability: `disabled` — ✅ already disabled

   On Windows 11 all four are already correct. None were changed in this case. Most "TCP tweak" guides date from the Windows 7 era and are obsolete today. Still, read and verify — someone may have broken them.

   If `show global` reports `Add-On Congestion Control Provider : default`, don't panic; the real value is shown by `show supplemental` (`cubic`).

   7.2 MTU — finding it empirically

   This is one of the rare TCP settings that can genuinely help.

   ping -f -l 1472 1.1.1.1

   • `-f` = Don't Fragment

   • `-l 1472` = payload size. MTU = payload + 28 (20 IP + 8 ICMP header)

   Do a binary search:

   foreach ($sz in 1472,1464,1452,1420) { $r = ping -f -l $sz -n 2 1.1.1.1 | Out-String "$sz (MTU $($sz+28)) -> $(if($r -match 'Reply from' -and $r -notmatch 'fragmented'){'PASS'}else{'FAIL'})" }

   Find the largest value that passes and add 28.

   💡 Test the router and the internet separately. In this case 1500 passed to the router but only 1492 passed to the internet. That 8-byte difference = PPPoE. The adapter was still at 1500.

   netsh interface ipv4 set subinterface "Wi-Fi" mtu=1492 store=persistent

   Common MTU values:

   • Ethernet / DHCP: 1500

   • PPPoE: 1492

   • PPPoE + some VPNs: 1400–1460

   7.3 DNS

   Measure; don't guess:

   $hosts='google.com','cloudflare.com','github.com','wikipedia.org' foreach ($dns in '1.1.1.1','8.8.8.8','9.9.9.9','192.168.100.1') { $tot=0 foreach ($h in $hosts) { Clear-DnsClientCache $sw=[Diagnostics.Stopwatch]::StartNew() Resolve-DnsName -Name $h -Server $dns -Type A -DnsOnly -ErrorAction SilentlyContinue | Out-Null $sw.Stop(); $tot+=$sw.ElapsedMilliseconds } "{0,-16} avg={1:N1} ms" -f $dns, ($tot/$hosts.Count) }

   ⚠️ The absolute numbers here are inflated by `Clear-DnsClientCache` overhead (600–750 ms in this case). Look only at the ranking, not the absolute value.

   Changing DNS:

   Set-DnsClientServerAddress -InterfaceAlias 'Wi-Fi' -ServerAddresses '1.1.1.1','1.0.0.1' ipconfig /flushdns

   DNS speed affects page load time, not download speed. Don't expect it to move your speedtest result.

   7.4 QoS reservable bandwidth

   $q='HKLM:\SOFTWARE\Policies\Microsoft\Windows\Psched' if (-not (Test-Path $q)) { New-Item -Path $q -Force | Out-Null } New-ItemProperty -Path $q -Name NonBestEffortLimit -Value 0 -PropertyType DWord -Force

   Let's be honest: the myth that "Windows steals 20% of your bandwidth" is false. Windows only reserves that 20% if an application actually requests QoS. Harmless, but don't build expectations on it.

   ---

9. 9

   8. Step 6 — Background traffic

   8.1 Delivery Optimization (P2P update sharing)

   $do='HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization' if (-not (Test-Path $do)) { New-Item -Path $do -Force | Out-Null } New-ItemProperty -Path $do -Name DODownloadMode -Value 0 -PropertyType DWord -Force

   `0` = P2P fully disabled. Stops Windows from distributing updates to others.

   8.2 Metered flag

   Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\DefaultMediaCost' | Select-Object Ethernet,WiFi

   `1` = Unrestricted (not metered) ✅ · `2` = Fixed · `4` = Variable

   8.3 Find bandwidth-consuming processes

   Get-NetTCPConnection -State Established | Where-Object { $_.RemoteAddress -notmatch '^(127\.|::1|0\.0\.0\.0)' } | Group-Object OwningProcess | Sort-Object Count -Descending | Select-Object -First 15 | ForEach-Object { $p = Get-Process -Id $_.Name -ErrorAction SilentlyContinue "{0,-30} connections={1}" -f $(if($p){$p.ProcessName}else{"PID $($_.Name)"}), $_.Count }

   In this case Steam topped the list with 15 connections. A client downloading a game update in the background invalidates every speed measurement. Close it before measuring, or at minimum note it.

   8.4 Unnecessary protocol bindings

   Get-NetAdapterBinding -Name 'Wi-Fi' | Select-Object DisplayName,ComponentID,Enabled

   Safe to disable on a home network:

   Disable-NetAdapterBinding -Name 'Wi-Fi' -ComponentID ms_lldp # LLDP Disable-NetAdapterBinding -Name 'Wi-Fi' -ComponentID ms_rspndr # LLTD Responder Disable-NetAdapterBinding -Name 'Wi-Fi' -ComponentID ms_lltdio # LLTD Mapper

   Never disable: `mstcpip` (IPv4), `mstcpip6` (IPv6), `ms_pacer` (QoS Scheduler). The speed effect is negligible; this is housekeeping, not a miracle.

   ---

10. 10

    9. Step 7 — Catching the root cause

    This is the most important section of the case. Everything up to here was correct but did not solve the actual problem.

    9.1 The symptom

    The first verification run after all the changes came out worse than baseline:

    Run 1 : DL 178.7 | UL 66.1 Mbps | 3.2% packet loss Run 2 : DL 57.7 | UL 51.6 Mbps Run 3 : {"error":"Cannot open socket"} <- outright failure

    9.2 The reflex: panic and roll back

    That would have been wrong. First check whether the measurement was even valid.

    netsh wlan show interfaces | Select-String 'BSSID|Band|Channel|Radio type|Receive rate'

    AP BSSID : 7c:00:4d:1b:88:b0 <- b0, not b4! Band : 2.4 GHz Channel : 3 Radio type : 802.11n Receive rate (Mbps) : 144.4 <- not 585

    9.3 The root cause

    The router was broadcasting one SSID on both bands (band steering):

    • `7c:00:4d:1b:88:b4` → 5 GHz, channel 36, 802.11ac, 585 Mbps, RSSI −71

    • `7c:00:4d:1b:88:b0` → 2.4 GHz, channel 3, 802.11n, 144 Mbps, RSSI −66

    The BSSIDs differ only in the last character → two radios of the same router.

    The client was picking the stronger but slower 2.4 GHz. Windows' "Preferred Band = 5G first" was not enough to prevent it, because the signal difference was 5 dB.

    That explained the 87.8 ↔ 275.5 Mbps swing in the baseline. It's also the likely reason the second laptop was faster — it was staying on 5 GHz.

    9.4 The fix: pin the band

    # Disable the 2.4 GHz radio -> the client is forced to stay on 5 GHz Set-NetAdapterAdvancedProperty -Name 'Wi-Fi' -RegistryKeyword 'WifiProtocol_2g' ` -DisplayValue 'Disabled' -NoRestart Restart-NetAdapter -Name 'Wi-Fi' -Confirm:$false

    Alternatives:

    • Disable 2.4 GHz on the client: Deterministic, doesn't affect other devices — No 2.4 GHz fallback in distant rooms

    • Split SSIDs on the router (`-2G` / `-5G`): Permanent, clean, keeps the fallback — Every 2.4 GHz device in the house must reconnect

    • Turn off band steering on the router: Easy — No guarantee — the client still chooses by signal

    The first method was chosen here: the laptop was the only problem, and there was no reason to disturb the household.

    9.5 The lesson

    When a measurement gets worse, the first question is not "which setting do I roll back" but "was the measurement valid". It wasn't, because the band had drifted. Rolling back settings would have deleted correct changes.

    ---

11. 11

    10. Step 8 — The router side

    The laptop side is done. Now the router.

    10.1 Identify the model (without logging in)

    $r = Invoke-WebRequest -Uri 'http://192.168.100.1' -UseBasicParsing [regex]::Match($r.Content,"ProductName\s*=\s*'([^']+)'").Groups[1].Value

    This returned `HG8145V5`.

    ⚠️ Searching the page content for a brand name is misleading. The first attempt matched "ZTE", but that came from a `DNZTELECOM2WIFI` branding list on the page. The device was Huawei. The `ProductName` variable and the `hwlogo_*` image names were the conclusive evidence.

    10.2 Read and compare the settings

    On a Huawei HG8145V5 the path is `Advanced > WLAN > ...`

    • 2.4G / 5G Basic: SSID, Authentication Mode, Encryption Mode, WPS

    • 2.4G / 5G Advanced: TX Power, Regulatory Domain, Channel, Channel Width, Mode, Band Steering

    10.3 The key finding: TKIP

    Authentication Mode : WPA/WPA2 PreSharedKey Encryption Mode : TKIP&AES <- PROBLEM

    TKIP cannot be used together with 802.11n/ac. The standard forbids it. In mixed `TKIP&AES` mode the AP may restrict its own BSS. TKIP is also cryptographically broken.

    Fix: `Encryption Mode` → `AES` → `Apply`

    💡 This firmware shared the security setting across both radios — the AES applied to 2.4 GHz also appeared on 5 GHz. Reload the page from scratch to verify.

    ⚠️ Honest expectation: in this case the change produced no measurable speed gain, because the client was already negotiating CCMP (AES). It's a correct and necessary fix, but not a performance fix.

    10.4 Common advice that may be WRONG

    Three "standard" recommendations collapsed once the device was actually inspected:

    • "Pin channel width to 80 MHz": Harmful at weak signal. An 80 MHz channel gives roughly 6 dB less SNR per subcarrier than 20 MHz. At RSSI −76, `Auto` is correct — it can narrow when the signal degrades.

    • "Switch to channel 149/157": The Regulatory Domain was `United Kingdom`. Under ETSI, 5 GHz has only 36–64 and DFS 100–140; 149–165 do not exist.

    • "Disable 20/40 Coexistence": No such setting exists in this firmware.

    Lesson: don't give advice without seeing the device. After seeing it, be ready to retract.

    10.5 Band steering — should you turn it off?

    It depends; it's not an automatic "yes":

    • If the client is already pinned to a band at the adapter level → turning it off gains nothing

    • If the house has many devices → turning it off may push them to 2.4 GHz

    • If only one device is problematic → solving it client-side is cleaner

    In this case it was left on, because the laptop was already pinned and the effect on the other 10 devices was uncertain.

    10.6 Other things to check

    Security > IPv4 Filtering -> any rules? Security > MAC Filtering -> is this device blocked or limited? Application > QoS -> any per-device rate limit? WLAN Advanced > TX Power -> is it 100%? WLAN Advanced > Regulatory Domain -> does it match your location?

    None of these had a limit in this case → the 254 Mbps ceiling was not router-imposed.

    ⚠️ If the Regulatory Domain doesn't match your location (`United Kingdom` while in Baku, in this case), that's a spectrum-regulation matter. Selecting the correct country is correct configuration, but picking an arbitrary country to gain TX power creates legal problems.

    10.7 While working in the router UI

    • One-session rule: Huawei ONTs allow only one admin session at a time. Logging in from

    another tab or device knocks out the existing one.

    • Session timeout: it logs itself out after roughly 5 minutes idle.

    • Login lockout: after a few failed attempts it locks for 1 minute.

    • Change the band you're connected over last. Test on the band you're not using first — some

    firmwares restart the whole device on `Apply`.

    ---

12. 12

    11. Step 9 — Verification

    11.1 Restart the adapter

    Restart-NetAdapter -Name 'Wi-Fi' -Confirm:$false foreach ($i in 1..30) { Start-Sleep -Seconds 2 if ((Get-NetAdapter -Name 'Wi-Fi').Status -eq 'Up' -and (Get-NetIPConfiguration -InterfaceAlias 'Wi-Fi').IPv4Address.IPAddress) { "Connected ($($i*2) s)"; break } }

    Registry changes such as `PnPCapabilities` only take effect after this.

    11.2 Repeat the measurement — with conditions fixed

    $exe="$env:LOCALAPPDATA\Microsoft\WinGet\Packages\Ookla.Speedtest.CLI_Microsoft.Winget.Source_8wekyb3d8bbwe\speedtest.exe" foreach($i in 1..4){ $band = (netsh wlan show interfaces | Select-String 'Band\s+:').ToString().Split(':')[1].Trim() $rssi = (netsh wlan show interfaces | Select-String 'Rssi').ToString().Split(':')[1].Trim() $j = & $exe -s 70970 -f json | ConvertFrom-Json "Run {0} [{1}, RSSI {2}] : DL {3,6:N1} | UL {4,6:N1} | loss {5}" -f ` $i,$band,$rssi,($j.download.bandwidth*8/1MB),($j.upload.bandwidth*8/1MB),$j.packetLoss }

    Record the band and RSSI with every measurement. Without that, the band drift in this case would never have been caught.

    11.3 Single-variable test: IPv6

    Disable-NetAdapterBinding -Name 'Wi-Fi' -ComponentID ms_tcpip6 # take 3 measurements Enable-NetAdapterBinding -Name 'Wi-Fi' -ComponentID ms_tcpip6

    In this case: off 259.7 / 183.5 · on 254.3 / 180.5 → a 2% difference = noise → re-enabled.

    Don't count anything under 5% as a gain. The natural variance of Wi-Fi measurements is larger than that.

    11.4 Interpret the result honestly

    The real table for this case:

    • Download avg: 199.0 Mbps — 263.0 Mbps — +32%

    • DL variance: 3.14× — 1.08× — the real win

    • Upload avg: 143.5 Mbps — 185.3 Mbps — +29%

    • Router ping max: 16 ms — 4 ms — −75%

    • Packet loss: 0% — 0% — —

    Most of the increase in the average comes from the elimination of the "sometimes drops to 88 Mbps" behavior. The ceiling didn't rise; the floor did.

    ---

13. 13

    12. Lessons from this case

    12.1 Methodological

    • Question the complaint. "Slow" was reported; the real problem was "inconsistent." The

    diagnosis changed on that distinction.

    • When a measurement goes bad, question the measurement first, not the settings.

    • Attach context to every measurement (band, RSSI, server). A number without context is useless.

    • Don't apply advice before taking inventory. Half the settings may not exist on your hardware.

    • Be ready to retract your advice after seeing the device. Four recommendations were discarded

    in this case.

    12.2 Technical

    • On Windows 11 the TCP settings are already correct. "TCP optimizer" guides are obsolete.

    • Modern Standby invalidates half of the power-management guides. Check with `powercfg /a`.

    • MTU must be found empirically. It's 1492 on PPPoE, and you find it by pinging the internet,

    not the router.

    • RSSI is the single most important number. "Signal %" is misleading.

    • Wider channels hurt at weak signal. 80 MHz is not always better.

    • The same SSID broadcast on two bands is the most insidious performance problem, and you spot

    it from the last character of the BSSID in `netsh wlan show interfaces`.

    • TKIP is incompatible with 11n/ac — if you see `TKIP&AES` on the router, set it to `AES`.

    12.3 Managing expectations

    Software settings cannot beat physics. The final bottlenecks in this case:

    • Router is Wi-Fi 5: `Radio type: 802.11ac` while the adapter supports `ax` — Replace the router

    • RSSI −71…−77: Channel 2% utilized, only one network visible → no interference, cause is distance — Change location

    • ISP ~260 Mbps: Link 520 Mbps, throughput capped at 263 — Upgrade the plan

    When the software side is done, say so plainly. Hunting for more "tweaks" is wasted time.

    ---

14. 14

    13. Command reference

    Diagnosis (read-only, safe)

    netsh wlan show interfaces # link state, RSSI, band, BSSID netsh wlan show drivers # adapter's theoretical capabilities netsh wlan show networks mode=bssid # neighbors, channel utilization netsh int tcp show global # TCP settings netsh int tcp show supplemental # congestion provider netsh interface ipv4 show subinterface # MTU Get-NetAdapter # adapter list Get-NetAdapterAdvancedProperty -Name 'Wi-Fi' # advanced properties Get-NetAdapterPowerManagement -Name 'Wi-Fi' # power management Get-NetAdapterBinding -Name 'Wi-Fi' # protocol bindings Get-NetIPConfiguration # IP, gateway, DNS powercfg /a # sleep capabilities (Modern Standby?) powercfg /getactivescheme # active power plan

    Measurement

    ping -n 50 <target> # latency, jitter, loss ping -f -l <size> <target> # MTU discovery speedtest -L # server list speedtest -s <id> -f json # test on a pinned server Resolve-DnsName -Name <host> -Server <dns> # DNS timing

    Changing (requires administrator)

    Set-NetAdapterAdvancedProperty -Name 'Wi-Fi' -RegistryKeyword <kw> -DisplayValue <val> -NoRestart Disable-NetAdapterBinding -Name 'Wi-Fi' -ComponentID <id> Enable-NetAdapterBinding -Name 'Wi-Fi' -ComponentID <id> Set-DnsClientServerAddress -InterfaceAlias 'Wi-Fi' -ServerAddresses '1.1.1.1','1.0.0.1' netsh interface ipv4 set subinterface "Wi-Fi" mtu=<n> store=persistent Restart-NetAdapter -Name 'Wi-Fi' -Confirm:$false

    Rollback

    Checkpoint-Computer -Description "..." -RestorePointType MODIFY_SETTINGS Get-ComputerRestorePoint Restore-Computer -RestorePoint <SequenceNumber> # reboots the machine

    ---

15. 15

    Appendix: Writing the rollback script

    Collect every change into a single script. Watch out for:

    1. If the file contains non-ASCII characters, save it as UTF-8 with BOM. PowerShell 5.1 reads BOM-less UTF-8 as ANSI and throws syntax errors on non-ASCII characters.

    $txt = [System.IO.File]::ReadAllText($path, [System.Text.Encoding]::UTF8) [System.IO.File]::WriteAllText($path, $txt, (New-Object System.Text.UTF8Encoding($true)))

    2. Validate the syntax without running it:

    $err=$null [System.Management.Automation.PSParser]::Tokenize((Get-Content $path -Raw),[ref]$err) | Out-Null if ($err.Count) { $err | ForEach-Object { "line $($_.Token.StartLine): $($_.Message)" } } else { "OK" }

    3. Verify the target before writing to the registry:

    $d = (Get-ItemProperty $key).DriverDesc if ($d -notmatch 'Realtek 8852CE') { throw "Wrong adapter: $d" }

    4. Preserve the difference between "the value was absent" and "the value was 0." If it was absent, use `Remove-ItemProperty` — do not write `0`. They mean different things.

    5. Note in a comment that router changes cannot be rolled back by the script.

    ---

16. 16

    Related files

    • `network-tuning-log.md` — all raw data from this case, old and new values

    • `rollback-network.ps1` — executable script that reverts every change

    • `wifi-optimizasyon-rehberi.md` — Turkish version of this guide

    • `wifi-optimization-guide-RU.md` — Russian version of this guide