Wi-Fi seamless roaming

The boss called me into a conversation, told me to bring a laptop with me. It seems to be nothing - both there and in the workplace we have an office wireless network. We arrive - and the download of the large file delivered for downloading was broken, the SSH sessions were closed, the carefully typed web form was dropped for some reason when it was sent. Familiar?
Today we will talk about seamless roaming of devices in wireless networks Wi-Fi.


Roaming is the process of reconnecting a device to a wireless network while moving it in space. The received power of the radio signal weakens with distance to the transmitter, as a result of which the effective information transmission rate drops, channel errors grow up to the interruption of the wireless connection. If there is more than one access point in the radio network with one name (SSID), moving the mobile subscriber from the zone of reliable operation within the first access point to the zone where the signal from the second access point is of higher quality (higher power, higher signal-to-noise ratio) such a reconnection will occur.

The decision to reconnect is always made by the client device (Wi-Fi adapter driver). The access point can only “prompt” the device about the desirability of this action. Sometimes you can specify in the driver settings the parameter “aggressiveness” of making a decision. However, when the subscriber is initially connected, the centrally controlled system may “force” the subscriber to connect to the preferred (in terms of load) point and on the desired channel / band.

A seamless call is such a roaming mechanism in which the losses of data transmitted, occurring at the moment of switching from point to point, are minimal or equal to zero, and the TCP / IP stack of the client operating system does not even notice the fact of switching. Such a mechanism is important in the operation of delay-sensitive and lossy applications, such as voice over the radio network (Voice over Wireless), streaming video, large amounts of data and, in general, all cases where the TCP protocol is not able to “digest” the temporary loss of the transmission channel data.
')
We will set up experiments and take a look at the seamless roaming process implemented by means of a centrally controlled wireless network built on Juniper Wireless equipment, which was discussed in the introductory article . This is an enterprise-class system, specially designed to meet the challenges of seamless roaming. Then we will “break” the seamlessness and demonstrate what this leads to and what behavior we can expect from the devices of the “home class”.

Our network will have a regular Windows7 laptop with an integrated Intel WifiLink 5100abg card, two Juniper MX8 wireless network controllers in one LAN segment, two WLA532 access points, each configured for its own controller. We will create traffic to the laptop from the Linux server using the ping -f -s 1000 utility or ping -s 100 -i 0.05 . The same notebook will do spectrum analysis ( Wi-Spy DBx / Channelyzer Pro) and capture 802.11 frames ( OmniWiFi / OmniPeek).



To authorize subscribers (correctly, WPA2 Enterprise ) using the 802.1x mechanism, we will raise the FreeRADIUS server and configure it on PEAP / MSChapV2. At the same time, we will be able to monitor the “wireless controller – RADIUS server” traffic flow when the latter is launched via freeradius -X and track the events of full authorization and messaging of accounts. As a local user base - a text file with passwords.
Controller settings for authorization in our network " DOT1X " are identical and simple:

 set service-profile Secure-DOT1X ssid-name DOT1X
 set service-profile Secure-DOT1X 11n short-guard-interval disable
 set service-profile Secure-DOT1X rsn-ie cipher-ccmp enable
 set service-profile Secure-DOT1X rsn-ie enable
 set service-profile Secure-DOT1X attr vlan-name default
 set radius server debian64 address 172.16.130.13 timeout 5 retransmit 3 deadtime 5 encrypted-key 0832494d1b1c11
 set radius server debian64 mac-addr-format colons
 set server group debian64-group members debian64
 set accounting dot1x ssid DOT1X ** start-stop debian64-group
 set authentication dot1x ssid DOT1X ** pass-through debian64-group
 set radio-profile default service-profile Secure-DOT1X

We arrange the laptop so that the signal it receives from both access points (on 6 and 11 channels of b / g, 2.4 GHz) is approximately the same, connect to the network, launch ping, look at the distribution of energy in the air:



To check roaming operability it is necessary that the laptop starts receiving from the access point with which it is currently associated, the signal is significantly worse than from another point with the same SSID and encryption settings. You can carry a laptop, but I was not so comfortable, so I wore one of the access points (on a long Ethernet cable) closer or behind a concrete corner, and weakened the second signal, covering it with three nested steel pots, like a nesting doll. Each pan gave a reduction of 3-4 dB. As a result, at some point in time, the client "jumped" to another access point:



At the same time, the analysis of packets on the air shows such a picture (in order for OmniPeek to see all the traffic, I had to repeat all the experiments with points rigidly tied to the 11th channel, otherwise I would lose the most interesting thing while scanning on {6.11}).
The laptop tries to find a more preferred access point (probe request, frame 79086), and receives responses from both, with a signal level of 23% (current) and 63% (candidate).
The last useful frame 79103 is transmitted to the server via ap2 , after which frames 79122-79136 are quickly switched to ap1 , including authorization, reassociation, EAPOL exchange.



The reassociation request in frame 79126 contains the PMKID (Pairwise Master Key) key, which defines, roughly speaking, the identifier of this wireless session. If the access points work collectively (under the control of a single controller, or the controllers communicate with each other), the “new” access point checks the received identifier using its tables and, if found, skips the authorization step and immediately allows data exchange.



In our case, the first useful frame 79138 through the new access point, ap1 , went 90 milliseconds after the last one through the old one. The RADIUS server received only the account bouncing message from the point that was left alone:

 rad_recv: Accounting-Request packet from host 172.16.130.30 port 20000, id = 143, length = 264

All this worked so quickly only because both access points (or rather, the controllers serving them) have a common base of connected active client devices. To do this, the controllers are combined into a "mobility group". The name is selected, the initial “candidate for the main role” is set:

WLA-1:

 set mobility-domain mode seed domain-name LocalMobilityDomain
 set mobility-domain member 172.16.130.31

WLA-2:

 set mobility-domain mode member seed-ip 172.16.130.30

An example of a functioning mobility group:

 WLC-1 # show mobility-domain 
 Mobility Domain name: LocalMobilityDomain
 Flags: u = up [2], d / e = down / config error [0], c = cluster enabled [0],
        p = primary seed, s = secondary seed (S = cluster preempt mode enabled),
        a = mobility domain active seed, A = cluster active seed (if different),
        m = member, y = syncing, w = waiting to sync, n = sync completed,
        f = sync failed 
 Member: * = switch behind NAT
 Member Flags Model Version NoAPs APCap
 ---------------- ----- -------- ---------- ----- -----
 172.16.130.30 upa-- MX-8 8.0.2.2 1 12
 172.16.130.31 um --- MX-8 8.0.2.2 1 12

When subscribers are roaming between access points, the controllers exchange the subscriber context, including the history of its movements:

 Roaming history:
   Switch AP / Radio Association time Duration
   --------------- ----------- ----------------- ------- ------------
  * 172.16.130.30 5/1 06/28/13 22:12:22 00:06:34            
   172.16.130.31 2/1 06/28/13 21:57:28 00:14:54            
   172.16.130.30 5/1 06/28/13 22:08:56                     

Now is the time to model a typical office case when access points provide the same network, but they don’t know about each other. Break-do not build: remove mobility group membership on one of the controllers (clear mobility-domain mode member). Similarly, a roaming event triggered leads to more serious consequences:



Although the client sends the correct PMKID in the reassociation message (27818), the new access point confirms the association (27820) and immediately requests a full 802.1 re-authorization (EAP, 27823). This leads to a long chain of events, including sending messages to the “old” access point de-association (27887) andAs a result, an effective interruption in data transmission was 332 milliseconds. And in our experiment, the RADIUS server used a local database, i.e. did not contact a slow SQL server, did not ask permission in Active Directory, and did not deal with the transfer, verification and comparison of X.509 certificates.

In this article, we did not consider the various standard or vendor-dependent client roaming “assistance” mechanisms, such as WPA2 Fast BSS Transition (FT) 802.11r, Neighbor Reports, etc. Those interested can read this series of articles .

Summarize:

• Household access points operating autonomously from each other will force the client to perform a full authorization cycle when moving from one point to another. This is fraught with serious delays in the transmission of useful traffic, especially when using centralized user databases (you do not use a common password / PSK in a corporate environment) and, as a result, a disconnection of connections.
• Low cost, but centralized systems (Mikrotik, UniFi) are possible and will provide seamless roaming, but this depends on the implementation. For example, although UniFi has a “controller”, it serves only for general configuration of a set of access points with one interface, and at least in the software version 2.x, the access points continue to work autonomously and do not help roaming (I will be glad to offer to test these devices in the same way ).
• Enterprise-class wireless systems (Juniper, Cisco, Aruba, etc.) were originally designed to support seamless roaming; first of all they implement innovations like 802.11r on them. But you have to pay for it, and often a lot.