From-Scratch Build · Networking
Two software access points sharing one network name, tuned so a moving client can jump between them in tens of milliseconds instead of seconds. Rebuilt from scratch to learn how 802.11r fast roaming actually works at the configuration level.
What it is
When a Wi-Fi device moves away from one access point and toward another that advertises the same network name, it has to switch over — that switch is called roaming. Done the ordinary way it means disconnecting, scanning, re-authenticating and renegotiating encryption keys, and the gap can stall a video call or a live data stream for a second or more.
This build is a small testbed that makes that switch nearly seamless. Two virtual access points run on Linux and share one network, and a roaming client can hand off between them in tens of milliseconds. I built it to answer a concrete question: what exactly has to be configured for a connection to survive a handoff that a user never notices?
The core idea I wanted to learn: most of the time in a normal roam is spent re-doing security from scratch. Fast BSS transition pre-arranges the new keys ahead of time and folds the key exchange into the same frames that join the new access point — so the handoff costs milliseconds, not seconds.
The stack
The point of this rebuild was the configuration, not custom code. Here is what each component does in the testbed.
The user-space daemon that turns an ordinary Wi-Fi card into an access point. Its config file defines the network name, channel, security and the roaming behaviour.
Fast BSS Transition. Pre-computes the keys a client will need at the next access point so the handoff skips the slow re-authentication.
The WPA2 security framework, with pre-authentication so a client can prepare for the next access point while still attached to the current one.
Two access points sharing the same network identity, each with its own identifier, so the client perceives one continuous network as it moves.
An optional central authentication server for the enterprise path, deciding who is allowed to connect and feeding the access points their answers.
The configuration on the roaming device — credentials and roaming triggers — so it knows when and how to jump to the stronger access point.
Architecture
The scenario is three machines: two access points and one roaming client. Most of the build is wiring and configuration; the heavyweight enterprise authentication path I treated as optional.
A virtual AP running the access-point daemon with security and fast-transition turned on — the client's starting point.
A second virtual AP advertising the same network name and sharing the fast-transition keying material so a handoff is possible.
The mobility-domain and key settings both access points must agree on, so one can vouch for a client the other already knows.
A device configured with credentials and roaming thresholds, set to move between the two access points.
The simplest security mode — a single passphrase — which already gets fast transition working without any server.
A central server with a backing database for per-user logins. Wired conceptually, left as the stretch goal in this build.
How it runs
The whole exercise is about shaving steps off the handoff. A normal roam walks through every stage; fast transition collapses several of them:
In my rebuild I focused on the pre-shared-key path: bring up both access points with matching network and mobility settings, point a client at them, and watch it hand off cleanly enough to keep a live stream alive across the move.
Reflection