Just under a year ago I finally got round to passing my CWNA. My plan at the time was to move on to the CWAP but the kindle edition of the study guide wasn’t available so I bought the CWDP book instead. To be honest I’ve started reading it a couple of times and not got very far with it but a few weeks ago I had a stern word with myself and committed to burying myself in it with a view to taking the exam before Christmas. Last Friday, full of cold, I made the trek over to the other side of the Severn Bridge to my lucky test centre in Newport and sat the exam. I’m delighted to say I now have another badge to pin to my chest.
I’m quite lucky in that I spend a fairly large portion of my time working on wireless design on fairly large projects. Having sat the Ekahau Design course earlier in the year and having read through the CWDP study guide I didn’t find the exam overly difficult. I’ll be honest and say the CWNA was probably a more difficult exam to prepare for. I do think however that the CWDP is a useful component of the professional level certifications offered and is definitely an area that will benefit as various initiatives to standardise and quantify the design process mature.
I’m looking forward to getting my teeth into CWAP. Kindle edition still isn’t available so I’m going to pick up a paperback edition and one of the older Peter Mackenzie books as a companion guide and make that my main objective for the first half of 2020. I can see many evenings ahead with just myself and wireshark for company.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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 ekahau.uservoice.com 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.
Last year we made a significant investment with Aerohive for our Halls of Residence wireless. We opted for the AP250 which hit a sweet spot for price, performance and power requirements.
Having made that choice for residences it was obvious we would give very serious consideration to their 802.11ax line now that we’re looking to refresh the campus infrastructure and so a few weeks ago I was excited to receive a parcel of AP650 and AP630’s to trial from AIT Partnership Group. We’ve deployed a few around the office and I’m now on a mission to get a couple working as survey AP’s for a major building refresh we have going on.
The trouble with this of course is that these things are meant to be ruled by the mighty cloud and when cut off from the outside world they go a little crazy. Left to their own devices if they can’t contact their Hivemanager they assume that something is broken and start broadcasting an SSID you can connect to to troubleshoot, a very useful feature unless you’re trying to use one for a battery powered AP on a stick site survey.
Another fly in the ointment is the fact that they use LLDP to negotiate power levels. Despite our power brick being fully 802.3at compliant, and having enough juice to drive a Cisco 2802i, when connected to an Aerohive device it is seen as an 802.3af device and certain features are disabled. In the case of the 600 series AP’s those certain features seem to be the radios! We’ve become used to seeing usb ports or certain antenna being disabled but to entirely shut down the radios is a new one on me and slightly alarming.
And finally we get to the fact that Aerohive have a shiny new mount. Based on a twist lock design it is indeed much better for attaching an AP to a ceiling rail. The force required to release the lock though is substantial and I’m already having visions of pulling ceilings down trying to retrieve these things in the future. Sadly it’s somehow not compatible with our trusty www.wifistand.com survey bracket. No one beats Cisco on the bracket front and this is another valiant attempt that doesn’t quite make it.
So on to the configuration required to make the AP behave and shout out a couple of SSID’s to survey with. Remember this configuration is purely for survey work, it is not meant for connecting users. What we want is a known transmission power on the 2.4GHz and 5GHz bands that ekahau site survey can identify and map for us.
So on a brand new AP we fire it up from a PoE+ battery and connect to it using our terminal program of choice via the console port. When asked to login we use the default credentials of admin/aerohive and set to work.
First we want to define a couple of radio profiles, one for wifi0 for 2.4GHz and one for wifi1 for 5GHz
radio profile Survey-2GHz radio profile Survey-2GHz phymode 11ax-2g radio profile Survey-5GHz radio profile Survey-5GHz phymode 11ax-5g
Then we’ll define a couple of SSID’s to broadcast and set our basic and supported rates.
Then we configure our interfaces with channel power and SSID’s to use
interface wifi0 radio profile Survey-2GHz interface wifi0 radio channel 6 interface wifi0 radio power 8 interface wifi1 radio profile Survey-5GHz interface wifi1 mode access interface wifi1 radio channel 36 interface wifi1 radio power 14 interface wifi0 ssid Survey-2GHz interface wifi1 ssid Survey-5GHz
Leave the lights on…
no system led power-saving-mode
Force 802.3at operation so that the radios work…
system power-mode 802.3at
Give our little friend a name and an address to stop the logs filling with dhcp requests and tell it to not try and get a time update from the mothership…
hostname UoB-Survey-APMODEL-X interface mgt0 ip 10.1.1.1 255.255.255.0 no ntp enable
And finally tell the poor thing it’s on it’s own and that the hive won’t be talking to it.
no capwap client enable
After that I normally stick a label on it with the power levels set on the radios for ease of future reference and then all that’s left to do is to try and work out how to attach it to this safely at 3.5m….
(Turns out a little brute force and ignorance will get you there as long as that plastic tab can withstand the strain – if anyone has any better suggestions please comment below)
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.