The 802.11 State Machine – How a client joins a wireless network.

One of the most fundamental processes in wifi is how a client finds and connects to a wireless network. In this blog I’m going to explain to myself how I believe the process works having read the CWNA study materials, sat the ECSE Design course, reading a whole plethora of online blogs and listening to a range of podcasts discussing the subject over the last few months.

Very briefly the process of finding and joining a network is described by the 802.11 State Machine. There are four stages to this and we will look at each in more detail further into this post but for now a client goes through the following steps to get connected.

Unauthenticated and Unassociated

Authenticated but Unassociated

Authenticated and Associated.

Let’s start with the first elephant in the room. That Authenticated doesn’t mean what you might think it means. During this process there are two types of authentication that can be specified. One is Open System Authentication and is what you should see on nearly every single network today. As the name suggests this is a completely open standard and offers no security or encryption. The other is Shared Key authentication and my understanding is that this referred to the now deprecated WEP security standard, hence why you should be seeing Open System Authentication at this point in the connection process. WPA2 or 802.1x authentication which you might expect to see here actually happen after the association process is complete in a four way handshake.

So how does an unauthenticated and unassociated client find a network to join? Well there are two methods. The first, passive scanning relies on beacons from the wireless access point advertising what networks with what capabilities are available. An example of a beacon frame is shown below for the wireless network VM7535957 which is on channel 44.

An 802.11 beacon frame

By default beacons are sent every 102.4ms so roughly ten times per second. A beacon is sent on every radio in an AP for every SSID it is broadcasting so the number of beacons can soon add up. Beacons are also sent at the lowest configured mandatory data rate for each SSID so it’s easy to see why multiple SSID’s with support for 802.11b at 1Mbps can soon start chewing up your airtime. Dropping support for 802.11b clients and adjusting the mandatory rate to 12Mbps or 24Mbps can vastly decrease the amount of airtime consumed by beacons, even when running multiple SSID’s. A great source to illustrate this is the Revolution Wifi SSID Overhead Calculator which can be found at

Active scanning on the other hand relies on the client to send a probe request actively asking if there are wireless networks available in the area. Probe requests can either be for a SSID value of 0 (null probe request) which will receive a response from all surrounding networks or can specify a specific SSID (directed probe request) in which case only AP’s carrying that SSID will respond.  Probe requests are sent as broadcasts on the lowest mandatory rate supported by the client. The probe request below is a directed one looking for the network VM7535957.

Probe Request

A probe response, as seen below, is sent in answer to a request. Probe responses are unicast traffic so should receive an ack from the client to the AP. They are sent at the lowest common data rate between the client and AP. They are very similar to beacon frames in that they contain extensive information about the 802.11 parameters of the network.

Probe response

So at this point our client is still unauthenticated and unassociated but it now knows everything it needs to find a compatible network. At this point the client will run through it’s own set of metrics to decide which AP it wants to connect to for any given SSID.  Once it reaches a conclusion it will send an Authentication Request, as unicast traffic, to the AP. This request will contain the authentication algorithm Open System in this instance. As unicast traffic an ack from the AP is expected. You’ll notice there is no mention of the SSID that the client is hoping to associate with at this point, simply the BSSID of the AP it wants to connect to.

Authentication Request

In response the AP will send an ack and then an authentication response frame. This is also unicast and will also expect an ack from the client. The response should show that the authentication sequence is set to 0x0002 indicating a successful completion of open system authentication.

Authentication Response

At this point we’ve progressed to the point where we have an authenticated but unassociated client. In the wired world we’ve plugged the cable in. We’re connected to the AP but not the specific network. Our client continues on with the next part of the process, association. It does this by sending another request, this time the association request. The association request contains the SSID that the client is asking to join along with an extensive list of capabilities around channels, rates, phy’s, power and supported security types amongst others. Again it is unicast to the AP and requires an ack.

Association Request

Again the AP responds with an ack and then hopefully an association response. The AP compares the clients capabilities to its own and sends an association response. If successful the association response will contain a Status Code of 0x0000 and will assign the client an Association ID. If unsuccessful the Status code will be 0x0001.

Association Response

At this point our client is both authenticated to the AP and associated to the SSID. Technically we have reached the end for this post. We now just have the matter of any further security to negotiate before we can start passing data traffic. WPA2 or 802.1x security will now take place as part of a four way handshake between the client and AP. You can see this in the screenshot below immediately after the association response, corresponding ack and random beacon.

The 802.11 State Machine from Start to Finish

I’m looking forward to delving more into the 4 way handshake as I study towards the CWAP and CWSP over the coming months. I’m sure there’ll be a blog about it at some point.

My Experience on an Ekahau ECSE Design Course

In June I was lucky enough to attend the ECSE Design course in Oxford hosted by Open Reality and led by the brilliant Ferney Munoz CWNE #187. I’ve got about three years of experience with Ekahau Site Survey and have been using their new Connect suite since late in the beta program. I was joined on the course by a new team member who is completely new to wireless and had only done a handful of small surveys using the sidekick and iPad. It was going to be interesting to see how we got along with our differing experience levels.

I’d been wanting to do this course for some time. Having passed my CWNA in December last year and with the recent launch of the Ekahau Connect suite of tools I figured now was the ideal time to sit the class to consolidate what I’d learnt so far and make the most of the investment we’ve made with Ekahau before moving on to working towards my CWDP qualification.

It’s to the courses credit that we didn’t even open Ekahau Pro until late into the second day. The first day is spent going over RF fundamentals and making sure that everyone understands how these waves we use to transfer data actually work. It’s a great way to consolidate some of the CWNA material with particularly good explanations of how clear channel assessments are carried out and “the game” every station must play to gain access to the medium. Having self studied for the CWNA using the excellent Coleman and Westcott study guide I really benefited from these practical demonstrations and they really stuck in my head.

We also spent a long time hammering home that while we can try and influence clients through both good design and tools such as band steering and neighbour lists, at the end of the day each client has their own “green triangle” of metrics that they will use to decide what AP to associate with and when to roam and where to go. Basically, trying to manipulate your clients is about as reliable as herding cats, and just as frustrating.

With a clear understanding of how 802.11 behaves we moved on to looking at the wireless network lifecycle. Define, Design, Deploy and Validate! Then redesign and revalidate until it’s right. There were some great discussions from the wireless professionals in the room about the issues we’d all faced at various stages of this lifecycle and how we could overcome them, another of the huge benefits of sitting a class instead of reading the book.

Despite having been using Ekahau Pro for nearly three years I still picked up some great hints and tips on best practices from Ferney.  He provided a particularly welcome workaround for aligning non overlapping floors that I’d been struggling with on a recent project and really provided a proper deep dive into the programs advanced features. Over the next couple of days we did a mix of theory and practical exercises covering predictive, AP on a stick and validation surveys. We also looked at how we can use the sidekick to perform spectrum analysis and packet captures for some preliminary troubleshooting.

Towards the end of the day on Thursday we were joined by Nick Turner from Ekahau for a great chat about what’s going on with the Ekahau tools and he seemed genuinely interested in getting our feedback and thoughts on features we felt would improve the product. This is something I’ve always found with anyone I’ve spoken too at Ekahau, they genuinely want to make the best product they can for the wireless community.

As an early adopter of the Connect suite I can say that little increment on the licence cost is more than worth the extra functionality you unlock. For me it’s worth it for the iPad survey tool alone and when you then add packet capture from the sidekick it becomes a bit of a bargain, particularly for Windows users who’ve always struggled with packet capture options in the past.

My only real complaint with the Connect tools is that you can’t perform an APoaS survey with the iPad at this moment as you can’t freeze AP’s. I know I’m not alone in raising that and hopefully it will get added soon. There are a few other niggles but it’s a new product so that’s to be expected. Nick was very keen to promote the new feedback site that Ekahau are trialling to gauge demand for features over at so if you have any burning suggestions for the team head over there and make them known.

As Friday came around, we completed the final exam, spent some time looking at active surveys and Ferney shared some of his favourite tools and tricks one last time before we headed home in our separate directions.

I can definitely say that I would recommend the course to anyone working with wireless. It would definitely be beneficial if you’d read a little of the CWNA material first as I know some of the class found that heavy going initially but with the excellent tutors who run these classes no one is left behind.

I personally found it a great refresher of the CWNA material and it aligns nicely with my next goal of completing the CWDP qualification. It also taught me new tricks in Ekahau and I believe will make my designs more efficient and hopefully improve the wireless experience for the end users of my networks. It was another great step on the road to wireless enlightenment.

Oh and one last tip that was drilled into us – get on twitter, it’s where the wireless community lives.

Ferney Munoz CWNE #187 @Ferney_Munoz

Open Reality @OpenRealityUK

Ekahau @ekahau

Nick Turner @nickjvturner

Ekahau Suggestions and Feedback

Me! @NAIwifi

Hello world!

After spending a little time around our wireless community I’m taking up the challenge of starting a blog to record my travels through the world of all things 802.11 and beyond.

I am by no stretch of the imagination an expert in the field and you should not rely on any of my ramblings as gospel. They will be a record of things I learn and experience working in the sector and trying to keep pace with the constant change and innovation that makes wifi so much fun.

A little about me. I started out fresh from University working in a further education college in Nottingham in the UK as a network technician and part time lecturer on the GNVQ Advanced IT course, I was fortunate enough to be chosen as an instructor in our CCNA Academy when it was founded and spent a couple of years teaching students the joys of the OSI model and the wonders of vlans before heading off contracting for a few years with IBM Global Services for Astrazeneca in Loughborough as a network engineer. During these years I gained my CCNP and spent a lot of time swapping supervisor cards in 6500 chassis.

Following on from here I spent roughly ten years working at Bangor University in North Wales, initially looking after the halls of residence network before also inheriting the lion’s share of making this new fangled wireless malarky work. We were initially a Trapeze/Juniper site before beginning a migration to Aerohive when Juniper decided they couldn’t make an 11ac access point.

More itchy feet followed and I made the move to the University of Bristol just over two years ago where I continue to hone my skills. Last year I gained my CWNA and am working towards the CWDx level certifications and attempting to get to grips with Python and Ansible for giggles.

When not worrying about channel utilisations and malformed packets I’m a aviation anorak who can often be found glancing at the sky whenever anything interesting passes overhead, be it one of Bristol many hot air balloons or a B52 sneaking into Fairford.