Reading a WLAN Pros Toolbox Connection Report

Someone sent you a block of plain text that starts with WLAN Pros Toolbox: Connection Report. They ran the "Check My Connection" (Test My Connection) tool in the WLAN Pros Toolbox, hit Copy, and pasted you the result. This guide tells you how to read it and what to do next.

The report answers one question: is the slow part the Wi-Fi link, or the internet upstream? Everything in it serves that single decision. The tool measures the Wi-Fi link (the radio hop between the device and the access point) separately from the internet connection (the path from the home or office out to the wider internet), then compares the two so you do not have to guess which side to chase.

The report never invents a value. Anything the device could not read prints Unavailable (Wi-Fi link facts) or Not measured (internet metrics). A blank or a fabricated number never appears, so an Unavailable is information, not a glitch.

What the report looks like

The copied text is plain text organized into labeled sections, always in this order:

Header: title, timestamp, and a one-line summary verdict
WI-FI: the radio link facts (network name, signal, rates, channel)
INTERNET: the measured speed test results
DNS: name-resolution time
NETWORK: local addressing on the device
ISP: public IP and provider (only when the lookup succeeded)
CLOUD APPS: reachability of common services (only when that panel ran)
VERDICT: the plain-language result and the direct comparison

Sections 6 and 7 are omitted entirely when their data did not land (offline, lookup failed, or the panel was not shown). Their absence is not an error.

How to read it: the fast path

If you only have ten seconds, read two lines:

The Summary line in the header (Summary: Wi-Fi Strong · Internet Weak)
The Result line in the VERDICT section

Those two carry the answer. The Summary grades each side independently; the Result names the limiter. The rest of the report is the supporting evidence behind that call, and it is where you go when the headline does not match what the user is experiencing.

Field-by-field

Ranges below are practical reading aids. Where a threshold is the Toolbox's own grading band, it is labeled as such; those are the cut points the app uses on screen, not a published industry standard. Wi-Fi link health depends heavily on band, distance, and what the device is doing, so treat the Wi-Fi numbers as directional rather than pass/fail.

Header

Generated: the test date, time, and platform (for example Jun 25, 2:14 PM on macOS). Use this to confirm the report is recent. A report from yesterday tells you little about a problem happening now.
Summary: the two-axis grade, Wi-Fi <tier> · Internet <tier>. Each side is graded Strong, Moderate, Weak, or Couldn't check. This is the single most useful line. Two Strong reads and a user still complaining points you at something the tool does not measure (a specific app, DNS, a remote server, a VPN), not at the local link or the pipe.

WI-FI

These come from the device's Wi-Fi radio. On macOS the system reads them through CoreWLAN; on iOS they arrive through the companion Shortcut plus the native network read; on Android and Windows through the platform Wi-Fi APIs. If the user is on a wired connection, or on iOS without the Shortcut capture, most of this section reads Unavailable by design, and the verdict leans on the internet measurement alone.

Network (SSID): the Wi-Fi network name. On macOS this is hidden unless the app has Location access, in which case it reads Unavailable (grant Location access to show the network name). That specific wording means the data exists but the OS is gating the name, not that the tool failed.
BSSID: the MAC address of the specific access point radio the device is joined to. Useful when you suspect the device is stuck on a distant AP. Same macOS Location gating as the SSID.
RSSI: received signal strength, in dBm. More negative is weaker. Practical reading: stronger than -60 dBm is excellent; -60 to -67 dBm is solid; -68 to -75 dBm is workable; -76 to -77 dBm is marginal; weaker than -77 dBm is troublesome. These are practical field reading aids; the app does not grade RSSI numerically.
Noise: the noise floor, in dBm. More negative is better (less background noise). A typical clean noise floor sits near -90 dBm or lower. On its own it means little; it matters as the other half of SNR.
SNR: signal-to-noise ratio, in dB, the gap between RSSI and the noise floor. Higher is better. This is often a better health indicator than RSSI alone. Practical reading: above 25 dB is comfortable for high data rates; 15 to 25 dB is workable; below 15 dB is where rates fall off. These are practical field reading aids; the app does not grade SNR numerically.
Wi-Fi Down (Rx rate): the negotiated receive data rate, in Mbps. This is the device-to-AP link speed for incoming data, not a throughput measurement. On macOS this reads Unavailable (not exposed on macOS), which is a known platform limit, not a glitch. iOS supplies it.
Wi-Fi Up (Tx rate): the negotiated transmit data rate, in Mbps. This is the link speed the verdict leans on most. The tool estimates usable Wi-Fi throughput at about 55% of the average of Tx and Rx, because real-world Wi-Fi throughput runs roughly 50 to 60 percent of the negotiated PHY rate. A low Tx rate relative to a healthy internet speed is the classic signature of a Wi-Fi-limited connection.
Channel: the Wi-Fi channel number. A value of 0 is the "no/unknown channel" sentinel some systems return and prints as Unavailable rather than a misleading 0. The channel tells you the band (1 to 14 is 2.4 GHz; 36 and up is 5 GHz or 6 GHz) and is your starting point for a co-channel or interference investigation.
Channel width: the channel width in MHz (20, 40, 80, 160). Wider is faster but more prone to interference. A device sitting on 20 MHz when wider is available can be a clue, though Wi-Fi will narrow width deliberately under contention.
Band: 2.4 GHz, 5 GHz, or 6 GHz. A device parked on 2.4 GHz when 5 GHz is available is a frequent cause of "the Wi-Fi is slow." 2.4 GHz is slower, more congested, and more interference-prone.
Standard (PHY): the Wi-Fi generation in use (for example Wi-Fi 5, Wi-Fi 6). An old standard on a new network can cap performance.
Security: the security scheme (WPA2-Personal, WPA3, and so on), or Unavailable when the platform did not report it.
Note: appears on iOS only, when the Wi-Fi signal details were not captured. It means the RF rows above are a missing capture step, not a failure: the user needs to tap "Capture Wi-Fi details" in the app to read them through the companion Shortcut.

INTERNET

These come from the speed test the tool runs against a public endpoint: a short download window, a short upload window, and a loaded-responsiveness probe, roughly 25 to 35 seconds total.

Internet Down: measured download throughput, in Mbps. Compare it against the user's plan. The Toolbox's own grading bands: Excellent at 100 Mbps and up, Good at 25 Mbps and up, Fair at 5 Mbps and up, Poor below 5 Mbps. Note that this is a single-flow web measurement, so it can read lower than a multi-connection speed test on a fast line. That gap is expected and is the subject of the companion methodology piece.
Internet Up: measured upload throughput, in Mbps. Toolbox grading bands: Excellent at 20 Mbps and up, Good at 5 Mbps and up, Fair at 1 Mbps and up, Poor below 1 Mbps. Upload matters for video calls, cloud backup, and uploads; a healthy download with a starved upload explains a lot of "my video keeps freezing" complaints.
Latency: round-trip delay, in ms. Lower is better. Toolbox grading bands: Excellent below 20 ms, Good below 50 ms, Fair below 100 ms, Poor at 100 ms and up. (The app grounds the direction in ITU-T G.114 voice guidance; the exact cut points are the app's own.)
Jitter: variation in latency, in ms. Lower is better. Toolbox grading bands: Excellent below 5 ms, Good below 15 ms, Fair below 30 ms, Poor at 30 ms and up. High jitter on a healthy-looking link is a top suspect for choppy calls.
Loss: packet loss, in percent. Lower is better. Toolbox grading bands: Excellent at 0%, Good below 1%, Fair below 2.5%, Poor at 2.5% and up. Any sustained loss above ~1% noticeably degrades real-time traffic.
Responsiveness: round-trips per minute (RPM) under load, the connection's bufferbloat behavior. Higher is better. Toolbox grading bands: Excellent at 1000 RPM and up, Good at 500 RPM and up, Fair at 100 RPM and up, Poor below 100 RPM. (Grounded in RFC 9097 and Apple's networkQuality; the value here is a simplified single-flow estimate, not a full multi-flow RPM, and the app says so.) A connection with good throughput but poor responsiveness is the textbook bufferbloat case: fine on a speed test, miserable on a call while something is uploading.

DNS

Resolution time: how long a name lookup took, in ms, with the resolved host noted, or Not available when no probed host resolved. This is a real measurement of the device's configured resolver, not anything the speed-test engine produces. Slow or failing DNS makes everything feel broken while raw speed reads fine; this row catches that. A few tens of ms is normal; hundreds of ms or Not available is worth chasing.

NETWORK

Local addressing on the device. The first three are read directly; the last three are honestly unavailable on these platforms and say why rather than guessing.

Local IP address: the device's address on the local network. A 169.254.x.x address means the device failed to get a real lease (no DHCP), which is itself a finding.
Subnet mask: the local subnet mask.
Default gateway: the local router/gateway address. A common first ping target when you start troubleshooting.
DHCP server, DNS server(s), VLAN tag: these carry the precise reason they are absent rather than a value, because the platform does not expose them in a sandbox-safe way. Do not read their absence as a fault.

ISP

Present only when the public-IP lookup succeeded. Tells you what the connection looks like from the outside.

Public IP: the public-facing IP address.
ISP / org: the internet provider or organization that owns the address. Tells you who to call if the verdict points upstream.
ASN: the provider's autonomous system number.
Approx. location: the geolocated area of the public IP. Approximate, and often the provider's regional point rather than the user's exact location.

CLOUD APPS

Present only when the cloud-apps panel ran. The header reads CLOUD APPS REACHABLE (N of M), then each service lists reachable (with a connect time) or unreachable. This is a fast triage layer: if the link and internet both read fine but one specific service is unreachable, the problem is that service or its path, not the user's connection. It also confirms the device is genuinely online even when the speed test stalls.

VERDICT

The plain-language answer, restating what the header summary graded.

Result: names the limiter in one sentence. The wording the tool produces:

Your Wi-Fi is the weak link right now. Usable Wi-Fi capacity is clearly below the measured internet. Chase the Wi-Fi link.
Your internet is the limit right now, not your Wi-Fi. Usable Wi-Fi clearly exceeds the measured internet. Chase the ISP / modem / plan.
Both your Wi-Fi and your internet are keeping up. Or a same-tier line noting which side has slightly more headroom. Neither is the obvious culprit; look past both.
We measured your internet, but could not read your Wi-Fi on this device. The link could not be read (wired, or iOS without a capture). The verdict rests on the internet side only.
You are online. Your internet is reachable, but the speed test did not complete... The device is confirmed online by DNS, public IP, and cloud reachability, but throughput did not measure. Re-run.

Comparison: the direct head-to-head, shown only when both sides measured. For example Your Wi-Fi link is 64% slower than your internet connection. or ...running at about the same speed. Within plus or minus 10% the two read as "about the same." Large gaps switch to a multiple ("about 12x faster") and past ~100x to "far faster / slower." This line is the quantified version of the Result.

Other tests worth running

The report is a snapshot from one tool. When the verdict is ambiguous, or you want to confirm it before acting, these add the missing dimension:

A saturating multi-connection speed test (the user's normal speed-test site or app). The Toolbox uses a single-flow web measurement, which can read lower than a multi-stream test on a fast line. Running both tells you whether a low Internet Down is a real upstream limit or just the measurement method. This is the heart of the companion methodology piece on why numbers differ.
iPerf between two devices on the LAN. This measures actual local throughput end to end, independent of the internet. When the Wi-Fi link looks weak, iPerf from the device to a wired host on the same network confirms whether the Wi-Fi hop is genuinely the bottleneck.
A ping or ping-plot to the default gateway, then to a public host. This separates "the local network is dropping" from "the path to the internet is dropping." The gateway address is right there in the NETWORK section. (The Toolbox has Ping and Ping Plotter tools for this.)
A look at the AP, band, and channel. The WI-FI section gives you band, channel, and width. Confirm the device is on the band you expect (5 GHz or 6 GHz, not 2.4 GHz) and that the channel is not buried under co-channel contention or a non-Wi-Fi interferer. (The Toolbox's AP Scan and channel reference tools help here.)
A DNS check against an alternate resolver. If the DNS row is slow or Not available, point the device at a known-good resolver and re-test. Slow DNS masquerades as a slow connection.

Where to go next

Read the Result line, then follow the branch:

If the report points to the Wi-Fi link (Your Wi-Fi is the weak link, or a weak Tx rate against a healthy internet speed), the fix is on the radio side:

Check the band: move the device off 2.4 GHz onto 5 GHz or 6 GHz if it is parked low.
Check distance and placement: a weak RSSI / low SNR means the device is too far from the AP, or there is too much between them. Move closer, or improve AP placement.
Check the channel: co-channel contention and interference drag rates down even at strong signal. Pick a cleaner channel.
Check width: confirm the AP is not stuck narrow when it could run wider.
Walk the user around: have them re-run the test in the same room as the AP. If the verdict flips to "internet is the limit" up close, you have confirmed the Wi-Fi link as the variable.

If the report points upstream (Your internet is the limit right now, not your Wi-Fi, or healthy Wi-Fi rates against a low Internet Down/Internet Up), the fix is on the internet side:

Compare Internet Down and Internet Up against the plan the user pays for. A big shortfall is an ISP or modem conversation. (First confirm with a saturating multi-connection speed test, since the Toolbox's single-flow number can read low on a fast line.)
Check the modem/ONT and the gateway: reboot, check for service alerts, look for a failing modem.
Use the ISP / org line to know who to call.
If Responsiveness is poor while throughput is fine, raise bufferbloat with the ISP, or enable smart-queue management on the router if available.

If both sides look fine but the user still has a problem, the bottleneck is past both the link and the pipe: a specific application, a remote server, a VPN, or DNS. Use the CLOUD APPS and DNS sections to narrow it, and look at the one app or site that is actually slow rather than the connection as a whole.

The reason this report is worth trusting on the link-versus-upstream call is that the Toolbox measures the two separately and compares them on the same basis. It isolates the Wi-Fi link from the internet, so when it says "Wi-Fi" or "internet," it is comparing usable Wi-Fi capacity against the measured internet rate, not guessing from a single number. That is also why its internet figure can differ from a multi-stream speed test: different tools answer different questions. For the full reasoning on that gap, see the companion piece on why speed results differ.

This guide pairs with the WLAN Pros Toolbox "Check My Connection" (Test My Connection) tool and the companion methodology piece on why speed-test numbers differ. It describes the copy-paste report exactly as the tool produces it. The RSSI and SNR ranges are practical field reading aids; all internet grading bands are the app's own thresholds.