Posts

Showing posts from 2013

What are RadioTap Headers?

Image
I've been doing some study for my CWAP  (wireless analysis) exam recently, so I've been spending quite some time staring at Wirehsark traces trying to figure out precisely what all of those 802.11 fields actually mean. One thing I noticed whilst pouring over a few capture files is that some of them seemed to have some additional fields included in the trace, which seem to have nothing to do with fields defined in 802.11 frames at all. They are in a section of the packet decode called 'RadioTap Headers'. I wasn't too sure what they were and why they are available in some captures, whilst in others they were missing. After a little bit of research, I found out a bit more information and thought it might be worth sharing in a quick blog post. In summary, radiotap headers provide additional information that is added to each 802.11 frame when capturing frames with an analysis application. Just to be clear, these are not part of the standard 802.11 frame form

Antenna Radiation Patterns in the Real World

Image
I was recently reading through the most recent edition the finest WiFi text book in the world (in my opinion): the CWNA study guide . I read the previous versions a couple of times when I took my original CWNA exam and subsequent renewals. Looking through the latest book, I've picked up a a few nuggets which I either missed, or weren't included in the previous versions that I read. I had one "light bulb" moment when reading about antenna radiation patterns.  If you've ever looked at datasheets for antennas or access points, you may well have come across diagrams (like those shown below) that show the radiation pattern of an antenna. Fig1 - Antenna Azimuth Chart Fig2 - Antenna Elevation Chart There are generally two types of radiation pattern shown for each antenna: Azimuth (i.e. the RF radiation pattern when viewed from above the antenna) Elevation (i.e. a side-on view of the antenna RF radiation pattern) These are useful to unders

Defaulting Cisco LWAPP/CAPWAP APs When You Have No Login Credentials

Occasionally you may come across an instance where you need to reset a Cisco 'lightweight' AP to it's default configuration. However, if the AP is not associated to a controller and you do not know the local username/password of the AP, then this can be something of a challenge. In summary, here are the steps to default the AP when you cannot get in to the AP via the 'usual' methods: Put a console cable in to the AP and fire up your terminal emulation program Power up the AP with the reset button pressed at the same time Release the reset button after 15 - 20 secs On the console, you should now be dropped in to a ' ap: ' prompt. Type in the following command to see the files on the AP: ' dir flash:' One of the files listed should be 'private-multiple-fs' Enter the following command to remove the configuration: delete flash:private-multiple-fs Reboot the AP - you will be able to login to the AP using the usual defaults (i.e. enable

Devin was right...?

In the WiFi industry, there are fewer characters who are more polarizing than Devin Akin ( @DevinAkin ). I guess he is the 'Marmite' of the WiFi industry: you will generally be a huge fan, or maybe not so much :) I personally have always been a huge fan of the work he did when he was part of the CWNP organization - I would not be in the position I am now without the fantastic work that Devin and the guys over at CWNP have done in providing vendor-neutral WiFi certifications. However, back at the beginning of 2012, Devin had moved to Aerohive and was presenting at the WiFi Symposium, which was part of the Wireless Field Day 2 event. I watched all of the videos from that event and learned some very valuable information. However, Devin's presentation about Aerohive's architecture (which you can see at the bottom of this article), and his belief that in the future other vendors must move in a similar direction, was a 'light-bulb' moment for me. I had only been

Configuring DHCP Option 226 on a Cisco Router/Switch for an Aerohive AP

There are a number of methods of directing an Aerohive AP to find its instance of HiveManager, including using a DHCP option. In this quick tip, I share how to set up a Cisco switch or router DHCP server range to provide the correct  DHCP option to direct an Aerohive AP to a local instance of HiveManager. This is useful if you have a copy of HM running on your own appliance or virtual server. APs may be passed the IP address of HM via DHCP option 226. In the example below, APs are assigned addresses in the range 192.168.20.0/24. The Hive Manager server may be found at 192.168.50.7 in this example. The default router and DNS server options will need to be set to match your own environment. ! ! DHCP range for Aerohoive APs ! (HM address passed to AP using option 226) ! ip dhcp pool APs    network 192.168.20.0 255.255.255.0    default-router 192.168.20.254    dns-server 8.8.4.4     option 226 ip 192.168.50.7 Hopefully, this is all fairly self-explanatory if you are famil

The Missing Feature in WiFi Solutions: Performance Testing

In this article I suggest a nice feature that would provide a useful WiFi vendor differentiation and a valuable tool for administrators of WiFi networks. As a WiFi network value added re-seller (VAR) I visit a lot of customers, interacting mainly with the poor, down-trodden folks who comprise the IT department of an organisation. They are generally responsible for fending off the daily barrage of complaints about " the network" . In general, they are mainly concerned about two factors when it comes to their wireless network: coverage and performance. There are many other factors that they should probably be concerned about, but these are the two factors that tend to keep users off their back if they are both taken care of. Verifying WiFi coverage for an average IT administrator is generally very simple. They simply do a Google search download a tool such as Metageek's inSSIDe r and visit the area where users are complaining. Even if they don't manage to use

How Much Air-Time Do Beacons Actually Burn?

Image
It’s a well known rule of thumb when designing WiFi networks that you need to try to keep the number of SSIDs broadcast by your wireless network  down to a ‘reasonable’ number. In this article, I take a look at how much of an issue SSIDs (and their beacons) are in consuming valuable wireless air-time. Generally, it’s recommended to keep the number of SSIDs below around 5 (ish). The reason for keeping the number of SSIDs to a minimum is that each SSID is advertised using a type of management frame called a ‘beacon’.  Beacons are generally sent 10 times per second for each SSID on the wireless network. Therefore, if you have 10 SSIDs, they will each be advertised 10 times per second, giving us 100 beacons per second. Air-time is a finite resource – there is only so much data that can be transferred across the air over a period of one second. If a large chunk of air-time is being consumed by SSID beacons, then that doesn’t leave a whole lot of time remaining for actual user d

5GHz Unlicensed WiFi Channels in the UK - White Paper

(Note: this white paper has been superseded with this new updated version ) I put together a few articles a few months ago talking about how the unlicensed 5GHz band is used for WiFi here in the UK. I thought it might be a good idea to consolidate all of the information that I found in to one place, so that people researching the topic could find and digest it more easily. Therefore I put together a white paper about how 5GHz is used for WiFi here in the UK. You can download it from here. There will no doubt be errors, omissions and other facts that folks would like to suggest. So, please feel free to drop me a note and I'll update this document from time to time to improve the quality of information that it contains. Nigel. Download the document from the following sources: Scribd Google Docs

802.11ad - Just for Home Cinema...Right?

Image
One of the things I love about Twitter is that once in a while you stumble across something that completely shifts your view of the world. I spotted this little nugget (posted by  @wifichef ) a couple of days ago, which made me significantly re-assess my view of the application of 802.11ad technology: " A deeper dive in to High Capacity WLANs:  http://t.co/L6kcx5oMI9 " Expecting another deep dive in to 802.11n high density WLANs (...small cell sizes, using 5GHz, band steering, disabling lower speeds etc.) I clicked through the link to see if I could find any new information. However, I was completely surprised to find myself looking at a  whitepaper  discussing the merits of 802.11ad! In fact, it actually highlighted the disadvantages of a traditional 'legacy' WiFi network - this had me hooked :) I must admit that I had dismissed 802.11ad (which uses the 60GHz band) as a niche technology that I'd probably hardly ever see in the Enterprise environments that

Cisco ACS Policy Decisions Based on SSID Name

Image
If you're using an authentication server (such as Cisco's ACS) to make policy decisions about wireless users, there may be times when you'd like to make a decision based on the name of the SSID that the user is joining. In this article, we'll look at how you can do this. In this article, I'm going to assuming that we are using a Cisco wireless LAN controller, together with a flavour of Cisco ACS 5.x. I've seen this method used with Cisco ACS 4.x (see references at the bottom of this article) and wouldn't be surprised if you could modify the technique for other RADIUS servers. When Googling about this subject, I don't see any results that show how to do this in ACS 5.x, so thought it was worth a quick note. Background In brief, when a wireless client is attempting to authenticate to an SSID on a Cisco WLC network, if 802.1x is being used to authenticate users, then various RADIUS attributes are sent to the RADIUS server (e.g. ACS) as part of