The Quest for a Secure Wi-Fi AP on Linux (Realtek Edition)

Posted on Feb 8, 2026

I recently set out to turn my ThinkCentre into a high-security wireless access point. My goal was simple: spin up a dedicated AP for my VR setup using modern WPA3-SAE security.

The hardware? A Realtek RTL8822CE. The result? A lesson in Linux driver limitations.

If you are trying to force WPA3 on a Realtek card and seeing supplicant-timeout errors, this guide is for you. Here is how I hit the wall, and the “Maximum Security” WPA2 configuration I used to fix it while staying FIPS-compliant.

The Problem: “Could not generate WPA IE”

I started by configuring a standard WPA3 Access Point using NetworkManager. My card claimed to support SAE (Simultaneous Authentication of Equals), so I ran:

nmcli con modify "VR_AP" wifi-sec.key-mgmt sae
nmcli con modify "VR_AP" wifi-sec.pmf required

It failed instantly. journalctl revealed the culprit:

wpa_supplicant[921]: Note: nl80211 driver interface is not designed to be used with ap_scan=2
wpa_supplicant[921]: Could not generate WPA IE.
wpa_supplicant[921]: WPA initialization failed.

Why this happens

While the RTL8822CE hardware theoretically supports WPA3, the Linux kernel driver (rtw88) currently struggles with it in AP Mode. It can connect to WPA3 networks as a client, but it crashes when trying to advertise one.

There are numerous threads on the kernel wireless mailing lists and Red Hat Bugzilla detailing similar issues with SoftAP mode on consumer cards.

The Solution: FIPS-Compliant WPA2-AES

Since “Pure WPA3” was off the table, the next best thing is WPA2-AES (CCMP) with Protected Management Frames (PMF).

By strictly enforcing AES encryption and disabling the older TKIP protocol, we achieve a setup that is:

  1. Stable on Realtek drivers.
  2. FIPS-Compliant (AES-only).
  3. Fast (802.11ac speeds).

Step 1: Unlock 5GHz Frequencies

Before configuring the AP, I had to ensure my regulatory domain allowed 5GHz usage. By default, Linux often blocks AP mode on 5GHz to prevent radar interference.

# Check your current setting
iw reg get

# Set it to your location (e.g., Montenegro 'ME' or US 'US')
sudo iw reg set ME

Step 2: The “Maximum Security” Config

Here is the nmcli command sequence that finally worked. I forced Channel 36 to avoid the 60-second DFS (radar detection) wait time that causes timeouts on many cards.

# 1. Clean slate
nmcli con delete "VR_AP"

# 2. Create the connection specifically on Channel 36 (Non-DFS)
nmcli con add type wifi ifname wlp1s0 con-name "VR_AP" autoconnect yes ssid "VR" \
  802-11-wireless.mode ap \
  802-11-wireless.band a \
  802-11-wireless.channel 36

# 3. Security: Force WPA2-AES (CCMP Only)
# This is the critical part. We explicitly disable TKIP.
nmcli con modify "VR_AP" wifi-sec.key-mgmt wpa-psk
nmcli con modify "VR_AP" wifi-sec.psk "YourSecretPassword"
nmcli con modify "VR_AP" wifi-sec.proto rsn
nmcli con modify "VR_AP" wifi-sec.pairwise ccmp
nmcli con modify "VR_AP" wifi-sec.group ccmp
nmcli con modify "VR_AP" 802-11-wireless.channel-width 80

# 4. PMF (Protected Management Frames)
# I set this to 'optional'. 'required' crashed the Realtek driver.
nmcli con modify "VR_AP" wifi-sec.pmf optional

# 5. Share the Internet
nmcli con modify "VR_AP" ipv4.method shared

# 6. Launch
nmcli con up "VR_AP"

Verification

To prove that the insecure TKIP protocol was actually gone, I checked the running interface:

iw dev wlp1s0 info

Output:

Interface wlp1s0
    ifindex 3
    wdev 0x1
    addr 82:2a:a9:cc:aa:d6
    ssid VR
    type AP
    channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
    txpower 23.00 dBm
    multicast TXQ:
        qidx: 0
        qlen: 0

Success! A stable, high-security AP running on hardware that fought me every step of the way.

Resources