Wi-Fi Access Path: From Scanning to Data Traffic

The device log already says connected, but the application traffic still does not work. The problem is usually not one “connected” state. It is that 802.11 access, security setup, DHCP, DNS, and application connectivity have all been mixed into one step.

Treating “saw the AP,” “associated,” “keys installed,” “got an IP,” and “the service works” as the same state is one of the most common mistakes in Wi-Fi access. For embedded implementation, packet analysis, and debugging, these states have different observation points. If they are mixed together, the logs lose their diagnostic value.

The most common scenario is a STA (Station) connecting to a normal AP (Access Point). The scope here is Open / WPA2-Personal / WPA3-Personal. 802.1X, roaming, Mesh, Wi-Fi Direct, and advanced PHY details are left out for now.

Scan -> choose AP / BSSID -> 802.11 authentication -> association -> key installation / data plane ready -> DHCP / DNS -> application traffic

SSID (Service Set Identifier) is the network name. BSSID (Basic Service Set Identifier) is the identifier of a specific AP radio interface, usually its MAC address. The terminal sees an SSID, but it actually joins a specific BSSID.

Minimal Mental Model: First Split the Stages, Then Split the Layers

Wi-Fi access is easier to reason about if you split it into two layers:

• Wireless access layer: scanning, discovery, authentication, association, key installation, and the ability to send data over the air
• IP access layer: address acquisition, default route, DNS, and later business connections

Which layer to inspect first depends on the symptom:

At the field level, these five states should be kept separate:

• AP visible
• Associated
• Keys installed
• IP acquired
• Business works

They are not the same state. In many logs, connected only means one part of that chain has completed.

What Scanning Solves

When a STA powers up, it does not know which channel the target network is on. So the first step is scanning. Scanning is not about “should I connect,” but about “what candidates are currently in the air.”

The two most common methods are:

• Passive scan: listen for Beacon on each channel
• Active scan: send a Probe Request and wait for a Probe Response

What later judgment depends on is not just “did I find a Wi-Fi name,” but:

• SSID
• BSSID
• Channel
• RSSI
• Security capabilities in the RSN IE (Robust Security Network Information Element)
• Which bands and channels were actually scanned

Two common mistakes show up here.

• Seeing an SSID does not mean the connection will succeed. It only means an AP is visible in the air, not that the security and implementation are compatible.
• Seeing the same SSID does not mean you saw the same AP. One SSID can map to multiple BSSIDs, and compatibility problems often live in just one of them.

So when scanning fails, first check:

• Whether the device supports the target band
• Whether the target BSSID actually appears in the scan result
• Whether the channel list is complete
• Whether RSSI is too low for stable association
• Whether a hidden SSID makes active probing necessary

Why Authentication and Association Are Separate

After a candidate BSSID is found, the terminal enters the connection stage. Authentication in 802.11 does not always mean “the Wi-Fi password has been verified.”

For Open and most WPA2-Personal scenarios, the common path is Open System Authentication:

STA -> Authentication Request -> AP
STA <- Authentication Response <- AP

This is closer to “you may continue to the next step” than “the password has been checked.”

So a successful authentication only means:

• The AP allows the terminal to move on to association

It does not mean:

• The password is correct
• The later four-way handshake will succeed

Then comes association:

STA -> Association Request -> AP
STA <- Association Response <- AP

The association step mainly decides:

• Which capabilities the STA claims to support
• Whether the AP accepts the STA
• Which Association ID the AP assigns

For WPA3-Personal, there is an extra detail: the authentication stage is usually SAE (Simultaneous Authentication of Equals).

• WPA3-Personal does not leave all password-related authentication until after association
• SAE must succeed before association can continue
• Even after association, the four-way handshake still has to install the data-plane key

So “stuck in authentication” and “stuck in association” are not the same problem. “Association succeeded” and “data plane usable” are not the same problem either.

Useful fields to check here are:

• Association Response Status Code
• Whether capability bits match between request and response
• Whether RSN IE, supported rates, channel width, and PMF (Protected Management Frames) requirements match

Why You Still Cannot Send Business Traffic Immediately After Association

If the network is open, association usually means you can proceed to the IP layer. In an encrypted network, however, association only means the device has joined the BSS (Basic Service Set). The data-plane keys still have to be installed.

The two most common encrypted paths are:

WPA2-Personal
scan -> Open System Authentication -> Association -> 4-Way Handshake -> DHCP / DNS

WPA3-Personal
scan -> SAE -> Association -> 4-Way Handshake -> DHCP / DNS

In real debugging, these three states must not be collapsed into one sentence:

• Associated
• Keys installed
• IP acquired

Many field misreads come from treating those three as one state.

The security split between WPA2 / WPA3 / PMF is covered in Wi-Fi Security: WPA2, WPA3, and PMF. For the main-path judgment, the key point is that DHCP only really makes sense after the data-plane key has been installed.

Why DHCP / DNS Must Be Counted as the Next Layer

Once the wireless link can pass data, the device enters the IP access stage. The common flow is:

DHCP Discover
-> DHCP Offer
-> DHCP Request
-> DHCP Ack

DHCP usually gives more than just an IP address:

• IP address
• Subnet mask
• Default gateway
• DNS server
• Lease time

Even after that, application traffic still may not work. You still need to confirm:

• Can the default gateway be reached?
• Can business domain names be resolved?
• Can the TCP / TLS connection be established?

So “connected but no IP” and “has IP but application traffic fails” are not the same layer anymore.

Capture and system logs also get out of sync here:

In the same site, captures may already show association success while logs are still saying connecting; or logs may already say connected while the capture shows the four-way handshake is not done yet. Always map them back to the same stage before deciding where to look next.

What to Check First in the Field

The worst habit in the field is changing parameters first. A safer order is:

1. Check whether the target SSID / BSSID was actually scanned
2. If it was, see whether the failure happened in authentication, association, or security
3. After key installation, check DHCP
4. After IP acquisition, check the gateway, DNS, and later TCP / TLS

If you only want to keep the minimum evidence, save:

• Scan result: SSID / BSSID / Channel / RSSI / Security
• Authentication and association result: status code and disconnect reason
• Security stage: EAPOL / SAE / PMF
• DHCP result: address, gateway, DNS
• Business entry point: ARP, DNS, TCP / TLS

The value of that order is not that it covers every failure. It is that it helps you place the problem in the correct stage instead of vaguely saying “the device cannot get online.”

References and Further Reading

Specification Entry Points

• IEEE Std 802.11
  • Scanning, authentication, association: Clause 11
  • RSN / PMF / security negotiation: Clause 12
• RFC 2131: DHCP
• RFC 1034 / RFC 1035: DNS

Further Reading

• Wi-Fi Security: WPA2, WPA3, and PMF
• DHCP
• DNS