Sunday, 27 May 2018

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

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.


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 (paid-for) licence to operate radio equipment.

All wireless services are generally subject to a range of enforceable technical restrictions to ensure they operate in a manner that will minimize interference to other wireless services. This may include restrictions on parameters such as RF transmit power levels and limiting the spectral characteristics of transmitted signals (e.g. channel widths used, spectral masks etc.).

Even though they may be licence-exempt, Wi-Fi networks are still subject to restrictions to minimize their impact on other wireless services and equipment in the same areas of spectrum used by WLANs.

One particular service that shares spectrum with wireless LANs is radar. Some types of radar installation operate in the 5GHz band that is used by Wi-Fi network. This means that they may use some of the same frequencies that are used for Wi-Fi networks. This doesn’t apply to all radar stations that have been deployed; there are many radar installations do not use 5GHz.

However, due to the coexistence of both radar and Wi-Fi networks in the same area of spectrum, the Wi-Fi standard (IEEE 802.11) was designed to incorporate a spectrum sharing mechanism on 5GHz to ensure that Wi-Fi networks do not operate on frequencies (hence causing interference) that are used by nearby radar stations. This mechanism is known as Dynamic Frequency Selection (DFS) and is designed to mitigate interference to 5GHz radar by WLANs.

How Does DFS Work?

DFS operation is as follows:

Channel Availability

Before an AP will use a channel that may be impacted by radar, it will perform a “Channel Availability Check” to check for radar signals on that channel. The AP will listen for 60 seconds for the presence of radar signals. If no radar is detected, then the channel is designated as being an “Available Channel”.

When powering up an AP that uses a DFS channel, you will see that the 2.4GHz radio becomes available as soon as the AP has completed its boot sequence, but the 5Ghz radio may not available for another minute. This is due to the AP performing its channel availability check, if the AP is trying to use a DFS-impacted 5GHz channel.

In some regions, where channels 120 – 128 are allowed for use by Wi-Fi networks, there may be an increased channel availability check of 10 minutes. This means that the 5GHz radio is not available until 10 minutes after the access point has booted up. This extended checking period is due to weather radar restrictions on those channels.

In-Service Monitoring

Once an AP is operating on a DFS channel, it has to monitor for the presence of radar signals appearing on that channel. This is known as “In-Service Monitoring”.

The AP must continuously monitor its channel for the presence of radar signals.
Channel Shutdown

If a radar signal is detected, then the AP must cease transmissions on the channel within the “Channel Move Time”, which is 10 seconds in the EU/UK.

At the end of this period, the AP will have ceased transmissions and moved to a new channel.

Prior to moving channels, some WLAN solutions may provide a “Channel Switch Announcement” 802.11 frame to connected clients to advise them which channel the AP will be moving to. Support for this on both WLAN infrastructure and client equipment seems to be optional from my own observations and should not be relied upon as a reliable method for clients to find the AP on its new channel.

Experience shows that there are variations between WLAN solutions around which channels an AP will choose to move to when radar is detected. In some solutions, APs that detect radar will move to channel 36 exclusively. In other solutions, APs will choose to move to any of the available non-DFS channels. Some will jump to any available 5GHz channel they find (DFS or non-DFS). Behaviour in this area seems to be inconsistent and is not defined within the 802.11 standard.

Non-Occupancy Period

Once radar has been detected on a channel, then the “Non-Occupancy Period” begins. This is a 30-minute period in which no further transmissions will be made by the AP on the affected channel.

At the end of the 30-minute period, most APs will attempt to return to their original channel, subject to a channel availability check. (Again behaviour in this area varies between vendors)

Radar Signal Characteristics

Radar signals themselves are very short duration pulses of Radio Frequency energy. In contrast to WLAN signals, they have no specific framing format, which makes their identification quite challenging.

Looking at the testing methodology in ETSI EN 301 893 V2.1.1 (Annex D), test pulses sent to WLAN gear under test may vary between 0.5 and 30 micro-seconds and be subject to a variety of test patterns. The table below is an extract from the document:

(Credit: Extract from ETSI standard: EN 301 893 V2.1.1)

The diagram below shows a single burst pattern that may be used to test WLAN devices:

(Credit: Extract from ETSI standard: EN 301 893 V2.1.1)

There is little doubt, that compared to the detection of well-structured, longer duration 802.11 frames, WLAN equipment has been set quite a challenge in reliably detecting radar signals (which can lead to annoying side-effects, discussed later).

Are All 5GHz Channels Subject to DFS?

No, not all channels in the 5GHz band are subject to DFS. The channels that are exempt vary from country to country, as dictated by local regulations. In the UK/EU, channels 36, 40, 44 and 48 are not subject to DFS. However, all remaining channels are subject to DFS. In the USA, channels 36 - 48, together with 149 - 165 are exempt from DFS operation, with all remaining channels requiring DFS operation. (Check your local spectrum regulation authority for the latest information for your country).

Channels that are not subject to DFS operate without having to perform any radar checks. Therefore, they are not subject to any disruptions from local radar equipment (or any other sources RF interference that may cause false-positive detection)

What Happens To Clients During a DFS Event?

Devices that are subject to DFS checks are divided in to two roles: master and slave. It is the role of the master device to advise slave devices when radar has been detected and that a channel shutdown is required.  In WLANs, the access point is usually the master device, with the associated clients designated as slaves.

Once radar is detected, it is the duty of the master device to advise the slaves that a channel change is imminent via a channel switch announcement message. This message should advise slaves (clients) which channel the AP intends to move to.

What Is The Impact on Client Applications During a DFS Event?

Once a radar signal has been detected, the impact on clients due to the required channel change is “variable”.

WLAN systems may or may not send a channel switch announcement (CSA). If no announcement is received by a client (or is lost in transit), then the client will be forced to go through its probing process to find a suitable BSSID with which to associate. Depending on the network configuration and client capabilities (e.g. 802.11k/v/r), the time to re-associate with the network will vary. Note that even if a CSA is received, a client may still choose to go through its own AP discovery process based on probing or 80.211k information it has received.

Once the move to a new channel has been completed, there will then be the usual delays in the resumption of application data flow due to processes such network access authentication and DHCP exchanges – these will again vary with network configuration.

Whatever the configuration of the WLAN and client capabilities, the move to a new channel will not be without some connectivity impact. This impact may be unnoticeable for users who are using non-real-time applications (e.g. mail, web browsing), but will certainly have an impact on latency sensitive, real-time applications (e.g. voice, video).

What Causes False DFS Detection?

Although DFS is, in theory, a great idea to protect systems that share the 5GHz spectrum, it has a major pitfall: false positives.

Detecting a radar signal signature is quite a tricky business. Due to the variety of radar signatures that may be detected, together with the short-duration nature of radar signals, false positive events may be quite frequent in some WLAN systems.

A false positive means that an AP is fooled into thinking that a radar signal is present by a non-radar RF signal. This causes a channel change, when one is not needed. This obviously leads to un-necessary WLAN disruption, that has varying impact on clients, depending on the applications in-use.

Theories around the exact cause of false positive events seem to be numerous, depending on who you speak with. I’ve heard the following possible causes cited:

  •  Transient conditions due to high densities of clients
  •  Bad client drivers causing short term RF spikes
  •  Co-channel interference from distant APs on the same channel
  •  Local non-Wi-Fi equipment interference

Whatever the cause, the false positives observed generally tend to be observed during times of increased user presence (i.e. they seem more likely during “office hours” as user numbers & activity increase).

How Do I Detect DFS Events?

To find out if your network is being impacted by DFS events, you need to check the trap logs or syslog messages from your wireless system.

All systems should report when a radar hit has been detected. This will generally be recorded in the logs of the AP, wireless controller or management system. Often this will be forwarded as an SNMP trap to a management system or perhaps as a syslog message to your logging server.
If you have log analysis and trending capabilities, it is well worth monitoring radar events to look for patterns of behaviour (e.g. particular sites, event times and channels)

What Do “Real” DFS Events Look Like?

You might be scratching your head at this point wondering how you can tell the difference between “real” DFS events and false positives.

In my experience, DFS events caused by genuine radar systems tend to be limited to a specific subset of channels on the 5GHz band. For instance, you may check your system logs and find that in a particular building, only channels 116 and 120 (for example) are reporting DFS events (i.e. radar hits). Also, these tend to be at a consistent rata throughout the day.

In contrast, false positives tend to be spread across a very wide portion of the 5GHz band and will vary in frequency throughout the day. They also generally fall to very low levels outside of office hours and at weekend (depending on the working patterns of your particular establishment).

How Can I Mitigate DFS Events on a Wi-Fi Network?

There are a few options available to try to mitigate the impact of DFS events on a WLAN:
  1. For genuine radar events that are impacting a subset of the 5GHz band, simply exclude the impacted channels from any channel planning. If using static channel planning, then avoid using affected channels. If using an auto-RF mechanism (i.e. automated channel planning), then exclude the affected channels from those available to the configuration of the auto-RF process
  2. Trying to mitigate false positives is a little more tricky. Options include:
    1. If you have sufficient non-DFS channels, do not use DFS channels at all in channel planning. This option is very much dependent on WLAN capacity requirements and the local regulatory domain in which the network operates
    2. Work with the WLAN vendor to find out if they have a more recent version of operating code that is less susceptible to DFS false positives. I have seen this approach used many times, with varying degrees of success
    3. Work with a vendor or VAR to try to identify any local sources of interference that may create false positives. Occasionally, it may be possible to identify a particular client type or item of non-Wi-Fi equipment that is causing false positives, If you have a support contract, assistance from a suitably qualified WLAN expert armed with a spectrum analyser and able to perform log analysis may be invaluable in tracking down offenders.
    4. If you vendor is unable to fix the issue, it may be worth trying an alternative vendor. Though this may seem extreme, I have seen huge variations between vendors and their susceptibility to DFS false positives. A limited-scope proof of concept costs little to deploy and can provide amazing leverage with your existing vendor…

What will be the impact of DFS on my Wi-Fi Network?

The impact of DFS events on your network (both “real” & false positive) will always be the same: a DFS event is detected and an AP will change channels. This will also cause the associated wireless clients to change channels.

The actual impact on the end-user will vary depending on what they are doing on their client.

Many applications that aren’t latency sensitive will simply continue with little obvious impact on service. If a user is browsing the web, sending email or even streaming a video file (assuming some buffering), they will generally not notice their client jump between channels as their associated AP changes channels. This assumes your WLAN is correctly designed so that clients have viable alternative APs available.

If clients are using real-time, latency sensitive applications, then they are much more likely to observe some sort of negative impact. The transition to a new channel is likely to be quite long (in WLAN terms). It will vary depending on the required operations (e.g. channel probing, 802.1X exchanges, DHCP exchanges etc.), but will generally be long enough to have an impact of real-time applications such a voice and real-time video. The use of enhanced WLAN features such as 802.11r/k may help to ensure that clients can significantly speed up the AP selection and roaming process.

These considerations provide a useful indication as to whether DFS events are going to provide problems on your WLAN and whether you should consider the impact of DFS on your wireless network.


In many Enterprise wireless WLANs, there will generally be a requirement to use as many unique 5GHz channels as possible. This provides opportunities to mitigate co-channel interference and increase capacity through the use of channel bonding (if required).

However, understanding and verifying the impact (if any) of radar detection is important to ensure the requirements of our WLAN design are not compromised.


Here are some other great sources of information you might like to look at for more information about DFS:

Saturday, 26 May 2018

802.11 Roaming Variations Cheatsheet

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 post. If you'd like to get a copy of the sheet, please feel free to download it yourself: 802.11 Roaming Variations


Sunday, 20 May 2018

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

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 details, I have added a few other topics around the use of 5GHz and the unique challenges that it presents. I'd recommend taking a look at my description of how DFS operates in Appendix 2, and have a play with the Opera weather radar location tool shown in Appendix 3.

I hope you find the update useful and informative.


Saturday, 21 April 2018

Scapy 802.11 Cheat Sheet

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.


Friday, 6 April 2018

Randomized MAC addresses in 802.11 Probe Frames

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. 


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 advertises its presence to anyone listening for probe requests in the vicinity. Even if the client is unsuccessful in finding and joining a network, it advertises its presence by continually probing for networks that it has been configured to join. The MAC address of the probing client’s wireless NIC is present, in the clear, in every probe request. 

The availability of the client MAC address, which is unique to that client, presents some potential privacy issues. Organisations that have wireless networks in multiple locations could, in theory, track the location of the client as it moves between sites. When coupled with other data sources (e.g. a login to a guest wireless portal for instance), it could allow tracking of an individual and gathering of behavioural data.

In order to combat these privacy concerns, some client vendors have taken the decision to randomise the MAC addresses that are used when probing for networks. This ensures that a client cannot easily be tracked as it moves between locations. Clients may use a randomised address to discover networks, but then revert to their “real” MAC address once they choose to join a network.


Although I’ve read about this behaviour, I’d never observed it first-hand. However, I recently spotted it, by accident, while testing some wireless tools. The tool that I was looking at was the ‘airodump-ng’ tool, which is part of the ‘Aircrack’ toolset. Aircrack is a suite of Linux-based pen-testing tools.

Airodump-ng is a wireless scanner that reports wireless networks, detected via beacons, from nearby access points. It also reports clients that can be heard probing in the vicinity. A screen-shot of the tool is shown below -  the top of the display shows the detected networks (discovered via beacons), the lower part of the display shows the clients (also know as stations) that can be heard probing.

Airodump-ng is generally used to scan across multiple channels to gather network and client data. However, it may also be configured to scan on a single channel of interest.

During my testing, I configured to my airodump-ng machine to scan on channel 52, as I knew there was an AP nearby using that channel. However, I noticed that in addition to the network I expected to see, I saw a client probing for a network called “Hidden _SSID”. This is a non-existent network that I had configured on my nearby MacBook Pro while doing some testing earlier in the day. I noticed, however, that the MAC address of the probing client was different to the actual MAC address of my MBP. 

I disabled and re-enabled my MBP wireless adapter several times. Each time I did this, a new MAC address appeared in the airodump-ng client list as the MBP probed with a new, randomised, MAC address. This is Apple MAC address randomization in action. You can see the effect in the screen-shot below:     

This is an interesting demonstration of the randomised client behaviour employed by Apple devices (among others). I thought this post might be useful for others who have not observed this feature, or perhaps aren’t aware that some clients exhibit this behaviour. 

I tried looking up some of the OUIs used in the randomized addresses using the online Wireshark OUI checker, but none of them corresponded with known manufacturer OUIs. The MAC addresses observed didn’t seem to be derived in any obvious way from the true MAC address of the MBP, they appear to be completely randomised.


** Update 7th Apr 2018

I received a Tweet from Arsen Bandurian about the randomized MAC addresses used by the Apple devices:

As he correctly states, the randomized MAC addresses being used are locally administered MAC addresses.  You can recognize a locally administered address by inspecting the 2nd least significant bit of the 2nd byte of the MAC address. This explains why I would never have seen any hits in the OUI lookup tool.   Thanks Arsen!

(If you got to the end of this article without falling to sleep, you did jolly well...)

Sunday, 1 April 2018

Wireshark Capture Filters for 802.11

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 - but in some rare cases, this may be what you want.

Capture filters are added prior to commencing an over the air capture with Wireshark, as shown in the screen-shot below (see green highlighted text):

(Note that if the capture filter text is highlighted in red (rather than the green shown above), then there is an issue with your filter that needs fixing. You can access the screen display shown above via the Wireshark menu items: Capture > Options

The filter language used for capture filters is different from the built-in filter language with which most people are familiar. Capture filters in Wireshark use Berkeley Packet Filter (BPF) syntax. You can find out more about the syntax here:

I thought it might be useful to provide some examples of capture filters for 802.11 (Wi-Fi) traffic, as I didn't find many examples when Googling around.

Here are a few example filters:
  • wlan type mgt - capture only management frames
  • wlan type ctl - capture only control frames
  • wlan type data  - capture only data frames
  • wlan type mgt subtype beacon - capture only beacon frames
  • wlan type mgt subtype deauth - capture only deauth frames
  • wlan type mgt subtype probe-req - capture only probe requests
  • not wlan mgt - do not capture management frame (i.e. capture data & control frames)
  • not wlan mgt subtype beacon - capture all frames except beacon frames
  • wlan type mgt and (subtype beacon or subtype probe-req) - capture only beacon  and probe request frames 
  • wlan type mgt and (subtype deauth or subtype disassoc) - capture on deauthentication and disassocation frames
  • (wlan type data) or (wlan type ctl and (subtype rts or subtype cts)) - capture only data frames and RTS/CTS control frames

By studying the examples above,you will likely be able to craft your own capture filters. However, you will need to understand the various types of 802.11 frame available and their roles to be able to construct valid filters (maybe take a look at the CWNA or CWAP certification programs if you are not familiar with these)

The following extract from the PCAP filter manpage provides all of the filter options available to you:

type wlan_type subtype wlan_subtype
True if the IEEE 802.11 frame type matches the specified wlan_type and frame subtype matches the specified wlan_subtype.
If the specified wlan_type is mgt, then valid wlan_subtypes are: assoc-reqassoc-respreassoc-reqreassoc-respprobe-reqprobe-respbeaconatimdisassocauth and deauth.
If the specified wlan_type is ctl, then valid wlan_subtypes are: ps-pollrtsctsackcf-end and cf-end-ack.

If the specified wlan_type is data, then valid wlan_subtypes are: datadata-cf-ackdata-cf-polldata-cf-ack-pollnullcf-ackcf-pollcf-ack-pollqos-dataqos-data-cf-ackqos-data-cf-pollqos-data-cf-ack-pollqosqos-cf-poll and qos-cf-ack-poll.

Again, it is worth stressing that most of the time, capture filters are not what you want. It is very easy to miss some important interactions unless you capture all frames over the air (e.g. it is no good capturing just data frames and not seeing deauth frames that are kicking your client off the network).

Saturday, 10 February 2018

Noise Floor Penalty of Wider Channels in Wi-Fi Networks

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 more than double our throughput, but lets keep it simple).

However, each time we double our channel width, so the theory goes, we also double the amount of noise our Wi-Fi station is exposed to. I guess this is (kind of) intuitive…

So here’s a quick check using my trusty Macbook Pro:

First of all, I connected to an SSID that is configured for a 20MHz channel width and took a look at the noise floor. In this instance, the noise is reported as –98dBm:

Screen Shot 2018-02-04 at 15.11.35

Fig 1 – 20MHz channel width

Next, I reconfigured the same SSID for a 40MHz channel width. Now, the noise floor was reported as –95dBm. Our noise floor had gone up by 3dB. (Sidenote: an increase of 3dB indicates a doubling of power).

Screen Shot 2018-02-04 at 14.57.30

Fig 2 – 40MHz channel width

Then, I reconfigured the SSID to double the channel width of the same SSID to achieve an 80MHz channel width. The noise floor increased by another 3dB (i.e. doubled again), changing from –95dBm to –92dBm:

Screen Shot 2018-02-04 at 15.17.31

Fig 3 – 40MHz channel width

The observed effect fits the theory. There, that’s 10 minutes of your life you’ll never get back….but never mind, at least you didn’t choose accountancy as a profession.

OK, so why are we really interested in this anyway? Well, the other aspect to this is that if you look back at the results again,  you can see that the received signal level has remained the same in each instance, but our noise floor has crept up. Our signal to noise ratio (SNR) has gone down by 6dB as we moved from 20MHz to 80MHz:

  • Rx_sig_level – Noise_level = SNR
  • 20MHz: –54dBm - -98dBm = 44dB
  • 40MHz: –54dBm - -95dBm = 41dB
  • 80MHz: –54dBm - -92dBm = 38dB

Our SNR values are  still very good in this example, but in an environment with a higher noise floor, a 6dB difference could make a significant difference. Many higher MCS values for 802.11n and 802.11ac rely on having high SNR values for successful operation. This means that a lower SNR could, in some environments have an impact on the higher speeds that are achievable across a network.

Well, that’s pretty much it. Hope this has been of interest.

(By the way, if you wonder how I got the additional Wi-Fi connection info on the Mac, when you click on the Wi-Fi symbol on the Mac top-bar, press the ‘alt’ key at the same time to see the enhanced connection info).

Monday, 29 January 2018

Ubuntu Wi-Fi Client Information

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.


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 issues that may cause connectivity problems, it’s time to try and understand the world from the clients view of the world. To do this, you need to gather data from the client so that you can see the network in the same way as the client sees it.

This can be quite a challenge, depending on the client-type and the tools that you may have available to you. This is particularly true in corporate environments, where locked-down, standard builds may be in-place. This can make it quite tough, so that you may need to get a little creative.

This article shows a few useful commands and code snippets I used to recently investigate issues on Ubuntu laptops. It’s certainly not a comprehensive guide to every command and tool available, but it will save me some hunting around next time I need to do this. :)

MAC Address & Interface Name Information

The first thing you need to know when investigating Wi-Fi client issues is the MAC address of the client. It’s also useful to know the name of the Wi-FI NIC interface to feed in to other commands that we’ll use later.The MAC address of a client in Ubuntu can be determined using the CLI (terminal) command “ifconfig” (see example screenshot below).

Multiple adapters may be listed (e.g. Ethernet, Wi-Fi etc.), depending on the hardware build of the Ubuntu machine. The “ifconfig” shows the MAC address of the adapter in the “HWaddr” field. In the example screenshot below, the ethernet adapter MAC address is 00:1c:42:38:58:e2.

The WLAN adapter name usually starts with a “W” (e.g.wlan0, or wlx687f74807e6f in the example below).

Fig 1 - Find MAC address and interface name using “ifconfig’

Wi-Fi NIC Information

It’s useful to find out a little more about the wireless NIC hardware to anticipate the clients’ capabilities. The CLI command “sudo lshw -C network” provides useful information about the Wi-Fi NIC card including the manufacturer, driver version and supported 802.11 amendments.

The screenshot below shows the output created by this command:

Fig 2 - Find Wi-Fi NIC driver info using “sudo lshw -C network”’

Channel Support

Hopefully, if you have modern wireless hardware and drivers, your client is going to support all of the available channels used on the 2.4 & 5GHz bands. But, it’s always worth checking to ensure that your clients won’t “blackhole” if they enter an area that is served by a channel that the client does not support. The CLI command “iwlist <adapter_name> channel” shows us the list of channel supported by the client. 

Note that the “<adapter_name> field above is the name we obtained for the Wi-Fi NIC using the “ifconfig” command.

Fig 3 - Find Wi-Fi NIC supported channel info using “iwlist <adapter_name> channel”’

Client Capabilities

If you are dealing with a client that is new to you, it is important to understand is capabilities. The command “iw phy” provides a wealth of information about the supported capabilities of the adapter.

I have provided a screenshot below of part of the output of this command, but the actual output is far more extensive and provides very detailed, rich information. This is information is invaluable for both troubleshooting and design activities.

Fig 4 - Find Wi-Fi NIC capabilities using “iw phy”

Client Connection Information

When a client is connected to a network, it is important to see how that connection looks from the client’s perspective. We may be able to see client connection  information by interrogating its information from a wireless controller or access point that the client connects to, but that is only half of the story (i.e. how the clients looks from the infrastructure perspective).

To understand the behaviour of a client, we also need to be able understand the other half of the “conversation” and see how the wireless infrastructure appears from the client’s perspective. The command “iwconfig” provides a useful view of how a client’s connection appears from the client’s view of the world.

The screenshot below shows the output of the “iwconfig” command. From the output, it is possible to see details such as the channel used, received signal level (probably the most important value) and connection speed.

It also provides an interesting field called “Link Quality”. This sounds interesting, but to date, I’ve not been able to determine what this actually means or what factors contribute to its value.

Disappointingly, the output does not report a noise or SNR value :(
Fig 5 - Find connection information using “iwconfig”

It can be very useful to repeatedly run the “iwconfig” command and capture its output (for example when assessing roaming behaviour). I’ve put together a short script to repeatedly run the command and output some of the output fields in a CSV format. The output can be reviewed manually or perhaps opened in a tool such as Excel to assess the data provided.

The script is shown below.

# Set the name of your Wi-FI NIC below (use output from iwconfig)

while [ 1 ]

RFINFO=(`/sbin/iwconfig $WIFINIC  | grep -oP '(?<=Signal level=)(.*)(?= dBm)|(?<=ESSID:")(.*)(?=")|(?<=Access Point: )(..:..:..:..:..:..)|(?<=Frequency:)(.*)(?=GHz)'`)


echo "$BSSID, $FREQ, $RSSI, $SSID"

sleep 0.5


Create this script using your favourite Linux editor and run it as shown below (hit Ctrl-C to stop it). I’ve named the script “” in this instance:

Fig 6 - Scripted output of the “iwconfig” command

(BONUS FEATURE: I did some additional work on this particular script and have put an improved version on GitHub:

Available Networks Information

Understanding which networks and access points a client is able to “see”, together with the information it has about each network, is useful when trying to understand client behaviour when troubleshooting.

Linux provides an incredibly useful command to provide detailed data about networks that can be seen by a client:  “sudo iw dev <interface_name> scan”. Note that the “<interface_name>” field is determined by using the output of the “ifconfig” command.

This command causes the wireless client to scan all channels and report on the Wi-Fi networks it hears. It is worth running the command a number of times, as it may not hear all networks each time a scan is performed - it is dependant on whether nearby networks are sending beacons at the time channels are scanned by our NIC adapter.

This is a command that requires elevated privileges to run, so is executed with the “sudo” command. Your (Ubuntu) user account must be capable of running with the elevated privileges required to run the command (i.e. root privilege).

A snippet of the output produced is shown below, though this represents a tiny fraction of the information provided. Each detected network is shown in significant detail, with data that is invaluable in troubleshooting scenarios:

Fig 7 - Sample output from the  “sudo iw dev <interface_name> scan” command

The output of the command can be quite tricky to wade through is you want a quick snapshot of what the client can see. A condensed version can be seen by applying some filtering with the grep command:

sudo iw dev wlx687f74807e6f scan | grep -o 'BSS ..\:..\:..\:..\:..\:..\|SSID: .*\|signal\: .*\|freq\: .*'

Fig 8 - Using grep to filter output from the  “sudo iw dev <interface_name> scan” command

Although this information is useful, it would be even more useful to have this data output in a CSV format. This is a little more challenging (for me) from a scripting perspective, so I have detailed a script to do this over on github: The really cool thing about the CSV option in this script is that you can save the output as a file to import into WiFi Explorer ( to do a little more analysis of the data (which is pretty dammed cool!).

Fig 9 - Importing CSV data in to WiFi Explorer


Unfortunately, the environment in which I was performing troubleshooting work did not allow me to install any new applications on the Ubuntu machines that I was investigating.

However, if you are able to install an application, I strongly recommend that you take a look at Wavemon. It's launched from a terminal window.  It isn’t necessarily as pretty as a full-blown, GUI-based app, but it’s fast and packs a lot of very useful information about the clients view of the “Wi-Fi world” in to a small space.

Here are a few screenshots showing the types of information you can get out of Wavemon. To install, you just need to enter the following terminal commands:

sudo apt-get update
sudo apt-get install wavemon

Fig 10 - Wavemon Link Information

Fig 11 - Wavemon Network Information

Here are few useful references from items covered in this article: