Picture courtesy of Meta

High‑density Wi‑Fi doesn’t fail because access points (APs) are weak. It fails because the airspace gets full.

Wi‑Fi is a shared medium. Every device in the room must take turns using the same channel. When too many devices need airtime at the same time, the AP cannot schedule transmissions fast enough — not because the hardware is slow, but because the RF channel is saturated.

To understand this, we need three simple concepts:

• Throughput

• Airtime demand

• Available airtime

Key Definitions

Per‑AP Throughput

This is the amount of data an AP must deliver based on how many devices are connected.

Example: If 100 devices each need 1 Mbps, the AP must deliver:

100 Mbps of throughput

What does 1 Mbps look like?

Typical 1 Mbps activities include:

• basic web browsing

• cloud‑based testing platforms

• simple video playback

• lightweight file sharing

• messaging apps

These are common in classrooms and testing environments.

Per‑AP Airtime Demand

This is how much actual radio time is required to deliver that throughput.

Wi‑Fi is only 20–35% efficient because devices must wait, contend, retry, and share the channel. So we multiply throughput by 3–5× to estimate airtime demand.

Example: 100 Mbps throughput × 3–5 = 300–500 Mbps airtime demand

This happens because Wi‑Fi is a half‑duplex channel — only one device can transmit at a time. Every packet occupies the channel for a certain amount of time, and when too many devices need airtime at once, the AP cannot queue and schedule transmissions fast enough. The RF medium becomes saturated, not the AP hardware.

This is the number that determines whether the AP can serve all connected clients.

Why Airtime Depends on Packet Duration

Wi‑Fi airtime isn’t consumed by “how much data” you send — it’s consumed by how long the transmission occupies the channel.

Every Wi‑Fi frame has a duration, based on:

• the data rate the client is using

• the size of the frame

• the overhead (headers, acknowledgments, backoff)

• the environment (interference, retries, contention)

High data rate = short airtime

A client transmitting quickly uses the channel for a very short time.

Lower data rate = longer airtime

A client transmitting more slowly occupies the channel for a longer time — even if the packet is small.

This is why airtime demand grows rapidly in dense rooms: packets take longer to send, and the AP cannot schedule transmissions fast enough.

Throughput vs Airtime Duration

Two clients each need to send 1 Mbps of data.

• Client A transmits quickly

• Client B transmits more slowly

They both send the same amount of data, but:

• Client A uses the channel for a tiny fraction of a second

• Client B uses the channel for much longer

So even though both need “1 Mbps throughput,” Client B consumes far more airtime.

This is why throughput must be multiplied by 3–5× to estimate airtime demand — because real‑world transmissions often take longer than expected.

Available Airtime per AP (Highway Analogy)

Available airtime is how much usable transmission time an AP has in one second.

Think of Wi‑Fi airtime like a single‑lane highway:

• Only one car can drive at a time

• Every car must wait its turn

• Slower cars block the lane longer

• Traffic lights (contention rules) decide who goes next

• Accidents (collisions) cause delays

This is why Wi‑Fi is a shared medium.

Real‑world available airtime (Enterprise AP)

Even though an Enterprise AP can support gigabit speeds, in a crowded room it typically has:

~120 Mbps of usable airtime

That 120 Mbps is the total lane time available.

Example: Airtime demand vs available airtime

If an AP needs to deliver 200 Mbps of throughput, airtime demand becomes:

200 Mbps × 3–5 = 600–1000 Mbps airtime demand

But the AP only has 120 Mbps of usable airtime.

The highway is jammed. The AP’s ability to queue and schedule traffic breaks down — not because the hardware is weak, but because the airspace is full.

The AP is still powered on, still broadcasting, still “up,” but the RF medium cannot accept more transmissions.

📊 Application Throughput Requirements

Credit: Cisco U. Training Designing Cisco Enterprise Wireless Networks (ENWLSD)

The three most important rows for high‑density rooms are:

• Casual file sharing

• Online testing

• Device backups

These determine whether the airspace stays healthy or becomes overloaded.

**📡 Capacity Reality Check

200 People • Enterprise APs • Real‑World Distribution**

Let’s set the stage clearly:

✔ The design is good

Five Enterprise APs in a single room is strong.

✔ But people are not evenly distributed

Some APs will see twice as many clients as others.

✔ And people have multiple devices

Most carry 2–3 active Wi‑Fi devices, not one.

So instead of 200 devices evenly spread across 5 APs, the real world looks more like:

• 400–600 devices total

• 80–120 devices per AP (unevenly distributed)

This is the number that actually drives airtime consumption.

📋 Realistic Per‑AP Load (Uneven Distribution + Multi‑Device Users)

🟢🟡🔴 Stoplight Capacity Graphic (200‑Person Room)

🟢 GREEN — Casual File Sharing (1 Mbps per user)

• Per‑AP throughput: 80–120 Mbps

• Per‑AP airtime: 240–600 Mbps

• Available airtime: ~120 Mbps

Verdict: GREEN — Barely.

Casual file sharing is green only at the low end. APs running 80 Mbps of load are fine. APs running 120 Mbps are at the ceiling.

This is “green,” but it’s fragile green.

🟡 YELLOW — Online Testing (2–4 Mbps per user)

• Per‑AP throughput: 160–480 Mbps

• Per‑AP airtime: 480–2400 Mbps

• Available airtime: ~120 Mbps

Verdict: YELLOW — The airspace is overloaded on most APs.

At 2 Mbps per user, many APs already exceed their available airtime. At 4 Mbps, every AP’s airspace is saturated.

This is not a hardware problem. The AP radios, CPU, and memory are fine.

What fails is the RF medium itself — the shared airtime.

When airtime demand exceeds available airtime:

• the channel stays busy

• devices wait too long for clear‑channel access

• retries multiply

• latency spikes

• queues fill

• clients disconnect or roam poorly

• applications freeze

The AP is still powered on, still broadcasting, still “up,” but the airspace is full and the AP can no longer queue and schedule traffic fast enough to serve all connected clients.

🔴 RED — Device Backups (10–50 Mbps per user)

• Per‑AP throughput: 800–6000 Mbps

• Per‑AP airtime: 2400–30,000 Mbps

• Available airtime: ~120 Mbps

Verdict: RED — Physically impossible.

Even with perfect AP distribution, this was impossible. With real‑world distribution, it becomes catastrophic.

Backups will:

• saturate radios

• overwhelm the airspace

• starve every other application

• destroy testing, video, voice, everything

This is not a Wi‑Fi design issue. This is a device‑behavior issue.

High‑Density Best Practices

Use 20 MHz channels

Why? Because wider channels (40/80 MHz):

• consume airtime faster

• reduce channel reuse

• increase interference

• amplify congestion

20 MHz channels maximize stability and airtime efficiency.

Client on 5 GHz and 6 GHz

Why? Because these bands:

• have more spectrum

• have less interference

• offer more available airtime

Ensure clean 5 GHz and 6 GHz spectrum

Why? Because unnecessary SSIDs, overhead, and co‑channel interference all consume airtime.

Reduce AP transmit power

Why? Because smaller cells reduce contention and prevent APs from hearing too many clients.

Mount APs above head height

Why? Because it reduces client‑to‑client interference and improves line‑of‑sight.

🎯 Final Summary (200‑Person Room)

Casual File Sharing:     🟢 GREEN — Barely. Some APs hit the ceiling.
Online Testing:          🟡 YELLOW — Airspace overloaded on most APs.
Device Backups:          🔴 RED — Physically impossible.

As wireless engineers, we spend years learning how to analyze RF environments, interpret heatmaps, troubleshoot interference, and design networks that perform well. The challenge often isn’t understanding the technology—it’s explaining the results in a way that customers, managers, and future engineers can easily understand.

Recently, I completed a Wi‑Fi assessment for a clinic. The report included heatmap snapshots, infrastructure details, RF observations, upgrade recommendations, and security considerations. The engineering analysis, site survey, and conclusions were all mine. What I wanted help with was turning those technical findings into simple explanations that the customer could keep as a long-term reference.

That’s where Microsoft Copilot came in.

Using Copilot as a Technical Writing Partner

My goal wasn’t to have AI perform the engineering. The engineering work had already been completed through site surveys, heatmaps, and analysis of the wireless environment.

Instead, I used Copilot to help answer a different question:

“How do I explain this in a way that makes sense to someone who isn’t a wireless engineer?”

The report included heatmap screenshots showing coverage and RF conditions throughout the clinic. I wanted every image and finding to have a simple explanation underneath it—something a customer could understand today and a future engineer could reference years from now.

Rather than writing every explanation from scratch, I started asking Copilot questions.

Some examples included:

• Please explain what a heatmap is and how it helps with Wi‑Fi troubleshooting.

• Explain why seeing 47 neighboring access points is challenging.

• Explain how SSIDs contribute to a crowded wireless environment.

• Why is Channel 2 a poor choice?

• Explain Channel 8 using the same style.

• Integrate how 6 GHz can help reduce the impact of neighboring networks.

• Make this customer friendly.

• Keep it concise.

As the conversation evolved, so did the report.

Turning Data into a Story

One heatmap observation showed something interesting:

47 neighboring access points and their associated SSIDs.

As engineers, we immediately understand why that’s noteworthy.

A customer may not.

Copilot helped translate that observation into language that explained the impact:

Large numbers of nearby access points and SSIDs increase competition for airtime, channel reuse, and wireless overhead, all of which can affect Wi‑Fi performance.

The engineering conclusion didn’t change.

The explanation became easier to understand.

Explaining Heatmaps Without RF Jargon

One of my goals was to make the report useful long after I handed it over.

When a customer opens the document six months from now, I don’t want them wondering what the colors on a heatmap mean.

Using Copilot, I added simple descriptions alongside the screenshots:

• Green = good performance

• Yellow = acceptable performance

• Orange/Red = potential problem areas

• Gray = little or no coverage

That kind of explanation may seem simple, but it significantly increases the value of the report for non-technical readers.

Making Upgrade Recommendations Clear

The clinic is currently served by three Cisco Meraki MR56 access points, providing solid 5 GHz coverage.

The engineering analysis also identified a dense RF environment caused by neighboring networks.

The recommendation was to consider future upgrades to Cisco CWxxx access points with 6 GHz capability.

Again, the challenge wasn’t arriving at the recommendation.

The challenge was explaining why.

Copilot helped convert technical specifications into customer-focused benefits:

• Additional wireless spectrum

• More available channels

• Reduced congestion

• Less impact from neighboring networks

• Better performance for compatible devices

That’s a much more meaningful explanation than simply stating that a device supports Wi‑Fi 6E.

Creating a Report That Lasts

One unexpected benefit of using Copilot was that the final document became more than a project report.

It became a reference guide.

The report now contains:

• Heatmap screenshots

• Coverage explanations

• RF observations

• Neighboring AP analysis

• SSID considerations

• 6 GHz recommendations

• Security considerations

• Rogue access point risks

• Customer-friendly explanations of technical concepts

A clinic manager can understand the findings.

A future network engineer can understand the reasoning.

And both audiences can use the document as a reference point going forward.

AI Didn’t Do the Engineering

This is the most important point.

Copilot didn’t perform the survey.

Copilot didn’t collect the heatmaps.

Copilot didn’t identify the neighboring access points.

Copilot didn’t determine that 6 GHz could be beneficial.

The engineering analysis remained entirely human.

What Copilot did was help package that analysis into a polished, readable, customer-focused document.

It helped answer the question every engineer eventually faces:

“How do I explain this to someone who isn’t me?”

For technical professionals, that’s where AI can provide tremendous value—not replacing expertise, but helping communicate it more effectively.

The result was a stronger report, clearer explanations, and a document that will continue to provide value long after the assessment is complete.

Picture courtesy of CoPilot

The Wi-Fi Standards Challenge

The perfect Wi-Fi protocol and standards brush-up to play on your phone while you’re commuting... as long as you’re not driving.

If you’ve ever looked at a wireless design question and thought:

“I know I’ve seen that 802.11 number before...”

this game is for you.

🎮 ROUND 1 – Wi‑Fi Generations

🛑 STOP

Make your matches before scrolling.

✅ ROUND 1 ANSWERS

1-E, 2-B, 3-C, 4-D, 5-A, 6-F, 7-G

🎮 ROUND 2 – Wi‑Fi Alliance Naming

🛑 STOP

Do not scroll until you’ve picked all four.

✅ ROUND 2 ANSWERS

1-C, 2-B, 3-D, 4-A

🎮 ROUND 3 – Backward Compatibility

The differentiator is exactly which legacy technology remains supported.

🛑 STOP

Question #7 is usually what gets people.

✅ ROUND 3 ANSWERS

1-A, 2-B, 3-C, 4-D, 5-E, 6-F, 7-G

🎮 ROUND 4 – Management Protocols

🛑 STOP

✅ ROUND 4 ANSWERS

1-C, 2-B, 3-A, 4-D, 5-E, 6-F, 7-G

🎮 ROUND 5 – Security

🛑 STOP

Do the matching first.

✅ ROUND 5 ANSWERS

1-B, 2-A, 3-C, 4-D, 5-E, 6-F, 7-G

Picture from CoPilot

Imagine a playground with only one slide that everyone wants to use.

Meet the Cat with the Birthday Cake

Imagine a playground with one slide.

At the top of the slide is a cute orange cat carrying a pink birthday cake with a candle. 🎂

The cat represents a voice call.

The other cats represent:

• 📺 Video traffic

• 🌐 Web traffic

• 📦 File downloads (FTP)

Everyone wants to use the slide, but only one cat can go at a time.

DCF (Distributed Coordination Function) - 1997

DCF was part of the original Wi‑Fi standard from 1997.

In DCF, every cat follows the exact same rules:

1. Wait until the slide is free.

2. Wait a little longer.

3. Start counting down.

4. Race for the slide.

This sounds fair... until two cats reach zero at the same time.

💥 BONK!

They crash into each other.

In Wi‑Fi, this is called a collision.

Imagine two cats trying to preserve the same birthday cake by both diving onto the slide at once.

Nobody wins.

The cake ends up on the playground.

DIFS (DCF Interframe Space)

DIFS = Distributed Coordination Function Interframe Space

That’s a very fancy way of saying:

“The amount of time everyone waits before starting their countdown.”

Think of DIFS as:

“OK cats, count to five before running!”

Every cat waits the same amount.

QoS (Quality of Service) - 802.11e (2005)

Around 2005, Wi‑Fi engineers realized:

“Maybe the cat carrying a birthday cake should go before the cat carrying a huge box of toys.”

That idea became QoS.

QoS = Quality of Service

QoS helps important traffic get through faster.

Examples:

Traffic Type Priority
Voice calls Highest
Video calls High
Web browsing Medium
File downloads Lower

The birthday cake cat suddenly became very important.

*Per Tom Carpender
”Pretty cool analogy for beginners. Only thing I’d pick at as iffy is the web vs. ftp traffic since the Wi-Fi drivers will just use layer 3 priorities and web and ftp will likely be untagged. But I like the slide analogy representing the medium.”

EDCA (Enhanced Distributed Channel Access) - 2005

EDCA is the main QoS method introduced with 802.11e.

Instead of making all cats wait the same amount of time:

• Voice cat waits less

• Video cat waits a little more

• Web cat waits longer

• FTP cat waits the longest

This dramatically reduces collisions.

Because the birthday cake cat gets a head start.

🎂🐱 “Excuse me everyone, this candle is lit!”

AIFS (Arbitration Interframe Space)

AIFS = Arbitration Interframe Space

Think of AIFS as:

“How long your cat waits before starting the countdown.”

Examples:

• Voice traffic → very short AIFS

• Video traffic → short AIFS

• Web traffic → normal AIFS

• FTP traffic → longer AIFS

So if Voice Cat and FTP Cat both pick the same countdown number:

Voice Cat starts earlier.

Voice Cat reaches zero first.

Voice Cat slides away with the cake.

FTP Cat patiently waits.

No collision.

No cake disaster.

TXOP (Transmission Opportunity) - 2005

Now comes the really clever part.

Without TXOP:

🐱

• Go down the slide once.

• Get back in line.

• Wait again.

• Go down once.

• Get back in line.

That’s a lot of waiting.

With TXOP:

🐱🎂

Once the cat gets permission to use the slide:

• Slide once.

• Slide again.

• Slide again.

• Slide again.

And nobody interrupts.

TXOP = Transmission Opportunity

A TXOP is:

“A reserved amount of time that a device gets to keep talking.”

This helps voice and video traffic stay smooth.

The cat doesn’t have to keep climbing back up the ladder.

SIFS (Short Interframe Space)

SIFS = Short Interframe Space

This is the shortest waiting time in Wi‑Fi.

During a TXOP, frames can be sent with tiny pauses called SIFS between them.

Think of SIFS like:

🐱 “Slide...” tiny breath “Slide...” tiny breath “Slide again!”

The cat keeps moving instead of waiting in the big line every time.

The Big Picture

DCF (1997)

All cats are treated equally.

Pro: Fair.

Con: Lots of collisions and waiting.

EDCA / QoS (2005)

Important traffic gets a head start.

Pro: Voice and video work much better.

Con: The FTP cat complains occasionally.

TXOP (2005)

Once a cat gets the slide, it can use it several times before leaving.

Pro: Faster, more efficient Wi‑Fi.

Con: The birthday cake cat starts feeling pretty important. 🎂🐱

One-Sentence Engineer Version

DCF (1997) makes every station wait the same amount of time, while 802.11e EDCA/WMM (2005) uses AIFS and TXOP to give voice and video traffic faster access to the wireless medium and more efficient transmission opportunities.

One of the biggest advantages of Marvis Minis is that they don’t simply check whether an access point is online—they verify that users can actually use the network.

Think about everything that has to happen before someone can connect to Wi-Fi and open an application. Marvis Minis walk through many of these same steps by acting as a virtual wireless client.

If any step fails, Mist knows exactly where the process stopped.

Figure 1. The Marvis Mini Validation Process

          Start Test
               │
               ▼
      Join Wireless SSID
               │
               ▼
 Authenticate (802.1X/PSK)
               │
               ▼
     Obtain DHCP Address
               │
               ▼
     Verify ARP / Gateway
               │
               ▼
      Resolve DNS Name
               │
               ▼
 Reach Configured Applications
               │
               ▼
      ✓ Test Successful

   If any step fails:
        • Record the failure
        • Generate Marvis Actions
        • Correlate with the Trouble Tree
        • Alert administrators

Rather than simply reporting that “Wi-Fi is down,” Marvis Minis identify which step failed, dramatically reducing troubleshooting time.

1. Wireless Association

The Mini first verifies that it can associate with the configured SSID, just like a laptop or smartphone.

Failures here may indicate:

• SSID configuration issues

• RF coverage problems

• Access point availability

• Client association problems

Where to find it:

• Marvis Minis dashboard

• Marvis Actions

• Trouble Tree (when client issues are investigated)

2. Authentication

After joining the SSID, the Mini authenticates using the configured security method.

For Enterprise SSIDs, this typically means communicating with your RADIUS server.

Failures may indicate:

• RADIUS server unavailable

• Certificate problems

• Shared secret mismatch

• Authentication server connectivity issues

Where to find it:

• Marvis Minis dashboard

• Marvis Actions

• Trouble Tree

3. DHCP

Once authenticated, the Mini requests an IP address.

This is one of the most common causes of user complaints because clients can appear connected while having no network connectivity.

Common causes include:

• DHCP server outage

• VLAN configuration errors

• Missing trunk VLANs

• DHCP scope exhaustion

• Relay configuration issues

Where to find it:

• Marvis Minis dashboard

• Marvis Actions

• Trouble Tree

4. ARP (Gateway Verification)

Next, the Mini verifies that it can communicate with the default gateway using ARP.

This confirms that basic Layer 2 connectivity is functioning correctly.

Failures often point toward:

• Switching issues

• Incorrect VLAN assignments

• Gateway connectivity problems

Where to find it:

• Marvis Minis dashboard

• Trouble Tree

5. DNS Resolution

Now the Mini verifies that DNS is working.

Many users describe every outage as “the Wi-Fi is down,” when in reality the wireless connection is healthy and only DNS has failed.

Possible causes include:

• DNS server outage

• Firewall changes

• Incorrect DNS configuration

• Upstream network issues

Where to find it:

• Marvis Minis dashboard

• Marvis Actions

• Trouble Tree

6. Application Reachability

Finally, the Mini attempts to reach the applications you’ve configured for monitoring.

These might include:

• Microsoft 365

• Google Workspace

• Zoom

• Internal web applications

• Business-critical services

This is often the final piece of the puzzle.

For example:

• Wireless Association ✔

• Authentication ✔

• DHCP ✔

• DNS ✔

• Microsoft 365 ✖

In this case, the wireless network is operating normally—the issue lies with the application or upstream network.

Where to find it:

• Marvis Minis dashboard

• Marvis Actions

• Trouble Tree

How Do You Know Marvis Minis Are Working?

Marvis Minis don’t operate silently in the background without visibility. They have their own dashboard where you can verify they’re actively running tests.

Navigate to Marvis → Minis to view:

• Current status

• Last successful test

• Historical test results

• Failed validation steps

• Manual Test Now option

Whenever a Mini detects a failure, those results don’t stay isolated. They feed directly into Marvis Actions and become correlated evidence within the Trouble Tree, alongside telemetry from clients, access points, switches, and WAN links.

Instead of guessing where a problem started, Marvis helps guide you directly to the failing step in the connectivity process.

This new capture tells a very different and much more interesting story. The biggest change is that this is one AP, and the dominant behavior is no longer infrastructure overhead — it is client-generated QoS Null traffic.

For a blog article, I would frame this as:

“The Wi-Fi Is Healthy… So Why Is 1 Out of Every 5 Frames Doing Nothing?”

Your capture is a great example of why packet captures matter. A dashboard may show a healthy AP, good signal, and low retries, yet the airtime story can reveal hidden client behavior.

Wi-Fi Airtime Health Report Card

One AP — 60 Second Packet Capture Analysis

Capture Summary

MetricValueCapture Duration60 secondsTotal Frames Captured90,877APs Captured1

Executive Summary

This packet capture shows a healthy RF environment with very low interference indicators, but it reveals a significant amount of client-generated QoS Null frame activity.

The AP itself does not appear to be the source of airtime problems:

• Beacon traffic is low.

• Management overhead is low.

• Retries are excellent.

• Client discovery traffic is minimal.

The primary finding is:

19% of all captured frames were QoS Null frames.

This means nearly one out of every five frames transmitted was not carrying user data.

The RF environment appears reliable, but client power-management behavior is consuming airtime that could otherwise support application traffic.

Wi-Fi Capture Results

1. Probe Requests and Probe Responses

Filter

wlan.fc.subtype == 4 || wlan.fc.subtype == 5

Result

Frames 235
Percentage 0.3%

What this measures

Probe traffic represents Wi-Fi discovery.

Probe Request

A client asks:

“What Wi-Fi networks are available?”

Probe Response

An AP responds:

“I have that network.”

Analysis

Your result:

🟢 Excellent

Only:

235 / 90,877 frames

were discovery frames.

This indicates:

• Clients are not aggressively scanning.

• Roaming activity appears low.

• The wireless environment is not being flooded with discovery traffic.

A high-density environment often shows much higher probe activity when devices constantly search for networks.

2. QoS Null Frames

Filter

wlan.fc.subtype == 12

Result

Frames 17,267
Percentage 19%

The Major Finding

🔴 High QoS Null Activity

Almost:

1 out of every 5 frames

was a QoS Null frame.

What is a QoS Null Frame?

A QoS Null frame is a data-category frame with:

• no application payload

• no user data

• only control information

Think of it as a client saying:

“I am still connected. Here is my current power state.”

Example:

Client Laptop
      |
      |
      |  QoS Null Frame
      |
      v
Access Point

The frame consumes airtime but delivers no application data.

Why do clients send QoS Null frames?

Common reasons:

1. Power Management

Modern devices aggressively manage battery life.

A client may:

• sleep

• wake

• notify the AP

• sleep again

This is common with:

• laptops

• tablets

• phones

2. Keepalive Behavior

Some clients periodically signal:

“Maintain my connection.”

This keeps sessions active.

3. Traffic Queue Management

QoS Null frames can communicate power-save state changes so the AP knows whether it can buffer traffic.

How Much Traffic Is This?

Your capture:

17,267 QoS Null frames
/
60 seconds

≈ 288 QoS Null frames per second

That is a significant amount of client signaling.

3. Beacon Frames

Filter

wlan.fc.type_subtype == 0x08

Result

Frames 1,105
Percentage 1.2%

What this measures

Beacon frames are AP advertisements.

The AP periodically announces:

• SSID

• channel

• capabilities

• security settings

Analysis

🟢 Excellent

For one AP:

1.2% beacon traffic is very low.

This indicates:

• The AP is not creating excessive management overhead.

• SSID advertisements are reasonable.

• Beacon airtime is not a concern.

4. Management Frames

Filter

wlan.fc.type == 0

Result

Frames 1,554
Percentage 1.7%

What this measures

All management activity:

Includes:

• Beacons

• Probes

• Authentication

• Association

• Roaming

• Action frames

Analysis

🟢 Excellent

The AP infrastructure is not consuming excessive airtime.

Typical guidance:

Management TrafficRating<10%🟢 Healthy10–20%🟡 Investigate>20%🔴 Problem

Your result:

1.7%

Very healthy.

5. Retries

Filter

wlan.fc.retry == 1

Result

Frames 610
Percentage 0.7%

What this measures

Retries occur when frames must be retransmitted.

Causes:

• interference

• collisions

• weak signal

• hidden nodes

• congestion

Analysis

🟢 Excellent

Your retry rate:

0.7%

This indicates:

• RF reliability is good.

• Clients are communicating successfully.

• Interference is not currently a major concern.

Final Wi-Fi Report Card

One AP — 90,877 Frame Capture

Category Result Grade
Client Discovery 0.3% 🟢 A
Beacon Overhead 1.2% 🟢 A
Management Traffic 1.7% 🟢 A
Retries 0.7% 🟢 A+
QoS Null Frames 19% 🔴 D

Overall Grade

🟡 B- — Healthy RF, But Significant Client Overhead

The wireless network is not failing.

The RF indicators are excellent:

✅ Low retries
✅ Low management traffic
✅ Low beacon overhead
✅ Minimal scanning

The concern is:

Clients are consuming a large amount of airtime with frames that contain no user data.

Troubleshooting Next Steps

1. Find which clients generate QoS Null frames

In Wireshark:

wlan.fc.subtype == 12

Then:

Statistics
→ Endpoints
→ WLAN

Look for the top transmitters.

You may find:

• one device generating thousands

• one operating system behaving differently

• a specific client type causing the behavior

2. Compare QoS Null frames against client count

The question:

How many clients were connected?

Example:

Clients Interpretation
5 clients Very unusual
50 clients Possible
200+ clients Expected behavior

3. Measure actual airtime

Frame counts are only part of the story.

Next filters:

Data frames:

wlan.fc.type == 2

QoS Data:

wlan.fc.type_subtype == 0x28

The key question:

Are QoS Null frames consuming meaningful airtime, or are they simply numerous small frames?

Blog takeaway

A Wi-Fi network can have excellent signal, low retries, and healthy AP statistics — while clients quietly consume airtime doing almost nothing.

The packet capture does not show a broken Wi-Fi network.

It shows something more subtle:

The AP is healthy. The clients are talking a lot. They just are not always saying anything useful.

That is exactly the type of behavior that dashboards often miss and packet captures reveal.

Airtime: The Real Bottleneck in High‑Density Wi‑Fi

In high‑density classrooms and conference spaces, Wi‑Fi doesn’t fail because of:

• signal strength

• channel width

• number of APs

• throughput

It fails because airtime runs out.

Wi‑Fi is a shared medium. Only one device can transmit at a time on a given channel. When slow frames, retries, probe storms, or low‑rate clients dominate the channel, airtime evaporates.

Packet captures help you see this happening.

What “100× More Airtime” Actually Means (Walkie‑Talkie + Currency Analogy)

To understand airtime, imagine two friends sharing one walkie‑talkie. Only one person can talk at a time.

Now imagine:

• Friend A speaks very slowly

• Friend B speaks very quickly

Both are trying to say the same message, but:

• The slow speaker takes 100× longer

• The fast speaker finishes almost instantly

Now imagine you have 60 seconds where the walkie‑talkie is available.

If the fast speaker takes 1 millisecond to say the message:

They can speak 60,000 times in one minute.

If the slow speaker takes 100 milliseconds to say the same message:

They can speak only 600 times in one minute.

Same message. Same walkie‑talkie.

100× difference in airtime consumed.

Airtime as Currency

Another way to think about it:

• You have 60 seconds of airtime — like having $60 to spend.

• Every transmission “costs” airtime.

• Fast transmissions cost 1 cent.

• Slow transmissions cost $1.

With $60:

• You can buy 6,000 fast transmissions, or

• You can buy 60 slow transmissions

One slow device drains the budget instantly. One slow frame costs the same as 100 fast frames.

This is why:

• minimum bitrate matters

• low‑RSSI clients must be rejected

• probe storms destroy networks

• retries collapse airtime

• 2.4 GHz is a liability in dense spaces

Airtime is the real bottleneck.

How to Interpret a 60‑Second Packet Capture

Here are the numeric thresholds that indicate airtime problems in a 60‑second capture.

These are field‑tested values used in high‑density deployments.

1. Probe Traffic (Requests + Responses)

wlan.fc.subtype == 4 || wlan.fc.subtype == 5

Healthy: < 2,000 probes/min
Concerning: 2,000–10,000 probes/min
Airtime meltdown: > 10,000 probes/min
Catastrophic: > 20,000 probes/min

Probe storms are the #1 airtime killer in classrooms.
Per the right hand lower corner, the numbers per 60 seconds show slightly unhealthy.
Packets 1000006 Displayed 5299 (2.4%)

2. Low‑Data‑Rate Frames (<12 Mbps)

radiotap.datarate < 12

Healthy: < 5% of frames
Concerning: 5–15%
Airtime collapse: > 20%
Critical: > 30%

Low‑rate frames dominate airtime because they transmit slowly.
Packets 1000006 Displayed 16706 (16.7%)

3. Retries

wlan.fc.retry == 1

Healthy: < 5%
Concerning: 5–15%
Airtime collapse: > 20%
Critical: > 30%

Retries multiply airtime consumption.
Packets 1000006 Displayed 30 (0.0%)

4. Beacons

wlan.fc.subtype == 8

Healthy: 1–8 SSIDs per AP
Concerning: 9–12 SSIDs
Airtime waste: > 12 SSIDs

Beacon interval warning: < 100 ms

Beacons transmit at low rates and consume airtime every 100 ms.

With this capture- the beacons show:
Packets 1000006 Displayed 40772 (40.8%)

5. Management + Control Frames

wlan.fc.type == 0 || wlan.fc.type == 1

Healthy: < 30% of total frames
Concerning: 30–50%
Airtime collapse: > 50%

These frames don’t carry data — but they consume airtime.

Packets 1000006 Displayed 57236 (57.2%)

6. QoS Null Frames

wlan.fc.subtype == 12

Healthy: < 500/min Concerning: 500–2,000/min Airtime collapse: > 2,000/min

These are “power‑save chatter” frames. In dense environments, they explode.
Packets 1000006 Displayed 16706 (16.7%)

Report Card

Executive Summary — Wi-Fi Airtime Health Report

Environment

• 5 GHz high-density classroom environment

• 2.4 GHz disabled

• 60-second packet capture analysis

Overall Grade: 🔴 D — Airtime Efficiency Failure Risk

Key Finding

The network is experiencing an airtime exhaustion problem, not a coverage or signal-quality problem.

Wi-Fi performance degradation is primarily driven by how airtime is being consumed, not by RF failure, retries, or lack of signal strength.

1. 🔴 Primary Cause — Wi-Fi System / Infrastructure Overhead

The largest portion of airtime is consumed by the wireless infrastructure itself:

• Management + Control Frames: 57.2%

• Beacon Traffic: 40.8%

Interpretation

The Wi-Fi system is spending most of its time:

• Advertising networks

• Managing connections

• Handling control functions

This leaves less airtime available for actual user data.

2. 🟡 Secondary Cause — Client-Generated and Client-Amplified Behavior

Client behavior contributes additional airtime load:

• Low Data Rate Frames: 16.7%

• QoS Null Frames: 16.7%

• Probe Traffic: 5,299 packets (2.4%)

Interpretation

Clients are not the root failure point, but:

• Slow devices consume disproportionate airtime

• Power-save behavior increases signaling overhead

• High device density amplifies contention

These effects become significantly worse as more clients join the network.

3. 🟢 RF Reliability Indicators — Not the Problem

• Retries: 0.0%

Interpretation

• No significant evidence of packet loss or interference

• Signal quality is not the limiting factor

• Increasing transmit power would not resolve the issue

4. Client Density Impact

Few Clients (5–10 users)

• Airtime demand is low

• Infrastructure overhead is present but not impactful

• Users experience fast and stable performance

Many Clients (60–100+ users)

• Airtime becomes saturated

• Infrastructure overhead consumes a fixed share of capacity

• Client behaviors compound congestion

Result:

• Slow applications

• Increased latency

• Testing and video failures

• Poor user experience despite good signal

5. How Many SSIDs are Seen?

wlan.fc.type_subtype == 0x08 && wlan.ssid == “Sky Mountain”

• Sorted on BSS Id, copied one of each unique

• In this example 20 SSIDs are shown in the room
  

  

  
  Filters in a Snapshot
  

  Wireshark FilterWhat It Does Why It Matters
  
  wlan.fc.subtype == 0x08 Isolates beacon frames. Used to measure SSID broadcast overhead and
  AP density impact on airtime.

  wlan.fc.type == 0radiotap.datarate < 12
Identifies low data-rate transmissions. These consume disproportionate airtime and are major contributors to congestion.
  wlan.fc.type_subtype == 0x04wlan.fc.retry == 1
Filters retransmitted frames. Indicates inefficiency and airtime multiplication due to collisions or poor conditions.
  wlan.fc.subtype == 0x0c Isolates QoS Null frames (power-save signaling). High counts indicate client power-save chatter increasing overhead.
  

  wlan.ssid == "Sky Mountain" Filters traffic for a specific SSID. Used to isolate beaconing and traffic belonging to a targeted

  WLAN.wlan.bssid Used to identify and group traffic by individual AP radio (BSSID) for density and overlap analysis. radiotap fields (general)Provides PHY-layer context
  like rate, signal strength, and channel— critical for interpreting airtime cost.

  
wlan.fc.type == 0 Filters all management frames only. Useful for isolating control-plane overhead independent of data traffic.

Final Assessment

Wi-Fi Airtime Health Score: 🔴 D

Primary Issues

• Excessive infrastructure airtime consumption

• High beacon overhead

Secondary Issues

• Client efficiency and density amplification

• Potential co-channel contention effects

Bottom Line

The wireless system is not failing because clients cannot connect or because RF is unstable.

It is failing because too much of the shared airtime is consumed by infrastructure overhead before clients can effectively transmit data.

The Wi-Fi Bars Lie

Most people think the Wi-Fi bars on their phone tell them everything they need to know.

Four bars? Great Wi-Fi.
One bar? Bad Wi-Fi.

But those bars only represent one measurement: RSSI.

They don’t show interference.
They don’t show congestion.
They don’t show noise.
They don’t even show whether you’re connected to the best access point nearby.

To really understand Wi-Fi performance, we need to look at RSSI, SNR, and data rates together.

Much of the explanation of RSSI ranges, SNR values, and application requirements below is based on concepts taught in Cisco U training for WLCOR (Implementing and Operating Cisco Enterprise Wireless Networks).

Let’s start with the bars.

What Wi-Fi Bars Actually Show

The bars on your phone represent signal strength, which in Wi-Fi is called RSSI.

RSSI stands for Received Signal Strength Indicator.

Think of RSSI like how loud the Wi-Fi signal is.

The closer you are to the access point, the louder the signal becomes.

RSSI is measured in dBm, and the numbers are negative.

The closer the number is to zero, the stronger the signal.

RSSI Signal Quality Typical Phone Bars
-30 Extremely strong Full bars
-50 Very strong Full bars
-60 Good 3–4 bars
-67 Minimum for voice ~3 bars
-70 Fair 2–3 bars
-80 Weak 1–2 bars
-90 Barely usable 0–1 bar

⚠️ Important: The number of bars can vary from device to device.
Every manufacturer translates RSSI into bars differently.

So three bars on one phone may not equal three bars on another.

What Different Signal Strengths Are Good For

Different applications require different signal strengths to work reliably.

The following guidelines are commonly used in enterprise Wi-Fi design and are discussed in Cisco U WLCOR training.

ApplicationRecommended RSSIWeb browsing / email-70 dBmStreaming video-67 dBmVoice over Wi-Fi (VoIP)-67 dBmVideo conferencing-65 dBmReal-time collaboration / AR / VR-60 dBm

For example:

• At -70 dBm, web browsing may feel fine.
• At -65 dBm, video conferencing becomes much more stable.
• At -60 dBm, performance is strong enough for demanding applications.

This is why many enterprise Wi-Fi networks are designed to provide at least -67 dBm everywhere users are expected to work.

The Bars Don’t Tell You Which Access Point You’re Using

There’s another important limitation with Wi-Fi bars.

They only show signal strength from the access point your device is currently connected to.

But your device may not be connected to the closest access point.

Imagine walking into an office building.

At the entrance your phone connects to an access point with -55 dBm, which is excellent.

Then you walk deeper into the building.

Your signal gradually drops:

-60 dBm
-67 dBm
-72 dBm

Meanwhile, you might now be standing right next to a different access point that could provide -45 dBm.

But your phone may still stay connected to the original one.

Why?

Because devices decide when to roam, not the Wi-Fi network.

As long as the current connection still works, many devices prefer to stay connected instead of switching.

This behavior is commonly called sticky clients.

So you might see three bars and assume everything is fine, even though your device is connected to a farther access point with weaker signal.

The Thing RSSI Does NOT Measure: Noise

RSSI only measures signal strength.

It does not measure interference or background noise.

Imagine trying to hear someone talking across a crowded room.

Even if their voice is loud, it may still be hard to understand because:

• people are talking
• music is playing
• chairs are moving

Wi-Fi works the same way.

You might have a strong signal, but if the air is full of interference, performance will still suffer.

That’s why engineers also look at SNR.

What is SNR?

SNR stands for Signal-to-Noise Ratio.

It measures how much stronger the Wi-Fi signal is compared to background noise.

Formula:

SNR = RSSI − Noise Floor

Example:

MeasurementValueRSSI-60 dBmNoise Floor-90 dBmSNR30 dB

That means the signal is 30 dB louder than the noise, which is excellent.

Typical SNR Levels and What They Support

The following ranges are commonly discussed in Cisco U WLCOR training when evaluating wireless link quality.

Minimum SNR Link Quality Typical Supported Applications
30+ dB Excellent High-throughput applications (4K video, large
file transfers), highest data rates (for example,
256-QAM and higher)
25 – 30 dB Very Good Good quality link, most applications perform
well
20 – 25 dB Better Reliable voice over Wi-Fi (VoWiFi), high-quality
video conferencing
15 – 20 dB Good Standard web browsing, email, standard-
definition video streaming
10 – 15 dB Poor Basic connectivity possible but with
retransmissions and low data rates
<10 dB Very Poor Connections may be unstable or frequently
disconnect

Even if RSSI looks strong, poor SNR can still make Wi-Fi perform badly. There are some free tools that can give SNR, some free with an Internet search.

A Simple Way to Think About Noise

Imagine two people trying to talk.

Scenario 1: Loud voice, noisy room

You can hear the voice, but lots of background noise makes it hard to understand.

That’s:

Strong RSSI, poor SNR.

Scenario 2: Quiet voice, quiet room

The voice is softer, but the room is silent.

You understand every word.

That’s:

Moderate RSSI, excellent SNR.

In Wi-Fi, clarity matters more than volume.

Data Rates: How Fast Devices Talk

Wi-Fi devices also adjust their data rate depending on signal quality.

Think of this like talking speed.

When signal and SNR are good:

Devices talk quickly.

When signal conditions worsen:

Devices slow down and repeat themselves.

Slow transmissions create a problem in Wi-Fi because Wi-Fi uses shared airtime.

If one device talks slowly, everyone else has to wait longer.

Why Removing Low Data Rates Helps

Devices normally decide when to switch access points.

But if very slow data rates are allowed, a device might stay connected with poor signal and just transmit slowly.

When slow data rates are removed:

• slow connections stop working
• devices roam sooner
• connections improve

This is why removing very low data rates often improves Wi-Fi performance at the edges of coverage.

The Simple Way to Think About Wi-Fi

Three things determine Wi-Fi performance:

1️⃣ RSSI

How loud the signal is.

2️⃣ SNR

How clear the signal is compared to noise.

3️⃣ Data Rates

How fast devices are allowed to talk.

The Real Meaning of Wi-Fi Bars

Wi-Fi bars only show RSSI.

They do not show:

• interference
• congestion
• noise
• SNR
• airtime usage
• retries
• which access point you’re actually connected to

So while the bars give a quick hint about signal strength…

They don’t tell the whole story.

And in Wi-Fi design, the goal isn’t just strong signal.

It’s clear signal, efficient airtime, and devices connecting to the right access point at the right time.

Wi-Fi has become as essential as electricity—only far more complex. With more devices, cloud apps, hybrid work, and wireless-first strategies taking root, reliable Wi-Fi isn't a luxury; it’s a utility.

But unlike a water line or light switch, Wi-Fi demands regular planning and upgrades. If we want it to perform at a high level across a campus, hospital, office, or enterprise, we need to budget for three core categories: Projects, Maintenance, and Tools.

Let’s break these down—plus provide you with a handy checklist to guide your planning.

🏗️ 1. Projects: Designing for Change

Your network is only as strong as its foundation—and that foundation needs to evolve with the demands placed on it.

Whether you're constructing new spaces, renovating existing ones, or simply adapting to new wireless use cases, Wi-Fi needs intentional design updates. It’s not enough to add access points. You need a strategy that accounts for:

• High-density areas (like lecture halls or lobbies)

• Interference from new devices

• New Wi-Fi or BLE use cases, such as asset tracking and location-based services

• Automation for business reporting or operational troubleshooting (e.g., developing scripts, building plug-ins for management systems, or deploying analytics engines)

As access point models change, so does the design. New hardware brings new signal patterns, power needs, and feature sets that must be factored into your wireless architecture. Each of these updates becomes a project—and that means budget.

A strong Wi-Fi project plan isn’t just about solving today’s problems—it’s about building for tomorrow’s demands.

🔄 2. Maintenance: Keeping Wi-Fi Healthy

Once your Wi-Fi network is live, it needs ongoing care. Like any infrastructure, it can quietly degrade without attention.

Maintenance includes:

• Keeping up with licenses and renewals

• Ensuring access points are running on current firmware

• Monitoring system health through dashboards and alerts

• Replacing aging hardware before performance drops

A big part of Wi-Fi maintenance is predictability—knowing you have a clean slate to work from when issues arise. If a license lapses or a tool is out of date, troubleshooting slows down and productivity takes a hit.

Think of Wi-Fi maintenance like dental hygiene—not glamorous, but essential. Skip it, and you’re headed for costly emergencies.

🛠 3. Tools: Seeing the Unseen

Wi-Fi doesn’t exist in plain sight. It floats through walls, ceilings, and airwaves crowded with everything from microwaves to motion sensors. That’s why your team needs tools.

And not just any tools—tools that evolve with the technology.

For example, with the introduction of 6GHz channels (in Wi-Fi 6E and Wi-Fi 7), your old analyzers may no longer be effective. You’ll need:

• 6GHz-capable spectrum analysis

• Advanced cloud-based dashboards

• AI-powered analytics to detect trends and pinpoint issues

The right tools help you work faster, solve smarter, and keep users online without guesswork.

The better the tools, the faster the fix—and the fewer headaches for everyone.

✅ Wi-Fi Budget Planning Checklist

Here's your at-a-glance guide to building a Wi-Fi budget that’s ready for the future:

📌 Projects

• Redesign Wi-Fi for new or remodeled buildings

• Design- Consider asset tracking, way finding and other Wi-Fi centric applications (this is a whole topic in itself)

• Refresh hardware as models and specs evolve (network and Wi-Fi Capacity)

• Plan for new wireless use cases (asset tracking, location services)

• Upgrade analytics engines or shift toward wireless-first infrastructure

📌 Maintenance

• Renew Wi-Fi licenses and subscriptions

• Schedule firmware updates and system health checks

• Replace aging equipment before failure

• Monitor performance and downtime metrics regularly

📌 Tools

• Upgrade to tools that support 6GHz and Wi-Fi 6E/7

• Use cloud-based or AI-powered analytics platforms

• Invest in spectrum analysis and diagnostic utilities

• Train teams to use next-gen tools effectively

🧠 Final Thought

Budgeting for Wi-Fi is not background IT task—it’s a strategic decision. The organizations that get ahead are the ones who treat wireless like a living system: built with care, maintained with discipline, and supported with the right tools.

Have thoughts, questions, or stories from the field? Leave a comment or hit reply—I’d love to hear how you’re approaching your next Wi-Fi upgrade.

Picture courtesy of Meta AI.

Client MAC: 7c:4d:8f:22:91:ab
AP/BSSID: 3e:9f:53:04:6d:f0
AP packet capture

📋 Wireshark APto-Client Connection Report Card

1️⃣ Traffic Visibility

What it Measures: Are frames consistently present between client and AP?

Display Filter:

eth.addr == 7c:4d:8f:22:91:ab && eth.addr == 3e:9f:53:04:6d:f0

RatingCriteria❌ PoorVery few frames; long traffic gaps⚠️ GoodMostly visible; small gaps✅ ExcellentContinuous packet flow

How to Check:
Apply filter → Look at packet count and timeline → Ensure traffic appears consistently.

2️⃣ Retransmissions (Packet Loss Indicator)

What it Measures: TCP retransmissions caused by loss/interference.

Display Filter:

tcp.analysis.retransmission && (eth.addr == 7c:4d:8f:22:91:ab || eth.addr == 3e:9f:53:04:6d:f0)

RatingCriteria❌ Poor>5% retransmissions⚠️ Good1–5% retransmissions✅ Excellent<1% retransmissions

How to Check:
Apply filter → Compare count to total packets from Item #1 → Calculate percentage.

3️⃣ Duplicate ACKs

What it Measures: TCP loss recovery behavior.

Display Filter:

tcp.analysis.duplicate_ack && (eth.addr == 7c:4d:8f:22:91:ab || eth.addr == 3e:9f:53:04:6d:f0)

RatingCriteria❌ PoorFrequent bursts of duplicates⚠️ GoodOccasional duplicates✅ ExcellentNone observed

How to Check:
Apply filter → Look for repeated ACK numbers in Info column.

4️⃣ Throughput Stability

What it Measures: Consistency of traffic rate.

Display Filter (for IO Graph):

eth.addr == 7c:4d:8f:22:91:ab || eth.addr == 3e:9f:53:04:6d:f0

RatingCriteria❌ PoorSpiky or collapsing traffic⚠️ GoodMostly steady with dips✅ ExcellentSmooth, steady rate

How to Check:
Statistics → IO Graphs → Apply filter → View Packets/Tick or Bytes/Tick → Look for stability.

5️⃣ Latency (Round Trip Time)

What it Measures: TCP round-trip time stability.

Display Filter (to isolate a stream):

eth.addr == 7c:4d:8f:22:91:ab && tcp

(Optional after selecting stream)

tcp.stream eq X

RatingCriteria❌ PoorHigh & inconsistent RTT spikes⚠️ GoodModerate but stable RTT✅ ExcellentLow & consistent RTT

How to Check:
Right-click TCP packet → Follow → TCP Stream → Analyze → Round Trip Time Graph.

6️⃣ Connection Stability

What it Measures: Unexpected TCP resets or session interruptions.

Display Filter:

tcp.flags.reset == 1 && (eth.addr == 7c:4d:8f:22:91:ab || eth.addr == 3e:9f:53:04:6d:f0)

RatingCriteria❌ PoorFrequent TCP resets⚠️ GoodOccasional reset✅ ExcellentNo resets

How to Check:
Apply filter → Count reset packets → Investigate timing of resets.

7️⃣ Packet Errors / Bad Checksums

What it Measures: Corruption or frame errors.

Display Filter:

(tcp.checksum_bad == 1 || udp.checksum_bad == 1) && (eth.addr == 7c:4d:8f:22:91:ab || eth.addr == 3e:9f:53:04:6d:f0)

RatingCriteria❌ PoorMany checksum failures⚠️ GoodOccasional failures✅ ExcellentNone

How to Check:
Apply filter → Verify count of bad checksum frames.

8️⃣ TCP Zero Window (Client Overload Indicator)

What it Measures: Whether the client is overwhelmed.

Display Filter:

tcp.window_size_value == 0 && eth.addr == 7c:4d:8f:22:91:ab

RatingCriteria❌ PoorFrequent zero window events⚠️ GoodRare zero window✅ ExcellentNone

How to Check:
Apply filter → Look for repeated zero window announcements.

🏁 Final Grading Guide

• 7–8 Excellent → Healthy Wi-Fi Session

• Mostly Good with 1 Poor → Monitor but acceptable

• 2–3 Poor → Investigate RF, congestion, or client health

• 4+ Poor → Likely Wi-Fi or network impairment

Picture from Meta AI

When someone asks:

“Is the client staying connected?”

What they usually mean is:

“Is the client staying connected well?”

A controller dashboard can say Connected: Yes.
But only a wireless packet capture (Radiotap + 802.11) can tell you whether that connection is actually healthy.

This guide walks through exactly how to analyze a client in Wireshark — including RSSI, retry rates, MCS behavior, noise floor, and roaming stability — using practical filters and examples.

Step 1: Isolate the Client

Start by filtering to the device you care about:

wlan.addr == de:ad:be:ef:12:34

Everything from here forward should be focused on one MAC address.

If you analyze multiple clients at once, the metrics become meaningless.

Step 2: Is the Client Actually Staying Connected?

Filter for Association & Disconnect Events

wlan.addr == de:ad:be:ef:12:34 &&
(wlan.fc.type_subtype == 0x00 ||
 wlan.fc.type_subtype == 0x02 ||
 wlan.fc.type_subtype == 0x0a ||
 wlan.fc.type_subtype == 0x0c)

These correspond to:

• 0x00 — Association Request

• 0x02 — Reassociation Request

• 0x0a — Disassociation

• 0x0c — Deauthentication

✅ Healthy Example

• One association at 10:02:14

• No deauth

• Continuous traffic afterward

Stable connection.

❌ Unhealthy Example

• Association at 10:02:14

• Deauthentication (Reason Code 4) at 10:07:31

• Reassociation at 10:07:34

• Pattern repeats

That’s connection cycling — not stability.

Step 3: Add RSSI and Noise Columns

Expand Radiotap Header in any packet.

Right-click and Apply as Column:

• radiotap.dbm_antsignal

• radiotap.dbm_antnoise (if available)

Now you can see:

• Signal strength (RSSI)

• Noise floor

• Implied SNR (Signal – Noise)

Understanding Noise Floor

Noise floor is background RF energy.

Typical values:

NoiseMeaning-95 dBmVery clean RF-92 dBmNormal-88 dBmGetting noisy-85 dBmCongested / interference

Why SNR Matters More Than RSSI

SNR = RSSI – Noise

Healthy RF

• RSSI: -58 dBm

• Noise: -94 dBm

• SNR: 36 dB

Expect high MCS (8–11).

Marginal RF

• RSSI: -72 dBm

• Noise: -90 dBm

• SNR: 18 dB

Expect mid-range MCS (3–6).

Unhealthy RF

• RSSI: -78 dBm

• Noise: -87 dBm

• SNR: 9 dB

Expect MCS 0–2 and retries.

Step 4: Add an MCS Column (Critical)

MCS reveals how efficiently data is being transmitted.

How to Add It

1. Expand Radiotap Header

2. Expand MCS information

3. Right-click:

radiotap.mcs.index

4. Select Apply as Column

Filter to View Client MCS

wlan.addr == de:ad:be:ef:12:34 && radiotap.mcs.index

What Healthy MCS Looks Like

Strong Client Example

• RSSI: -60 dBm

• Noise: -94 dBm

• MCS: 8–9 (Wi-Fi 5) or 9–11 (Wi-Fi 6)

• Retry < 5%

Efficient airtime usage.

Marginal Example

• RSSI: -72 dBm

• MCS bouncing between 3–5

• Retry ~15%

Still connected — but inefficient.

Unhealthy Example

• RSSI: -80 dBm

• MCS stuck at 0–2

• Retry 30%+

Barely functional.

Why Low MCS Hurts the Entire Cell

Wi-Fi shares airtime, not bandwidth.

A client transmitting at:

• 600 Mbps uses minimal airtime

• 6 Mbps consumes dramatically more airtime

Low MCS clients:

• Increase contention

• Increase retries for others

• Slow down the entire AP

Step 5: Measure Retry Percentage

Filter:

wlan.addr == de:ad:be:ef:12:34 && wlan.fc.retry == 1

Compare retry frames vs total frames.

Interpretation

Retry %Health< 8%Healthy10–20%Concerning20–40%RF struggling40%+Severe issue

Step 6: Add a BSSID Column (Roaming Insight)

To track AP changes:

Right-click:

wlan.bssid

→ Apply as Column

Now you can visually detect roaming.

Healthy Roam

• RSSI drops to -70

• Reassociation

• New RSSI -58

• MCS improves

Smooth transition.

Sticky Client

• RSSI -78

• No roam

• MCS 2–3

• Retries climb

Connected — but unhealthy.

Ping-Pong Roam

• BSSID flips every few minutes

• RSSI stable at -60

Likely misconfigured roaming thresholds.

Step 7: Look for Time Gaps

Scroll timestamps.

If you see:

• Retry burst

• 2–3 seconds of silence

• Reassociation

That matches user complaints like:

“Wi-Fi froze.”

What a Truly Healthy Client Looks Like

• One association

• RSSI between -55 and -65 dBm

• Noise below -90 dBm

• SNR above 25 dB

• Retry under 10%

• Stable high MCS

• Clean roaming behavior

• No unexplained time gaps

Final Perspective

A dashboard may say:

Client Connected: Yes

But your wireless capture reveals:

• Is RF clean?

• Is SNR strong?

• Is MCS stable?

• Are retries controlled?

• Is roaming efficient?

A client can remain connected at MCS 0 with 35% retries…

…and technically be “online.”

Connection status tells you if a device is attached.

MCS, retries, RSSI, noise, and stability tell you if it’s healthy.

That’s the difference between observing Wi-Fi…

…and engineering it.

It’s frustrating. It can feel like the network just isn’t keeping up.

But what’s really happening has less to do with failure—and more to do with how Wi-Fi behaves under pressure.

Picture from Meta AI

🚗 Imagine a Highway at Rush Hour

Picture a quiet highway that suddenly gets flooded with cars—all at once.

That’s exactly what happens when an entire class connects to Wi-Fi at the same moment:

• Every device sends a request to join

• The network authenticates each one

• IP addresses are assigned

• Security checks happen in the background

When all of this happens simultaneously, things queue up.

Why this matters:
Wi-Fi is a shared system. It processes requests in real time, and when too many arrive at once, delays are inevitable—just like traffic merging onto a busy road.

📡 Not All Connections Are Equal (and Why Devices Get It Wrong)

Your laptop decides which Wi-Fi access point to join—not the network.

And it doesn’t always make the best choice.

Devices tend to connect based on:

• The first signal they detect

• A quick snapshot of signal strength

• Previous connection history

They don’t understand how busy an access point is.

Why this matters:
You can have plenty of total capacity, but if too many devices pick the same access point, it creates a bottleneck—while others nearby sit underused.

🚌 The Hidden Weight of Lockdown Browsers

Lockdown browsers don’t just deliver exams—they often:

• Record video

• Capture audio

• Monitor activity continuously

• Send steady streams of data back to servers

This creates a very different kind of network load.

Instead of quick bursts (like loading a webpage), every device becomes a constant communicator.

What that means:

• Normal use: ~20–50 ms latency

• Under load: ~50–100 ms

• Exam conditions with video/audio: 100–300+ ms spikes

Why this matters:
Wi-Fi works like a shared conversation—devices take turns “talking.” Constant uploads from many devices increase contention, meaning everyone waits longer.

⚙️ 4 Common Lockdown Browser Settings (and Why They Matter)

These are some of the most common features enabled during exams—and each one adds load in different ways:

Video Monitoring (Webcam Recording)

Records and uploads video throughout the exam
👉 Continuous upstream traffic from every device increases network usage

Audio Recording

Captures sound during the session
👉 Adds steady background traffic, even when nothing is happening

Screen Monitoring / Screen Capture

Tracks what’s happening on the student’s screen
👉 Frequent data transfers increase overall load and processing

Real-Time Proctoring (Live Monitoring)

Streams activity to a proctor in real time
👉 Highly sensitive to latency and bandwidth—can amplify performance issues in busy rooms

Big picture:
Each of these on its own may be manageable—but together, across a full classroom, they create sustained, heavy demand on the network.

🌿 What You Can Do To Help in the Classroom with Connections

Small actions can make a meaningful difference—and here’s why:

Reconnect before starting

Turning Wi-Fi off and back on helps devices reassess and choose a better connection
👉 Can shift devices away from overloaded access points

Limit extra devices

Phones and idle laptops still use airtime
👉 Wi-Fi capacity is shared—even background traffic matters

Be thoughtful with exam settings

Disable video/audio if not essential
👉 Reduces constant upstream traffic

Start a few minutes early when possible

Staggering connections reduces the initial surge
👉 Prevents system overload during authentication

📶 A Quick Note on Device Behavior

It’s worth mentioning that laptops and tablets don’t always choose the most efficient Wi-Fi connection.

Devices often connect based on:

• The strongest signal they first detect

• Previous connection history

• A quick, limited snapshot of network conditions

This can sometimes lead multiple devices to land on the same access point.

However: in exam scenarios, this is usually a secondary factor. The larger performance impact still comes from the overall surge in connections, shared airtime, and heavy application traffic rather than individual device decisions.

🔧 What’s Happening Behind the Scenes

Network teams are working to improve things by:

• Adding more access points (more “lanes”)

• Monitoring performance during exams

• Studying how devices connect and where congestion forms

But even with improvements, device behavior and timing still play a major role.

📶 The Future: Smarter, Faster Wi-Fi

Technologies like Wi-Fi 8 are being designed for exactly these scenarios:

• Better handling of crowded environments

• Lower latency under heavy load

• Smarter coordination between access points and devices

Why this matters:
Future networks will be better at preventing these “traffic jams” before they happen.

🧭 A Thought on Directional Antennas

Directional antennas can focus Wi-Fi into specific areas, improving performance in dense classrooms.

They can:

• Reduce interference

• Improve signal quality

• Increase usable capacity

But they also require:

• Additional cost

• Careful room design and placement

They’re powerful—but not always simple to implement.

💬 Final Thoughts

When Wi-Fi struggles during exams, it’s usually a combination of:

• Everyone connecting at once

• Devices clustering unevenly

• Applications generating constant, heavy traffic

The good news? Awareness and small adjustments can go a long way.

📣 Please Keep the Feedback Coming

Your experiences matter.

If something feels slow, inconsistent, or different than expected during an exam, please continue to share:

• Dates and times

• Class sizes

• What tools or settings were used

Why this helps:
Patterns over time help identify root causes, improve design, and support better solutions for everyone.

We truly rely on your feedback to make the experience better.

What helps us improve visibility

Please continue to send reports like this, including:

• Date and time

• Room/building

• Class size

• Whether lockdown browser was in use

If possible, you can also message me directly in Teams during or shortly after an issue so I can review conditions in real time.

What can help in the classroom

A few small actions can make a meaningful difference:

• Restart Wi-Fi in the room if issues appear
  This can help devices reassociate to a closer or less congested access point.

• Adjust lockdown browser settings when possible
  Reducing video/audio/monitoring features (when academically appropriate) can significantly reduce network load.

• Limit unnecessary devices on Wi-Fi
  Every connected device adds load—like additional “cars” entering the highway and contributing to congestion.

—-Bonus—- Ticket Response Template—
Hello,

Thank you for your concern and ticket for Wi-Fi.

In classrooms, what we are primarily seeing is a Wi-Fi technology and capacity issue, where a high number of devices place heavy demand on the system at the same time.

Think of it like a highway: when too many cars enter all at once, everything slows down. In exam situations, it becomes even more extreme—because with lockdown browser tools enabled (especially video, audio, and monitoring), it’s not just cars entering the highway, it’s large buses merging all at once and continuously occupying lanes. That creates congestion that takes time, like any highway system, to sort out under load.

I am actively reviewing capacity in high-density exam spaces and evaluating where additional access points or tuning may help. However, Wi-Fi has natural limits in dense environments due to spectrum availability and how devices share airtime—so at a certain point, adding more access points can also introduce interference and diminishing returns.

I appreciate everyone who continues to report these issues. The patterns we see over time are what help us improve design, capacity, and overall experience in these high-density environments.

Please let me know your thoughts and how things are going.

Picture from Meta AI

RF Shielding Paint, Windows, and Wi-Fi: Controlling Wireless Signals in a Room

Before getting into RF shielding paints and window treatments, here is a helpful example showing a window coating designed to improve energy efficiency while allowing RF signals to pass through.

This highlights an important concept: windows can either block or allow radio signals depending on their coating.

Making Windows Great Again | Luc Pendic | WLPC Prague 2025

Understanding how walls and windows interact with RF can make a big difference when troubleshooting Wi-Fi in buildings.

Why RF Control Matters in Wi-Fi Environments

Wireless networks rely on radio frequency (RF) signals that travel through walls, ceilings, and windows. In many homes and offices this works well, but in dense buildings or technically sensitive environments, uncontrolled RF can create problems such as:

• interference from neighboring Wi-Fi networks

• inconsistent signal strength

• signals leaking outside a building

• outside signals interfering with equipment

One emerging approach to managing these challenges is RF shielding paint combined with selective window coatings or films.

Rather than simply increasing transmit power, these tools allow engineers—or even homeowners—to shape how wireless signals move through a space.

How RF Shielding Paint Works

RF shielding paint is a conductive coating containing carbon, graphite, or metal particles. Once applied to walls or ceilings, the coating forms a conductive layer that reflects or absorbs electromagnetic energy.

This creates an effect similar to a Faraday shield, where radio waves interact with the conductive surface instead of passing freely through the wall.

Most shielding paints provide:

• 20–40 dB signal attenuation per coat

• reduction of up to 99–99.99% of RF energy

These paints usually affect a wide range of frequencies including:

• Wi-Fi (2.4 GHz and 5 GHz)

• Bluetooth

• cellular signals

• microwave frequencies

Because the paint layer becomes conductive, many installations also connect the shielded surface to building ground to improve performance.

Example RF Shielding Paint: WOREMOR RF-IE50

One shielding product often discussed in RF control environments is WOREMOR RF-IE50 EMR Shielding Paint.

Typical characteristics include:

• water-based conductive shielding paint

• graphite/carbon shielding formulation

• approximately 36 dB attenuation with one coat

• 40+ dB attenuation with two coats

• effective up to roughly 18 GHz, covering most modern wireless technologies

Like many shielding paints, it can be applied using rollers or brushes and then covered with standard decorative paint.

Other Common RF Shielding Paints

Several other shielding paints are widely used in RF control environments.

YShield HSF54 Shielding Paint

One of the most well-known RF shielding paints, providing roughly 36 dB attenuation per coat.

YShield HSF64 Shielding Paint

A more durable variant of HSF54 designed for exterior or higher-moisture environments.

CuPro-Cote RF Shielding Paint

A copper-particle-based shielding paint typically providing 20–35 dB attenuation depending on application thickness.

Each of these paints works by creating a conductive barrier that reduces RF transmission through walls.

Windows: The Weak Point in RF Shielding

When walls are shielded, windows become the primary path for RF signals.

Glass blocks very little radio energy compared with most building materials. Even if the surrounding walls are coated with shielding paint, signals can still easily pass through untreated windows.

Typical RF attenuation of materials looks roughly like this:

MaterialRF attenuationDrywallLowBrickModerateConcreteModerate–highRF shielding paintHighGlassVery low

Because of this, windows often become the most important variable in RF control.

RF Window Films and Shielding Coatings

To control RF through windows, specialized films and coatings are available.

These films typically contain thin metallic layers or conductive mesh structures embedded in transparent material. They reflect or absorb radio waves while still allowing visible light to pass through.

Typical performance includes:

• 14–35 dB RF attenuation in commercial films

• up to 98% signal reduction in some specialty products

• 30–40 dB attenuation in copper-mesh laboratory films

These materials allow natural light to enter a room while still controlling wireless signals.

Common RF Shielding Window Films

YShield RDF72 RF Shielding Window Film

A widely used shielding film providing about 33 dB RF attenuation while maintaining roughly 72% light transmission.

RadioTint RF Shielding Window Film

Designed to reduce Wi-Fi, cellular, and microwave frequencies with 20 dB or greater attenuation.

Signal Protect RF Window Film

Available in clear or reflective versions that reduce incoming and outgoing RF while maintaining window visibility.

Some laboratory installations use transparent copper mesh window films, which can exceed 40 dB attenuation across wide frequency ranges.

Selective Window Treatment

Windows are often the largest RF leak in a shielded room because glass blocks very little radio energy. Even when walls are coated with shielding paint, wireless signals can easily enter or exit through untreated windows.

For that reason, window treatment should be intentional and strategic, depending on the goals of the wireless environment.

In some cases you may want to block RF signals at the window. In others, you may want the window to remain transparent to wireless signals.

When to Apply RF Shielding Film

RF shielding films can be useful for windows facing strong interference sources or areas where signals should not escape.

Examples include:

• apartment, office or campus buildings with many overlapping Wi-Fi networks

• RF testing labs

• offices attempting to contain internal wireless signals

Products such as:

• YShield RDF72 RF Shielding Window Film

• RadioTint RF Shielding Window Film

can reduce RF signals by 20–35 dB, significantly limiting wireless energy passing through the glass.

When used together with shielding paints such as WOREMOR RF-IE50 EMR Shielding Paint, this can help create a controlled RF environment where signals behave more predictably.

When to Leave Windows RF-Transparent

In other scenarios, you may want windows to allow RF signals to pass through.

Examples include:

• extending indoor Wi-Fi coverage outdoors

• connecting mesh nodes between buildings

• allowing cellular signals to reach interior spaces

Some modern energy-efficient window coatings are specifically designed to improve thermal efficiency while remaining transparent to RF, allowing Wi-Fi and cellular signals to pass through normally.

However, certain metallic heat-reflective window films can unintentionally weaken wireless signals, so coating selection should be made carefully.

Designing a Balanced RF Environment

The most effective RF control strategies usually combine several techniques.

1. Shielding paint on walls and ceilings

Examples include

• WOREMOR RF-IE50 EMR Shielding Paint

• YShield HSF54 Shielding Paint

2. Selective window treatment

Examples include

• YShield RDF72 RF Shielding Window Film

• RadioTint RF Shielding Window Film

3. Dedicated Wi-Fi access points inside shielded rooms

4. RF measurement tools such as spectrum analyzers or Wi-Fi scanning software

Rather than simply blocking signals everywhere, this approach allows engineers to shape RF propagation intentionally.

Thinking of Windows as RF Valves

One helpful way to think about RF shielding systems is that walls provide the barrier while windows control the openings.

Shielding paint establishes the RF boundary of a room. Window films determine where radio signals are allowed to enter or exit that boundary.

Used together, these materials can transform an unpredictable wireless environment into a controlled and measurable RF space, which can be extremely useful when diagnosing difficult Wi-Fi issues.

In summary:
Products such as WOREMOR RF-IE50 EMR Shielding Paint and RF shielding window films are not designed to increase Wi-Fi signal strength directly. Instead, they help engineers and homeowners control where RF signals travel, reducing interference, containing wireless networks, and creating more predictable wireless environments.

Picture from Meta AI

A Quick Summary of Peter’s Main Points:
Place access points as close to the users as possible
Disable 2.4Ghz on business and mission critical networks
Disable lower data rates but (6, 12, 24) are standard (drop 6 if can)
Increase AP Minimum TX power

Here’s a link to Peter’s WLPC 2-26 Arizona presentation.
How to Fix Your Wi-Fi | Peter Mackenzie | WLPC Phoenix 2026 - YouTube

Yes- I will ensure my min transmit rate at a higher level. Here’s why:

If you want to understand some of the most common Wi-Fi design advice from engineers like Keith Parsons and Peter Mackenzie, here’s a simple story.

Imagine a classroom.

The teacher asks students to read sentences out loud, one at a time.

But there’s an important rule:

Only one student can talk at a time.

Everyone else has to wait their turn.

That rule is very similar to how Wi-Fi works.

Only one device can transmit on the channel at a time.

The Problem: Whispering Students

At first, the teacher allows students to whisper if they want.

Some students whisper very slowly so everyone can hear them.

But whispering causes two problems.

First, the student takes a long time to finish the sentence.

Second, students far away struggle to hear and must speak even slower.

While this whispering happens:

• nobody else can talk

• the classroom slows down

• everyone waits

Wi-Fi works exactly the same way.

A device transmitting very slowly occupies the wireless channel for longer, preventing everyone else from communicating.

What Whispering Looks Like in Wi-Fi

In Wi-Fi, whispering means using very low data rates.

Older Wi-Fi standards supported speeds like:

• 1 Mbps

• 2 Mbps

• 5.5 Mbps

• 11 Mbps

These were designed decades ago when wireless devices were much simpler.

Today, they are incredibly inefficient.

Sending a frame at 1 Mbps takes dramatically longer than sending the same frame at 24 Mbps or higher.

That means one slow device can consume a huge amount of airtime, slowing down the entire network.

The Teacher Changes the Rule

Now imagine the teacher introduces a new rule:

“You must speak clearly. No whispering.”

Suddenly the classroom becomes more efficient.

Students speak clearly and finish faster.

Everyone gets their turn sooner.

Wi-Fi engineers accomplish the same thing by raising the minimum data rate.

This removes the slowest legacy speeds so devices cannot transmit too slowly.

This Also Removes Ancient Devices

There’s another side effect.

Some very old devices only know how to whisper.

If whispering is no longer allowed, those devices cannot participate.

In practice, this removes devices using extremely old protocols.

Those might include hardware that only supports early generations of Wi-Fi like IEEE 802.11b.

These devices are usually:

• extremely old handheld scanners

• legacy IoT equipment

• outdated wireless adapters

Modern devices already support higher data rates, so they are unaffected.

In fact, removing these legacy speeds often improves performance for everyone else.

Now Let’s Talk About Distance

Imagine a student sitting at the very back of the classroom.

If whispering is allowed, that student might stay seated far away and whisper slowly.

The teacher can barely hear them, and the entire class waits while they struggle through their sentence.

But if whispering isn’t allowed, the student has two choices:

Option 1
Speak clearly so the teacher can hear.

Option 2
Move closer to the teacher.

Wi-Fi clients behave the same way.

When minimum data rates are raised, devices must maintain a signal strong enough to communicate efficiently.

If the signal becomes too weak, the device naturally connects to a closer access point.

This Improves Roaming

Roaming is when a device moves from one access point to another.

Without minimum data rates, devices sometimes stay connected to an access point even when the signal becomes very weak.

This creates what wireless engineers call sticky clients.

The device clings to the original access point, whispering slowly at extremely low speeds.

That harms the entire network.

When slow data rates are removed, the device reaches a point where it can no longer communicate efficiently.

At that moment it searches for a better access point nearby.

That leads to better roaming behavior.

How Transmit Power Fits Into the Picture

Wi-Fi signal strength is measured in dBm.

Typical signal strengths might look like this:

Signal Strength Quality
-40 dBm Extremely strong
-60 dBm Excellent
-67 dBm Good for voice
-70 dBm Usable
-80 dBm Weak

Engineers sometimes raise the minimum transmit power of access points to prevent extremely weak coverage areas.

This helps ensure that devices remain in signal ranges where they can use faster data rates.

The result is a healthy chain of improvements:

Strong signal
→ Higher modulation
→ Faster data rate
→ Shorter airtime usage
→ Better performance

The Edge of the Wi-Fi Cell

The edge of a Wi-Fi cell is where signal strength begins to drop.

If whispering speeds are allowed, devices may stay connected at signal levels like:

-80 dBm or worse.

At those levels, communication becomes extremely slow.

When slow data rates are disabled, devices cannot communicate efficiently at those weak signals.

Instead they naturally look for a closer access point with stronger signal strength.

This keeps devices connected to access points that can support faster communication.

The Big Idea

Raising minimum data rates and transmit power isn’t about making Wi-Fi louder.

It’s about preventing inefficient communication.

In the classroom analogy, the rule is simple:

Speak clearly, or move closer.

When every student follows that rule:

• nobody whispers

• nobody takes forever to finish

• everyone gets a turn

And the entire classroom runs smoothly.

Wi-Fi networks work best when devices behave the same way. 📶

Picture from Meta AI

Sometimes people notice something puzzling: one device connects to Wi-Fi instantly, while another device—sitting right next to it—refuses to connect at all.

It’s tempting to assume the Wi-Fi is broken, but very often the real issue is a mismatch between the security technology on the device and the security supported by the Wi-Fi system.

This isn’t just an Android issue. It can happen with many types of modern devices.

Wi-Fi Is Always “On,” but Security Matters

A helpful way to think about Wi-Fi is like light in a room. The signal is always being broadcast. Devices simply step into that signal when they connect.

But before a device can “turn on the light,” it has to prove who it is. That’s where Wi-Fi security comes in.

Over the years, Wi-Fi security has evolved significantly. Older systems may still support legacy methods, while newer devices are designed to refuse weaker or outdated security protocols.

When those two generations meet, the connection can fail.

Older Wi-Fi Security

Some older networks still rely on methods such as:

• WEP – now considered insecure and blocked by most modern devices

• WPA or WPA-PSK – an improvement, but aging

• WPA2-PSK – still common for home networks

Enterprise networks sometimes used authentication methods such as:

• PEAP with MSCHAPv2

• EAP-TTLS

These typically rely on usernames and passwords.

Modern Enterprise Security: EAP-TLS

Many organizations are moving toward EAP-TLS (Extensible Authentication Protocol – Transport Layer Security), one of the most secure wireless authentication methods available.

Instead of passwords, EAP-TLS uses digital certificates.

In simple terms:

• The device presents a certificate

• The network presents a certificate

• Both verify each other before allowing the connection

This process is called mutual authentication, and it dramatically improves security.

However, it also means the device must be properly configured with certificates and compatible software.

It’s Not Just Android

Android devices sometimes get the spotlight in Wi-Fi troubleshooting discussions, but they are far from alone. Many modern devices can experience the same compatibility challenges.

Examples include:

• Apple iPhone models running newer versions of iOS

• Apple iPad tablets running iPadOS

• MacBook computers using macOS

• Newer Chromebooks running ChromeOS

• IoT devices that expect specific security methods

In many cases, newer operating systems enforce stricter security rules. If a network uses outdated encryption or authentication settings, the device may simply refuse to connect.

Why Two Phones Next to Each Other Can Behave Differently

Even within the same device family, differences in:

• operating system versions

• Wi-Fi chipsets

• driver implementations

• security policies

can cause one device to connect easily while another fails.

It’s a bit like trying to plug a modern charger into a very old electrical socket. The power is there—but the standards have changed.

What Usually Fixes the Problem

When security compatibility issues appear, network administrators typically resolve them by:

• Updating Wi-Fi infrastructure firmware

• Updating authentication servers

• Migrating to modern security standards like WPA2-Enterprise or WPA3

• Implementing certificate-based authentication such as EAP-TLS

These improvements help networks stay compatible with modern devices while also strengthening security.

The Takeaway

When a device cannot connect to Wi-Fi, the issue isn’t always signal strength or coverage. Sometimes the device and the network are simply speaking different security languages.

As phones, laptops, and tablets continue to evolve, networks must evolve alongside them.

The good news is that once the security standards align, the connection usually becomes just as seamless as we expect Wi-Fi to be.

Discover Your Wi-Fi with inSSIDer: A Beginner’s Guide

Wi-Fi can be tricky. Maybe your laptop drops connections, your smart devices lag, or you’re just curious why your network feels slow. inSSIDer is a simple tool that helps you peek behind the scenes of your wireless network to understand what’s happening—and the free version is a great place to start.

What is inSSIDer?

inSSIDer is a Wi-Fi scanner that shows you all the networks around you. Unlike the basic network list on your computer, inSSIDer gives you more detail: signal strength, channel usage, security type, and how many networks are competing for the same channel. It’s like a magnifying glass for your Wi-Fi.

How the Free Version Helps

Even without paying, the free version of inSSIDer can help you in several ways:

1. See all nearby networks – You can identify which Wi-Fi networks are around, which channels they use, and how strong their signals are. This helps you spot congestion or interference that could slow your connection.

2. Check your signal strength – If your Wi-Fi is weak in certain rooms, you can see exactly how your signal changes as you move around. This is especially handy for troubleshooting dead spots.

3. Spot channel overlap – Many Wi-Fi problems happen when multiple networks use the same channel. inSSIDer shows you overlapping networks so you can pick the best channel for your router.

4. Basic troubleshooting – If devices keep dropping or your internet feels slow, you can see if the issue is network congestion, weak signal, or interference from neighbors.

How to Use It

1. Download and install the free version from the official website.

2. Open inSSIDer and let it scan your area.

3. Look at the list of networks, their channels, and signal strengths.

4. Identify your network and check if it’s crowded by other networks.

5. Move around and watch the signal meter to find weak spots.

Why Beginners Should Try It

The free version is easy to understand and doesn’t overwhelm you with too much data. It’s a safe, practical way to start learning about Wi-Fi behavior, and it gives you actionable insights: switch your router channel, move your AP, or simply understand why your connection might be slower in one room than another.

💡 Tip: Once you’re comfortable, you can explore the paid version for more advanced features like network performance metrics and detailed interference analysis—but many users solve most everyday Wi-Fi issues with just the free tools.

What SSIDs and channels are they on- so you can avoid them with your home install.

Picture from Meta AI

Anyone who works with Meraki networks long enough eventually hits that moment:
you’re doing the same repetitive task for the hundredth time, clicking through dashboards, exporting settings, double‑checking SSIDs, and thinking, There has to be a better way.

For me, that moment turned into a script — and that script turned into a workflow upgrade I didn’t know I needed.

The Problem: Repetitive Work + Human Error = Not Fetch

Meraki’s dashboard is great, but when you’re responsible for multiple networks, multiple SSIDs, and recurring audits, the manual process becomes a slog.
Every time I needed to:

• Pull SSID configurations

• Verify security settings

• Check WPA2/WPA3 modes

• Export everything cleanly into Excel

…I found myself repeating the same steps. And let’s be honest — the more repetitive the task, the more likely something gets missed.

That’s when I decided to automate the whole thing.

The Solution: A Script That Actually Does Fetch

My script — now living happily on GitHub — uses the Meraki Dashboard API to automatically:

• Fetch SSID configuration details

• Parse out the important fields

• Organize everything

• Export it into a clean, ready-to-use Excel file

You can see it here:
https://github.com/jadexing/Merakicode/blob/main/SSID_ConfigDetail_Excel

Instead of clicking through dashboards, I run the script and let the API do the heavy lifting.
Suddenly, “fetch” does happen.

Why This Script Changed My Workflow

1. Accuracy Every Time

The API doesn’t get tired, distracted, or rushed.
It returns exactly what’s configured — no more, no less.

2. Speed That Makes Manual Work Look Silly

What used to take minutes (or longer) now takes seconds.
I can run it across multiple networks without breaking a sweat.

3. Repeatability

Recurring tasks are no longer chores.
They’re just… scripts.

4. Transparency and Documentation

Having everything exported to Excel means:

• Easy audits

• Easy comparisons

• Easy sharing with teams

• Easy historical tracking

5. It’s Not Just for Me — It’s for Anyone

The best part?
Meraki’s API is open, well-documented, and available to everyone.
If you’ve ever thought, “I wish I could automate this,” the answer is almost always yes, you can.

And if my script helps someone else skip the repetitive grind, even better.

Why I Put It on GitHub

Because automation shouldn’t be gatekept.
If I’ve already solved a problem, why make someone else reinvent the wheel?

Plus, the Meraki community thrives on shared tools, shared scripts, and shared ideas.
If someone wants to fork it, improve it, or adapt it — go for it.

Final Thoughts: Fetch Happens When You Make It Happen

In Mean Girls, “fetch” never happened.
But in networking, automation absolutely can.

My script started as a way to save myself time.
Now it’s a tool I rely on — and one that anyone can use to make their Meraki workflow faster, cleaner, and more accurate.

If you’re tired of repetitive dashboard work, take a look at the code.
Make it your own.
Let automation do the boring stuff so you can focus on the real work.

Because in this case?
Fetch totally happens.

Picture from Meta AI

The Evidence: Two Clients, Same Room, Completely Different Behavior

Before we talk theory, let’s start with the proof — because nothing is more convincing than a picture.

Below are two screenshots from Meraki’s Client Roaming History tool.
Both clients were:

• Sitting in the same room

• Connected to the same SSID

• Under the same RF conditions

• Stationary

• Tested at the same time

The only difference?
Their NICs.

📸 Screenshot #1 — The Calm, Mature NIC (Wi‑Fi 5 or older Wi‑Fi 6)

What this shows:

• Two roam events (on right), after the initial movement roam

• Long, stable association

• No unnecessary transitions

• Predictable behavior

This is what a well‑tuned NIC looks like.
It roams once, settles in, and stays put.

📸 Screenshot #2 — The Overactive, Newer NIC (AX201/AX211/MT7921, etc.)

What this shows:

• Multiple roams in minutes

• Bouncing between APs

• Short association times

• Roams even with strong signal

• Sometimes roams back to the AP it just left

This is the NIC equivalent of a party‑goer who must greet every AP in the building, regardless of whether the user is trying to stay on a Zoom call.

Why This Happens: The NIC Is the Variable

Same room.
Same APs.
Same RF.
Same SSID.
Same test conditions.

The only thing that changed?

The NIC.

This is the clearest demonstration of why “new hardware = better Wi‑Fi” is a myth.
New NICs often ship with:

• Immature drivers

• Over‑aggressive roaming algorithms

• Misinterpreted 802.11k/v/r information

• Poorly tuned band steering

• Firmware that’s still “learning”

Older NICs, by contrast, have:

• Years of driver refinement

• Stable roaming logic

• Predictable behavior

• Fewer surprises

This is why your older laptop might stay connected during a Zoom call while your brand‑new one drops three times in ten minutes.

How to Capture This Yourself Using Meraki

Meraki makes this incredibly easy — and incredibly visual.
Here’s how to run the same test and gather your own picture‑proof.

Step 1 — Have Two Clients Sit in the Same Room

Choose:

• One older NIC (Wi‑Fi 5 or early Wi‑Fi 6 with mature drivers)

• One newer NIC (Intel AX201/AX211, MediaTek MT7921, etc.)

Connect both to the same SSID.

Have both users remain stationary.

Step 2 — Open the Meraki Dashboard

Go to:

Network‑wide → Clients

Select the first client.

Step 3 — Scroll to “Connection” → Open Roaming History

You’ll see a timeline showing:

• Every AP the client associated with

• The timestamps

• The duration of each association

• Signal strength

• Whether the roam was assisted (802.11r/k/v)

This is the goldmine.

Step 4 — Compare the Two Clients Side‑by‑Side

You’re looking for:

Stable NIC

• One roam

• Long dwell time

• No unnecessary transitions

Unstable NIC

• Frequent roams

• Roams with strong RSSI

• Roams between APs with similar signal

• Roams back and forth

• Roams that correlate with user complaints

This comparison is devastatingly effective because it removes all other variables.

How to Interpret What You See

1. Excessive roaming frequency

If a client roams more than once every 10–20 minutes while stationary, something is wrong.

2. Roams with strong signal

Roaming at –55 dBm or better is a NIC decision problem, not an RF problem.

3. Roams between APs with similar RSSI

This indicates poor roaming logic or misinterpreted 802.11k/v data.

4. Roams that break sessions

If the user reports:

• Zoom freezes

• Teams reconnecting

• Voice dropouts

• Web pages stalling

…and the timeline shows a roam at the same time, you’ve found the smoking gun.

5. Roams that bounce back and forth

This is the classic “party‑goer NIC” behavior — it can’t commit.

Why Meraki’s Visualization Matters

Most Wi‑Fi troubleshooting is invisible.
Users say “the Wi‑Fi is bad,” and IT has to guess.

But when you show:

• Two clients

• Same room

• Same APs

• Same RF

• One stable

• One bouncing

…it becomes undeniable:

The NIC is the problem, not the network.

This is especially useful for:

• Helpdesk escalations

• Vendor disputes

• Laptop rollout testing

• Leadership briefings

• User education

• Proving that “the Wi‑Fi” isn’t the issue

Meraki gives you the picture.
The picture tells the story.

Other Meraki Tools That Help Diagnose NIC Behavior

Event Log

Shows:

• Authentication failures

• DHCP issues

• 802.11r transitions

• Disassociations

• Driver resets (visible as sudden disconnects)

RF Spectrum

Rules out interference.

AP Load

Rules out congestion.

Client Health

Aggregates:

• Latency

• DNS performance

• Signal quality

• Roaming events

Final Thoughts

Some NICs roam calmly.
Some roam aggressively.
And some roam like they’re working the room at a cocktail party.

When you put two clients side‑by‑side and watch one behave and the other bounce like it’s trying to meet every AP in the building, the truth becomes obvious:

New hardware isn’t always better Wi‑Fi.
Better drivers are better Wi‑Fi.

Picture from Meta AI

For the Audience — TL;DR (“Too Long; Didn’t Read”) Executive Summary

This section provides a quick, high‑level summary of the article for readers who want the essential points up front. Here’s what you need to know:

• New NICs (network interface cards) often perform worse than older ones because their drivers and firmware are still immature.

• Popular models — including Intel AX201/AX211 and the MediaTek MT7921 found in many Wi‑Fi 6 Chromebooks — are known for roaming delays, video freezes, and random disconnects.

• Roaming issues are one of the biggest reasons video calls break up when you move around (or don't move around with aggressive nic cards).

• Tools like Wireshark, PingPlotter, iPerf3, Event Viewer, and ChromeOS Diagnostics can reveal what’s really happening behind the scenes.

• Troubleshooting usually involves updating drivers and firmware, checking AP compatibility, tuning roaming aggressiveness, and testing on multiple networks.

• In some cases, the cleanest fix is replacing the NIC with a more stable model — when the device allows it.

Introduction

There’s a quiet myth in the tech world: new hardware means better Wi‑Fi.
It feels intuitive — you buy a new laptop, a new Chromebook, or a new Wi‑Fi 6/6E device, and you expect everything to be faster, smoother, and more reliable.

But Wi‑Fi doesn’t work that way.

In fact, some of the newest NICs on the market are the ones causing the most frustration. Video calls freeze. Roaming between access points becomes unpredictable. Latency spikes appear out of nowhere. And suddenly your “upgrade” feels like a downgrade.

Let’s unpack why this happens — and what you can do about it.

Why New NICs Often Perform Worse Than Older Ones

A NIC’s performance depends on far more than its hardware specs. A brand‑new chipset may support Wi‑Fi 6E, WPA3, OFDMA, and all the buzzwords — but if the software stack isn’t mature, you’ll see:

• Roaming delays

• Latency spikes

• Video freezes

• Random disconnects

• Poor throughput despite strong signal

New NICs often suffer from:

Immature drivers

New NICs almost always arrive before their software ecosystem is fully ready. When a new Wi‑Fi generation rolls out — Wi‑Fi 6, Wi‑Fi 6E, and now Wi‑Fi 7 — the hardware tends to hit the market months or even years before the drivers and firmware mature.

This creates a predictable pattern:

• The chipset supports the newest protocol on paper

• The operating system barely supports it

• The drivers are rushed to meet launch deadlines

• The firmware is still being tuned for real‑world behavior

• Access point vendors are also updating their own code at the same time

In other words: everyone is building the airplane while it’s already in the air.

New Wi‑Fi standards introduce features like:

• OFDMA

• Target Wake Time

• 1024‑QAM and 4096‑QAM

• Multi‑link operation (Wi‑Fi 7)

• 6 GHz band behavior (Wi‑Fi 6E)

• More complex roaming logic

• New power‑saving modes

Each of these requires:

• New driver logic

• New firmware behavior

• New AP firmware

• New OS‑level support

• New regulatory compliance handling

Because all of these pieces evolve independently, early drivers often struggle with:

• Incorrect roaming decisions

• Misinterpreting AP capabilities

• Power‑saving bugs that cause disconnects

• Latency spikes during OFDMA scheduling

• Incomplete support for 6 GHz or DFS channels

• Crashes when switching between bands

This is why a NIC that looks “cutting‑edge” on a spec sheet can behave worse than a five‑year‑old Wi‑Fi 5 card in real‑world environments. The older card has had years of refinement; the new one is still learning how to walk.

A Real‑World Example: Wi‑Fi 5 vs. Wi‑Fi 6 — When “New” Isn’t Automatically Better

It’s easy to assume that Wi‑Fi 6 should outperform Wi‑Fi 5 in every scenario. After all, Wi‑Fi 6 introduces:

• OFDMA

• Target Wake Time

• 1024‑QAM

• Better multi‑user scheduling

• Improved efficiency in dense environments

• Lower latency under load

On paper, it’s a clear upgrade.

But in practice, especially in the first 1–2 years of Wi‑Fi 6 hardware, many users discovered the opposite.

Scenario: A user walks from their office to the kitchen during a Zoom call

Wi‑Fi 5 (802.11ac) — Older, but Mature

A laptop with a well‑established Wi‑Fi 5 NIC (like the Intel 8265 or Qualcomm Atheros QCA6174) typically behaves like this:

• Roams predictably between access points

• Maintains stable RSSI during movement

• Keeps latency consistent

• Rarely drops the call

• Years of driver updates have smoothed out roaming logic

Result:
The user barely notices the transition. The call continues smoothly.

Wi‑Fi 6 (802.11ax) — Newer, but Not Fully Baked

A laptop with a first‑generation Wi‑Fi 6 NIC (like the Intel AX201 or MediaTek MT7921) often behaves differently:

• Roaming decisions are inconsistent

• The NIC may cling to the old AP too long

• Or roam too early

• OFDMA scheduling may cause latency spikes

• Power‑saving features may trigger micro‑disconnects

• Drivers are still catching up to the standard

Result:
The user sees:

• Frozen video

• Audio dropouts

• A “Reconnecting…” message

• Or a full disconnect and reconnect

Even though Wi‑Fi 6 is “better” on paper, the immature drivers and firmware make the experience worse.

Why This Happens

Wi‑Fi 5 (802.11ac)

• Released in 2013

• Had nearly a decade of driver refinement

• AP vendors fully understood roaming behavior

• OS‑level support was stable

Wi‑Fi 6 (802.11ax)

• Released in 2019

• Introduced major architectural changes

• Required new driver logic

• Required new AP firmware

• Required OS updates

• Required regulatory updates for 6 GHz (Wi‑Fi 6E)

When all of these moving parts are new, the NIC becomes the weakest link.

The Takeaway

Wi‑Fi 6 is better technology — but only when:

• The drivers are mature

• The firmware is stable

• The AP ecosystem is updated

• The OS supports the features properly

Until then, a well‑tuned Wi‑Fi 5 NIC can outperform a brand‑new Wi‑Fi 6 NIC in everyday tasks like:

• Video calls

• Roaming

• Latency‑sensitive applications

• Moving between rooms

• Dense environments

This is exactly why “new hardware = better Wi‑Fi” is a myth.

Unpolished firmware

Firmware controls roaming, power saving, and RF behavior. Early versions are notoriously unstable.

Compatibility issues with access points

A NIC might work flawlessly with one vendor and fall apart with another.

Poorly tuned roaming logic

Some NICs cling to a weak AP; others jump too early. Both behaviors break video traffic.

NICs With a Reputation for Problems

These aren’t “bad” products — but they’re widely reported as frustrating in real‑world environments.

Intel AX201 / AX211 (Wi‑Fi 6/6E)

Extremely common, extremely temperamental. Known for:

• Over‑aggressive roaming

• Driver regressions after OS updates

• Latency spikes during video calls

• Occasional firmware crashes

MediaTek MT7921 (common in Wi‑Fi 6 Chromebooks)

A frequent source of Chromebook Wi‑Fi complaints:

• Poor roaming

• Slow reconnects

• Weak DFS performance

• Random “Wi‑Fi disabled” states

Realtek RTL8822CE / RTL8852AE

Affordable, but not known for stability:

• Weak driver support

• Poor performance under load

• Unstable connections with certain APs

Killer AX1650 (Intel hardware + custom software)

The hardware is Intel, but the software stack complicates things:

• Driver conflicts

• Over‑aggressive QoS

• Roaming instability

Broadcom BCM43xx series

Mixed reputation, especially outside macOS:

• Limited driver support

• Poor Linux compatibility

• Roaming issues in dense environments

NICs People Actually Like

These NICs tend to be stable, predictable, and well‑supported.

Intel AX210 (Wi‑Fi 6E)

A major improvement over the AX201/211 line.
Better roaming, better stability, fewer complaints.

Intel I225‑V / I226‑V (wired)

Rock‑solid for most users, with mature drivers and consistent performance.

Qualcomm Atheros QCA6174 / QCA9377

Older, but extremely stable — especially on Linux.

Broadcom BCM4360

A surprisingly reliable chipset from the older MacBook Pro era.

Mellanox ConnectX‑3/4/5 (wired, enterprise)

If you want NICs that “just work” at high speeds, Mellanox is the gold standard.

How Roaming Breaks Video Traffic

Roaming is the process of switching from one access point (AP) to another.
A good NIC roams:

• Quickly

• Smoothly

• Without dropping packets

A bad NIC roams like this:

• Waits until the signal is terrible

• Drops the connection

• Reconnects to a random AP

• Re‑authenticates

• Re‑establishes DHCP

• Re‑establishes TCP sessions

During a video call, users will see:

• Frozen video

• Audio dropouts

• Pixelation

• “Reconnecting…” messages

This is why roaming behavior matters more than raw throughput.

The Tools That Reveal What’s Really Happening

These tools aren’t just for network engineers — they’re incredibly useful for anyone trying to understand why their NIC is misbehaving.

Wireshark

A packet capture tool that shows what’s happening on the network.

Great for:

• Identifying packet loss

• Seeing retransmissions

• Detecting roaming events

• Spotting authentication failures

Look for:

• Sudden gaps in traffic

• Burst retransmissions

• EAPOL messages

• Deauthentication frames

PingPlotter

A visual tool for tracking latency over time.

Great for:

• Detecting latency spikes

• Identifying jitter

• Seeing when roaming occurs

Look for:

• Spikes that correlate with movement

• Drops that align with AP transitions

iPerf3

A throughput and jitter testing tool.

Great for:

• Measuring real‑world bandwidth

• Testing stability under load

• Comparing performance between APs

Look for:

• Throughput that fluctuates wildly

• Jitter that increases during movement

• Drops when switching APs

Windows Event Viewer (Intel NICs)

Windows logs NIC driver resets, firmware crashes, and roaming events.

Look for:

• “Netwtw” errors

• “Device reset” messages

• “Roaming decision” logs

ChromeOS Diagnostics (Chromebooks)

ChromeOS includes built‑in Wi‑Fi logs.

Look for:

• Sudden RSSI drops

• “Roam triggered” messages

• “Wi‑Fi disabled” events

Troubleshooting a New NIC That Doesn’t Work Well

A structured approach that avoids unnecessary or harmful changes.

1. Update the Drivers

New NICs often ship with buggy drivers.
Check:

• Intel’s driver page

• Realtek’s official site

• MediaTek OEM support

• Chromebook OS updates

• Laptop manufacturer support pages

2. Update the Firmware

Firmware updates often fix roaming, stability, and power‑saving issues.

3. Check AP Compatibility

Some NICs simply don’t get along with certain access points.

Best places to check:

• r/networking

• r/sysadmin

• Ubiquiti, Aruba, Cisco, TP‑Link forums

• Chromebook community forums

Search for:
“ roaming”

4. Adjust Roaming Aggressiveness (Intel only)

On Windows:

• Device Manager

• Wi‑Fi adapter → Properties

• Advanced tab

• “Roaming Aggressiveness”

Medium‑Low or Medium often yields the best stability.

5. Test on Another Network

If the NIC behaves the same on:

• Home Wi‑Fi

• Work Wi‑Fi

• Mobile hotspot

…it’s the NIC, not the network.

6. Use Diagnostic Tools to Observe Behavior

Look for:

• High retry rates

• Sudden RSSI drops

• Frequent disconnects

• DHCP renewals mid‑session

• Driver resets

7. Consider Replacing the NIC

If your laptop allows it, swapping to a known‑good NIC (like the Intel AX210) is often the cleanest fix.

Chromebooks usually don’t allow NIC replacement, so software tuning is your only option.

Final Thoughts

A NIC is one of the most important components in your device — and one of the easiest to overlook. New hardware doesn’t guarantee stability, and some of the most advanced NICs are the ones with the roughest edges.

If your video calls freeze when you walk between rooms, or your Wi‑Fi 6 Chromebook drops off the network for no reason, you’re not imagining it. Roaming behavior, driver maturity, and chipset quirks all play a role.

The good news: with the right tools and troubleshooting steps, you can usually tame even the most temperamental NIC. And if not, at least you’ll know which ones to avoid next time.

Image from Meta AI

If you’ve ever typed your Wi‑Fi password into your Mac — slowly, carefully, triple‑checked — only to have macOS pop the box right back up at you…

You’re not alone.
And no, you didn’t type it wrong.
And no, you didn’t “break” anything.

In fact, this frustrating little loop is incredibly common on macOS Tahoe, especially on secure enterprise networks. The good news?
It’s totally fixable — and actually pretty simple once you know where macOS hides things.

This post walks you through the why and the how in plain English, with zero blame and no tech‑shaming.

Let’s get into it.

🌥️ Why Tahoe Gets Stuck in a Wi‑Fi Password Loop

Modern macOS versions don’t store your Wi‑Fi information in one place. They stash little pieces everywhere:

• Keychain Access (where your passwords live)

• Known Networks (your saved SSID list)

• System authentication caches (temporary but stubborn)

• MDM or company‑installed profiles (if you’re on a managed device)

If any of those copies becomes outdated, corrupted, or slightly mismatched, Tahoe does something very… Tahoe:

👉 It silently retries the wrong credential in the background.
👉 Each retry looks like a failed login to your company’s authentication system.
👉 Tahoe then prompts you again — even though you entered the correct password.

This is how people accidentally get locked out of their corporate accounts by doing absolutely nothing wrong.

🛑 Before You Fix Anything: Turn Wi‑Fi OFF

This step matters more than people realize.

Turning Wi‑Fi off prevents Tahoe from repeatedly slamming your company’s authentication servers with bad attempts while you’re trying to fix the issue.

Just flip the toggle off — we’ll come back to it later.

🔑 Step 1: Clear Old Wi‑Fi Credentials from Keychain

This is the #1 cause of repeated prompts.

1. Press ⌘ + Space

2. Type Keychain Access → hit Enter

3. Click Login on the left

4. Click System just below it

5. Use the search bar to look for:

   • Your Wi‑Fi network name

   • Your company name

   • Terms like 802.1X, EAP, or AirPort

Now delete anything clearly tied to that network:

• Old Wi‑Fi passwords

• Certificates

• 802.1X authentication tokens

Don’t worry — you’re not hurting anything. This just removes Tahoe’s stale credentials so it stops trying them over and over.

📡 Step 2: Remove the Network from “Known Networks” (Tahoe UI Changed This)

Apple moved this in macOS Tahoe, so don’t panic if it’s not where you expect.

1. Open System Settings

2. Click Wi‑Fi

3. Scroll until you see Known Networks

4. Click Edit or Advanced…

5. Remove your company Wi‑Fi network(s)

This wipes the saved profile — the macOS equivalent of netsh wlan delete profile on Windows.

🔄 Step 3: Restart Your Mac

Yes, really.

Tahoe caches network authentication in the background. A reboot clears those hidden caches and resets the Wi‑Fi subsystem cleanly.

🌐 Step 4: Reconnect (Cleanly This Time)

Now turn Wi‑Fi back on.

1. Choose your company network

2. Enter your password

3. When asked, choose:

   • Save to Login Keychain

   • Remember this network

If the cleanup worked, macOS will handshake normally and the password window will stay gone.

🗂️ Step 5 (Optional): Check for Company Profiles

If you’re on a corporate‑managed Mac (Intune, Jamf, etc.), the issue may not be your password at all.

1. Go to System Settings → Privacy & Security

2. Open Profiles

If you see:

• Wi‑Fi configuration profiles

• Certificates

• MDM enrollment profiles

…don’t delete them unless your IT team says so — but their presence tells you the problem might be server‑side, not something you did.

✨ You Didn’t Mess Up — Tahoe Did What Tahoe Does

Here’s the truth:

• macOS Tahoe retries silently in the background

• One stale credential causes endless failures

• Each retry looks like a bad login attempt

• That leads to lockouts and frustration

• None of this is the user’s fault

You didn’t forget your password.
You didn’t break your Mac.
You didn’t “fat‑finger it.”

The system just got confused — and now you know exactly how to reset it.