Skip to main content

ch12_5

12.5 MAC Layer Management Entity (MLME)​

In the previous section, we talked about "sleeping" — how a client sleeps and how an AP keeps packets on its behalf. But this comes with a prerequisite: before going to sleep, the client must first make sure it has found the right "pillow" (AP), and that this "pillow" actually allows it to rest its head.

Establishing this trust relationship, along with its day-to-day maintenance (like switching to a different WiFi network, or moving around a room and switching to an AP with a stronger signal), falls outside the scope of data transmission. Instead, it belongs to the management layer.

In the grand architecture of 802.11, management tasks are divided among three pillars: the Physical Layer Management Entity (PLME), the Station Management Entity (SME), and the MAC Layer Management Entity (MLME), which is our main focus here.

In this section, we shift our gaze away from moving data packets and look at how the MLME handles chores like scanning, authentication, association, and roaming — much like a busy switchboard operator.

12.5.1 Scanning: Searching for Signals in the Air​

Imagine walking into a deep forest with a radio, wanting to know if there are any radio broadcasts. You have two ways to find out:

One is to listen quietly. You tune to a frequency, listen for any sound, and if there's nothing, you move to the next one. The other is to shout loudly. You tune to a frequency, shout "Is anyone there?" into the microphone, and if someone hears you, they'll reply "Yes."

In wireless networks, this is the difference between Passive Scanning and Active Scanning.

Passive Scanning​

In certain frequency bands — especially the higher 5GHz bands (where radar is frequently present) — regulations prohibit you from transmitting arbitrarily. You can't just send a Probe Request right off the bat; that's illegal. You must keep your mouth shut and keep your ears open.

In mac80211, when the scan request flags include IEEE80211_CHAN_PASSIVE_SCAN, the driver enters this "silent listening" mode. The station hops from channel to channel (Channel Hopping), staying on each channel for a short while, waiting to receive Beacon frames. Because Beacons are the periodic "heartbeats" broadcast by an AP, as long as the AP is present, you will eventually hear it.

Active Scanning​

In ordinary 2.4GHz/5GHz bands like those in homes or offices, time is money. Waiting for Beacon periods is too slow, so we usually take the initiative.

The logic behind active scanning is simple, even a bit blunt:

  1. Hop to a channel.
  2. Shout: "Who is an AP?" (Send a Probe Request frame).
  3. Listen for a second to see who shouts back (Receive a Probe Response).
  4. If nobody answers, switch to the next channel and repeat the process.

In the kernel code, this sequence of actions is triggered by the ieee80211_request_scan() method. The actual "shouting" action is specifically carried out by ieee80211_send_probe_req(). This function constructs a management frame with its frame control subtype set to IEEE80211_STYPE_PROBE_REQ.

During this process, switching channels is a technical task. It's not as simple as changing a variable; you have to tell the hardware to adjust the radio frequency. This is done by calling the ieee80211_hw_config() method, passing in the parameter IEEE80211_CONF_CHANGE_CHANNEL.

⚠️ Here is an easily confused concept In upper-layer applications (like wpa_supplicant), we often say "Channel 6," but in the eyes of hardware drivers, it only knows "Frequency 2.437 GHz." This is a one-to-one mapping relationship. The kernel has a dedicated function, ieee80211_channel_to_frequency() (located in net/wireless/util.c), responsible for translating human-readable channel numbers into frequencies that the hardware understands. If you are writing a driver and directly stuff Channel 6 into a register, the hardware will just stare at you blankly.

12.5.2 Authentication: The Initial Handshake​

Now, suppose that through scanning, your client discovers an AP with a strong signal. It wants to connect to it. But before allowing it to send data, the 802.11 protocol requires a formal procedure: authentication.

Note that authentication is not encryption. The "encryption key negotiation" in modern WiFi networks (WPA2/WPA3) actually happens during the 4-Way Handshake phase. The "authentication" at the MLME level discussed here is more like "knocking on the door to say hello."

In the kernel, the method responsible for this step is ieee80211_send_auth() (in net/mac80211/util.c). It sends a management frame with the subtype IEEE80211_STYPE_AUTH.

Open System Authentication​

The original 802.11 standard defined two authentication algorithms. One of them, which is mandatory to support, is called Open System Authentication, corresponding to the macro WLAN_AUTH_OPEN.

This is arguably the most hypocritical security mechanism in the world. Its flow goes like this:

  1. Client: "I want to authenticate."
  2. AP: "Granted." Yes, as long as you are a human (or a machine) sending a request, the AP will let you through. This is the so-called "Null Authentication." Although its security value is exactly zero, it is a mandatory step in the protocol flow. Even if you are going to use WPA2 encryption later, you must first go through this "Open System Authentication" to advance the state machine.

Shared Key Authentication​

The other ancient method is Shared Key Authentication, corresponding to the macro WLAN_AUTH_SHARED_KEY. This involves WEP (Wired Equivalent Privacy), an encryption standard that has been proven to be not only terrible but also full of holes. The general flow is that the AP sends a challenge text, the client encrypts it back with the WEP key, and the AP verifies its correctness. Because WEP has been completely obsoleted, this authentication method in modern drivers is more of a "I know it exists, but I try not to touch it."

12.5.3 Association: Establishing a Formal Connection​

After authentication passes, the client and the AP can be considered "acquainted." But to actually transmit data, the client must initiate Association.

You can think of "authentication" as shaking hands when meeting, and "association" as taking a seat and registering. Only after a successful association will the AP allocate resources for you, add you to its internal tables, and tell the switch that this MAC address is on its wireless port.

This step is completed by the ieee80211_send_assoc() method (in net/mac80211/mlme.c). It sends a management frame with the subtype IEEE80211_STYPE_ASSOC_REQ. This frame contains a lot of key information: which rates the client supports, which 802.11n/ac/ax features it supports, whether it wants to save power, and so on. Upon receiving this, the AP replies with a Association Response. If it carries a status code of 0, it means success.

12.5.4 Roaming: Switching to Another AP and Continuing​

As a user, you've definitely encountered this: you're connected to Router A in the living room, you walk to the bedroom, the signal weakens, but the system automatically switches to Router B (or another band of the same router), and the network barely skips a beat.

This is Roaming.

Roaming essentially happens between two APs (belonging to the same ESS, i.e., the same SSID). When your client finds that the signal quality of the current AP has degraded to an intolerable level, or when another AP with a better signal appears nearby, it decides to "jump ship."

This process is called Reassociation.

In the kernel, the ieee80211_send_assoc() function is reused. Why? Because "association" and "reassociation" share 99% of the same content — both need to send capability sets and wait for a reply. The only difference is that the frame subtype is IEEE80211_STYPE_REASSOC_REQ, and in this request frame, the client includes an extra piece of information: what the AP I was previously connected to is called (BSSID).

This information is very important. It's just like telling your new employer: "I just resigned from my previous employer, here is my resignation letter." The new AP will take this address, look it up in its tables, and finding that it's a sibling in the same network, will go to the old AP to synchronize your cached data (like the packets that weren't picked up while you were sleeping), achieving a seamless handover.

If all goes well, the new AP will reply with a Reassociation Response and conveniently assign a new AID (Association ID). Once you get this AID, you have officially settled into this new territory.

In this section, we pulled up a chair and watched a play unfold. We watched how a client scans channels like a radar, how it goes through "open authentication" completely unguarded, and how it officially takes a seat to associate. This is the daily routine of the MLME as a management layer — tedious, but indispensable.

Now, we have the foundation for data transmission (TX/RX), as well as lifecycle management (Power Save, MLME). Next, we will dive into the kernel implementation details of mac80211 and look at the core data structures that support the entire wireless framework. If we don't look at what ieee80211_hw and sta_info look like, our understanding of the Linux wireless stack will always be obscured by a veil.