When the University Enables PMF: Teaching FreeBSD's iwm Driver a New Trick

The rant: This is one of the problems where IT departments show that they are no help at all (searching excuses like “oh thats not supported” after doing a breaking change because someone in some hidden away team just flipped a switch) and where people always surface the unhelpful question “Have you asked IT department about this?”. Well and as usual: When there is a problem one just has to solve it by oneself. There is never anyone else to do this. So let’s go and solve that problem. And since it’s a technical problem there is always a solution that is not “not supported” or “buy new hardware”.

My university enabled mandatory Protected Management Frames, and my beloved notebook stopped connecting. The authentication configuration had worked before; the operating system and wireless card had not suddenly become useless overnight. Nevertheless, a network-side change had turned a routine part of my day into another software project. As I explained in Why I Prefer FreeBSD on All of My Machines, I use FreeBSD wherever I can, and usually also where somebody suggests that I cannot. I hate unnecessary change, have worked with FreeBSD for decades, and have absolutely no intention of going back to the hell of Windows or switching to chaotic Linux because a wireless feature is missing. Repairing the feature seemed the more reasonable response.

The temporary workaround was mobile-phone tethering followed by a VPN tunnel back into the university network. That was annoying, and it became costly when larger data transfers were involved. It is also worth explaining why the (private) notebook was there in the first place: in our academic setting, employees using their own equipment is perfectly normal. Scientific work brings particular software requirements and direct control of laboratory hardware. A centrally administered device on which every compiler, dependency or driver change becomes an IT request would prevent progress before the experiment had even started. We are not insane about this: laboratory networks are usually closed down and separated according to their purpose. The point is to retain control of the tools needed to do the work.

The result was a working experimental PMF implementation using the existing Intel Wireless-AC 8260 and FreeBSDs iwm driver. According to my timing, Codex helped to get to a working driver milestone in about 6 hours and 15 minutes, and it took that long largely because I was slow at reading suggestions and approving the next steps as well as reviewing code. That is the elapsed development story, not a claim that a complete wireless security qualification can be compressed into an afternoon. The distinction matters throughout this article: authentication and ordinary operation worked on the real notebook, while several security and lifecycle checks remain unfinished.

• What a Protected Wireless Connection was Still Missing
• Two different cryptographic paths
• Why iwm was a Useful Place to Work
  • Why not Simply Use the iwlwifi driver?
• What changed in the Kernel and Supplicant
• Replacing a Driver without Rebuilding the Kernel
• What the Actual Tests establish
• Conclusion: Keeping the System I Actually Want to Use
• References

What a Protected Wireless Connection was Still Missing

PMF and this implementation at a glance

Property	Meaning
Original specification	IEEE 802.11w-2009, later incorporated into IEEE 802.11
Protected traffic	Selected robust management frames, subject to association/key state
Unicast protection here	CCMP-128 with the pairwise key
Group protection here	BIP-CMAC-128 with IGTK and MMIE
Development system	FreeBSD 14.3-RELEASE-p14 GENERIC, amd64
Wireless adapter	Intel Wireless-AC 8260, iwm driver
Firmware	Unmodified stock 22.361476.0 firmware
Userspace	Modified BSD backend and completion hooks for wpa_supplicant 2.11
Delivery	Replacement if_iwm.ko plus matching supplicant; private ABI 3
Status	Working experimental client; complete security qualification remains open

A wireless network exchanges several kinds of frames. Data frames carry the traffic we normally think about: an SSH connection, a web request or a measurement file copied from a laboratory computer. Management frames establish and maintain the relationship between a station and an access point. Historically, protecting the data did not automatically protect all of that management conversation. A message claiming that the association had ended could therefore affect a connection even though the application traffic itself was encrypted. PMF addresses selected management frames, including deauthentication, disassociation and robust Action frames, by adding cryptographic protection and replay checks once the necessary keys exist. Its original specification was IEEE 802.11w-2009, the amendment was subsequently incorporated into the consolidated IEEE 802.11 standard.

This makes requiring PMF a defensible network-security decision. My objection was to losing a working connection, not to authenticating messages that can tear that connection down. PMF makes certain forged management messages ineffective against a correctly implemented protected association. It does not make a radio channel immune to interference, authenticate every frame sent before a connection exists, or replace the certificate validation used by enterprise authentication. An access point still needs its normal authentication policy, a client still needs to validate the server correctly, and applications still need their own appropriate transport security. Treating PMF as an additional, specific protection is more useful than describing it as a general switch that makes WiFi secure.

Two different cryptographic paths

The initial cipher target was CCMP-128 for individually addressed traffic and BIP-CMAC-128 for group management traffic. Those are distinct operations. A unicast robust management frame uses the pairwise key with CCMPs management-frame-specific nonce and authenticated-data handling. Group-addressed management traffic carries an integrity element with a management key identifier, packet number and authentication code. The body remains readable, but a receiver checks its integrity and rejects an old packet number. Consequently, testing only the Protected bit in the frame header cannot select every PMF verification path. Group management needs its own parsing, key selection and replay state, and it must not accidentally fall through to ordinary data-key handling. The controller documentation for 802.11w also describes the separate management protection and SA Query procedures.

SA Query handles another part of the problem: a station sometimes needs to establish whether its existing security association is still valid instead of immediately accepting an apparent disconnect. Implementing that behavior involves requests, responses, transaction identifiers, retry intervals and a bounded timeout. Association-comeback handling adds another timing boundary between the kernel’s association state and the supplicant’s expectations. These details explain why the project could not be reduced to advertising a capability bit or enlarging a key array. A client needs to negotiate, install the right keys, process the relevant frames and preserve the association state across all those operations.

Why iwm was a Useful Place to Work

The most useful property of this particular driver was how much of its cryptographic work already happened in software. Its transmit path calls into net80211 software encryption, and we did not need to introduce hardware management-key offload before implementing PMF. Receive frames were available to software with the information needed for the management protection path. That made it practical to add a private extension around the existing driver and stack interfaces while leaving the firmware itself alone. It was still necessary to verify the behavior on the card; readable source code cannot prove that a particular firmware will deliver every relevant frame in the expected form.

The firmware check was deliberately mundane. The firmware-transfer source file matched the local stock driver and the driver continued requesting firmware through FreeBSDs normal firmware subsystem. The tested card loaded the same 22.361476.0 firmware supplied by the stock firmware module. We did not flash the adapter, modify a firmware image or claim that a firmware flag alone would enable the missing feature. Preserving that part of the system reduced the number of moving pieces and made a rollback much easier to reason about.

Why not Simply Use the iwlwifi driver?

The Intel 8260 can also be driven by FreeBSDs newer iwlwifi driver in theory, so switching drivers was an obvious alternative to investigate. First switching drivers immediately lead to crashes that where only resolvable by PTX prompt work to get into the system again (what a surprise - the next component that spilled over from Linux that makes stability problems).

Second, it does not remove the underlying PMF problem: FreeBSDs management-frame protection support was still incomplete in the common wireless stack, including IGTK handling. I therefore stayed with iwm, whose software-crypto path also made it a particularly convenient place for this experiment.

What changed in the Kernel and Supplicant

The installed GENERIC kernel already contained important parts of net80211, so replacing those pieces wholesale would have complicated the goal of delivering a loadable module. Instead, the replacement if_iwm.ko contains a private PMF implementation and hooks at the necessary driver boundaries. The core handles management CCMP, BIP-CMAC, frame classification, replay state, fragmentation, SA Query and association timing. Private session state binds operations to a peer and an association generation. IGTK slots 4 and 5 remain distinct from data-key slots, while a private pairwise-key copy supports protected management traffic. The design preserves the public net80211 structure layouts and leaves ordinary data processing in the existing stack.

The matching supplicant is equally important. Its BSD backend communicates PMF policy, selected RSN parameters and management keys through a private control ABI. Completion hooks check that the kernel has the required PMF keys and can authorize the matching session before the supplicant reports success. A connection with incomplete management protection must not become an ordinary authorized data connection merely because EAP authentication succeeded. One concrete audit finding concerned a failed key callback: net80211 had already changed its software key before the private management-key installation could fail. The corrected callback therefore revokes private data authorization on failure instead of retaining authorization from the old session. That failure case was exercised offline, not deliberately induced on the campus network to prevent hearth attacks in the IT departement.

Departure ordering also needed care. A disconnect is itself management traffic, and it must be protected while the required key and firmware association still exist. Erasing the key first and trying to construct a departure frame afterward would defeat the purpose. The implementation retains the management context through departure submission and completion, then drains outstanding receive and transmit work before releasing the private state. Generation checks help reject work that belongs to a previous association, including frames that were delayed by reordering or reassembly.

Replacing a Driver without Rebuilding the Kernel

On the tested system we could stop WiFi, destroy its virtual interface normally, unload the current iwm module, load the replacement and recreate the interface without rebooting. Before doing that, we established wired access and temporarily suppressed only the relevant WiFi automation in devd. Otherwise, automatic interface scripts or module discovery could interfere with the controlled replacement. Every shell command was recorded in a write-ahead journal before execution, so a crash would leave evidence of the last intended operation. The feared interface-destruction hang did not occur during these tests, but successful teardown on one machine is not a universal guarantee.

For ordinary use the replacement module must run with its matching supplicant and the existing trusted network configuration. The intended persistent setup retains the original failover aggregation of wired and wireless interfaces; it does not require abandoning that network design. The deployment approach saves the installed module, places the matching userspace programs in a dedicated directory and selects the new supplicant through a service-specific configuration setting. The authentication configuration stays unchanged. A standalone shell rollback script restores the original driver and service configuration without requiring Python or networking. Persistent boot recovery also needs loader instructions: if a module panics before single-user mode, one must first boot without preloading that module. That recovery path is part of deployment engineering, not evidence that a reboot has already been tested.

What the Actual Tests establish

The corrected candidate authenticated to the enterprise network using the unchanged configuration, installed a pairwise key and an IGTK, and reached the private secured state. An ordinary DHCP exchange demonstrated data traffic beyond EAPOL, while a no-op DHCP configuration script preserved the wired address and route setup. A client-requested reauthentication completed another EAP and key exchange without a disconnect. A subsequent deliberate client disconnect and reconnect succeeded with a new session generation. Two protected departures were submitted and completed according to driver/firmware counters, and the stock driver was restored without a crash, hang or reboot. No malformed-frame, replay or disruptive network tests were performed against the live infrastructure.

Those observations have practical value, but they also have limits. We did not observe protected management reception during that session, so BIP receive and SA Query interoperability are not established by the connection result. Departure completion counters are not an independent over-air capture proving what the access point accepted. Offline tests use independently generated cryptographic reference frames and sanitizer-backed harnesses, including key rotation, replay boundaries and teardown ownership, but they cannot certify firmware behavior. Broader lifecycle tests, independent captures and an isolated environment for negative security tests remain necessary. Likewise, receiving a DHCP acknowledgment while deliberately preserving routes is not the same as validating ordinary routed application traffic through the new interface.

Conclusion: Keeping the System I Actually Want to Use

This project was possible within a day because of the magnificent and fascinating capabilities of OpenAI’s GPT-6-Astra running in Codex, combined with manual verification and real hardware checks. In my run, the working driver milestone took six hours and fifteen minutes, with a substantial part of that elapsed time attributable to me reading the suggestions and approving the next steps. Codex could inspect the kernel and supplicant together, implement changes, build them, exercise offline harnesses and follow the evidence from the notebook. That is a substantial improvement over treating every missing driver feature as a reason to replace an otherwise useful operating system.

It does of course not eliminate engineering responsibility. A model’s confidence is not a packet capture, an assertion is not an interoperability test and a successful connection is not a security certification. What we achieved was a working experimental path on the hardware I already owned, with the original authentication settings and an approach that can be packaged as a kernel module and matching userspace tools. For me, that is a much better outcome than accepting permanent tethering or changing the operating system. I get to keep using FreeBSD, and the missing capability becomes an implementation problem we can inspect and improve.

References

• GitHub repository containing the patched driver and supplicant
• FreeBSD
  • FreeBSDs iwm driver
• IEEE 802.11 standard
• Protected Management Frames
• Intel Wireless-AC 8260
• OpenAIs codex
  • GPT-6-Astra

This article is tagged:

• FreeBSD
• Network
• Security
• Programming
• Artificial Intelligence
• Vibe coding