Posts

Showing posts from 2018

The 5GHz “Problem” For Wi-Fi Networks: DFS

Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p

802.11 Roaming Variations Cheatsheet

Image
I recently saw a very interesting post from Gjermund Raaen  about Fast Secure Roaming, where he discusses OKC and 802.11r. This reminded me of some roaming issues I had recently observed with OKC myself, which got me looking up information to refresh my memory on a variety of roaming methods and standards. While looking in to the issue, I came across a classic blog post from Andrew Von Nagy about 802.11 roaming. It provides a superb summary of various roaming and security methods. I've read the post several times in the past, but thought that I would really benefit from a summary of its content to act as a memory jogger, rather than reading through the whole document again. For me, things get a little hazy when I start trying to remember the intricacies of the differences between EAP session resumption, PMK caching, OKC and PMK. To save myself some time for the next time I go through this loop, I put together a summary (Cheatsheet) of the content of the roaming variations

Updated White Paper on Licence-Exempt Spectrum in the 5GHz band for Wireless LANs in the UK

Image
For the past few years, I've maintained a white paper on the use of the 5GHz spectrum for Wi-Fi networks here in the UK. As Wi-Fi text books tend to focus on the spectrum available in the USA, I put this document together to clarify how 5GHz spectrum may be used in the UK. Following the release of a Voluntary National Specification document by Ofcom in August 2017 ( VNS 2030/8/3 ), additional channels became available for use in the UK on 5GHz. As we now have additional spectrum, it's time for an update to my white paper to detail the new spectrum that is available. Prior to updating the white paper, I published a summary sheet that shows the new spectrum allocation. This can be obtained obtain from my previous blog article:  UK 5GHz WLAN Spectrum Allocation (August 2017)  (this is definitely one to print off and laminate). I have now completed my updates to the white paper, which I am pleased to share with you now. Note that in addition to adding the new spectrum det

Scapy 802.11 Cheat Sheet

Image
I've been taking a look at Scapy as I've been learning more about Python. It's a great Python-based tool for capturing, analyzing and creating network packets. There are some great resources to learn more bout Scapy, and even some cheat sheets out there. But, as there were quite a few new concepts (for me) and my own interest is in Scapy for 802.11 related activities, I put together my own Scapy for 802.11 cheat sheet . You can grab a copy from here if it may be useful to you. References : Scapy 802.11 cheat sheet  Scapy docs: https://scapy.readthedocs.io/en/latest/ Building Network Tools With Scapy SANS Scapy Cheat Sheet

Randomized MAC addresses in 802.11 Probe Frames

Image
To address perceived privacy issues, some wireless clients adopt a randomized MAC address in probe frames when probing  for wireless networks. In this post  I take a quick look at how you might see clients using randomized MAC addresses.  Background When a wireless LAN client needs to find a nearby access point to join a Wi-Fi network, it has two choices: Passive scanning: a client will listen to beacon frames, broadcast by nearby access points, that advertise networks that it makes available. This can be quite a slow process, as a client cycles though channels and waits to hear beacons. Active scanning: a client will cycle through channels and send out probe frames to proactively query nearby APs for a specific wireless network (SSID). This will generally be a faster method of finding networks that the client is configured to join, and may be used by all clients in conjunction with passive scanning. One (unfortunate) side-effect of active scanning is that a client a

Wireshark Capture Filters for 802.11

Image
Generally, when performing over the air captures of WLAN traffic with Wireshark, the workflow adopted is as follows: pick a specific channel where target traffic resides switch the capture adapter to that channel capture all 802.11 traffic over the air on that channel Once a sample of traffic has been captured, the capture is stopped and analysis of the traffic using Wireshark's built-in display filters can begin. In most situations, this is the best workflow to adopt. It ensures that all required frames are captured. Filtering wireless traffic while capturing frames is very problematic due to the complexity of 802.11 frame exchanges. It is very easy to miss parts of interactions between stations if you filter traffic as it is being captured. However, there are a few edge cases where it may be useful to filter over-the-air frames at the point of capture. This will mean that only the filtered frames are available to display in Wireshark - all other frames are lost

Noise Floor Penalty of Wider Channels in Wi-Fi Networks

Image
I’ve been told a number of times that although wider channels in a Wi-Fi network generally provide a higher connection speed (and hopefully a higher throughout), it comes at the cost of increasing the perceived noise floor of the client device. I thought it would be interesting to test this out for myself. With the advent of 802.11n, it became possible to bond together the 20MHz wide channels of earlier standards in to 40MHz channels (though in reality, this was only practically feasible on the 5GHz band). Several years later, 802.11ac enabled us to bond together even larger chunks of contiguous channels and achieve 80MHz and 160MHz wide channels on the 5GHz band. Though 80MHz channels are not feasible in many environments and 160MHz is limited to very niche scenarios, they nonetheless are options. Theoretically, each time we double our channel width, we are going to double our connection speed and our throughput (there are some protocol efficiencies achieved which mean we may slightly

Ubuntu Wi-Fi Client Information

Image
When troubleshooting Wi-Fi connectivity issues, gathering information from the infrastructure side of the network is only half of the picture. In addition to understanding how your Wi-Fi network is configured and performing, it is critical to understand how the wireless network looks from the wireless client’s point of view. In this article I present a few useful snippets that may help you if you have an Ubuntu client that you need to investigate. Background Understanding AP channels plans, their transmit power, the coverage that they provide and a whole host of infrastructure-side parameters is very useful when diagnosing Wi-Fi client issues. However, even when you have (what you consider to be) a well designed, well configured network, there may still be some wireless clients that refuse to play nicely on your network. I recently had issues with a number of Ubuntu laptops that were having connectivity issues on a network I was investigating. Once you’ve checked the usual iss