Mitigating the KRACK in WPA2 with WIPS

On Monday, security researcher Mathy Vanhoef disclosed a new vulnerability in the WPA/WPA2 four-way handshake, which has been branded KRACK. The attack is targeted and sophisticated, and it results in decrypting a TKIP or CCMP/AES encrypted session without knowledge of the PTK. WPA/WPA2-Personal and WPA/WPA2-Enterprise networks are vulnerable.

The attack takes advantage of client side implementations of the WPA/WPA2 protocol, which in some cases allows clients to reinstall the PTK and reuse cryptographic information in a way that allows the the attacker to decrypt the session. The PSK or 802.1X credentials are not compromised by this attack. I know that description is vague so if you want more, my favorite resource on this is this serious of videos from Hemant Chaska of Mojo Networks. Do yourself a favor and watch them all.

The ultimate solution to the vulnerability is to patch clients to prevent them from reusing the same cryptographic information when EAPOL keys are retransmitted. That will take some time, and there are a lot of clients, like IoT clients, which are unlikely to ever be patched. Windows and iOS clients with the latest security patches are already protected.

Fortunately, the attack relies on the attacker deploying an easy to detect and mitigate rogue AP. Today, without patching clients or the WLAN infrastructure, KRACK can be totally mitigated on a WLAN by configuring WIPS to auto-contain rogue AP’s that broadcast one of your own SSID’s. You need to tread lightly and understand the legal consequences before enabling auto-containment of rogue AP’s (Configure it for alerting-only first!). It’s best to get management and your InfoSec teams involved before taking this step so that the benefits and risks of auto-containment are understood by the organization.

Another solution is to disable retransmission of EAPOL frame M3 on the WLAN, but sometimes M3 needs to be retransmitted. If there was a collision or the frame arrived to quickly for the client to process, it should be retransmitted to complete the four-way handshake and prevent the client from going through a full reassociation. This is especially true for latency-sensitive voice clients which roam frequently, resulting in many four-way handshakes. These clients may be short on CPU cycles and free memory to quickly process EAPOL frames, and may require an occassional EAPOL frame retransmission.

Therefore, I prefer to mitigate KRACK by using WIPS to contain rogues that use the organization’s own SSID’s. As you can see from the test below, a Cisco monitor-mode AP will deauth a new client on a rogue AP before any data frames are transmitted.

In my testing, every client that associated to the rogue AP was deauthed before any data frames could be transmitted by the client.

Even simple probing on the channel resulted in a flood of deauth/disassociate frames from the monitor-mode AP to the client:


This attack works by setting up the rogue AP on a different channel from the target AP, so make sure you are scanning all channels for rogues. It’s also a good idea to setup notifications from your NMS in the event that a rogue is contained so that you are aware of potential attacks as well as false positives that require correction.

The one exception to WIPS protection appears to be CVE-2017-13082, which will require an infrastructure-side patch. This only affects SSID’s that use 802.11r.

So patch your clients, tune your WIPS, and relax! The sky is not falling.


macOS Wi-Fi Roaming

One of the nice things about Intel wireless chipsets is that the drivers expose a lot of controls to help tune the chipset’s operation. One of my favorite of these controls is “Prefered Band,” which I usually adjust to instruct the chipset to prefer the 5 GHz band over the 2.4 GHz band. There are some other useful controls like “Roaming Aggressiveness” and you can also enable Fat Channel Intolerance if a neighbor is rudely using 40 MHz of spectrum in 2.4 GHz.


Although macOS has many advantages over Windows when it comes to Wi-Fi, such as the ability to natively do packet captures with the internal chipset, macOS doesn’t have the same level of customization as a Windows machine with an Intel chipset. And my experience has been that Mac clients don’t roam particularly well. Too often they are “sticky clients” and you need to disable/enable Wi-Fi on them to get them to associate with a better BSS.

Here’s a screenshot for a MacBook Air which wouldn’t roam away from a BSS whose RSSI has fallen to -80 dBm, while the laptop was only able to transmit at MCS 0, 7 Mbps. However there was another BSS in the -60’s which would have allowed for much better Wi-Fi performance.

Why is the native macOS Wi-Fi menu showing a full signal with -80 dBm RSSI and MCS 0? Wi-Fi Signal tells the real story.

In 2016 Apple published a webpage that explains how macOS makes roaming decisions and what roaming features it supports. This is very helpful and I wish other manufacturers would do the same. The algorithms that control client roaming are usually a black box, so Wi-Fi engineers have make a lot of assumptions about them when designing WLAN’s for clients that require efficient roaming. That said, while Apple says Macs should usually roam at -75 dBm, that doesn’t match my experience. Sometimes Macs are just sticky.

One reason for this is that once the roaming threshold is crossed, a Mac will only roam to a BSS that is 12 dBm louder than the current BSS, which would require a roaming candidate BSS to have an RSSI of -63 dBm or better before roaming will occur at -75 dBm. There doesn’t appear to be any way to modify this value.

Enabling 802.11k or 802.11v won’t help because macOS does not yet support those features, although they don’t prevent Macs from using an SSID that has them enabled. 802.11k and .11v are supported in Windows 10, however, if the wireless adapter supports those features.

There is an old plist that once controlled “opportunistic” roaming behavior, which I suspect meant roaming above -75 dBm RSSI.


…which has these defaults in macOS 10.12 Sierra:

    deltaRSSI = 10;
    disabled = 0;
    useBonjour = 0;
    useBroadcastBSSID = 1;

That looks promising, however, this plist hasn’t been used by macOS since macOS 10.10 Yosemite. It’s ignored by the OS now, and when it was utilized, it wasn’t intended to be user-editable, so changes were likely to be overwritten by the OS.

So if you are an enterprise with a fleet of Macs to manage and you run into sticky client issues, consider infrastructure features like Cisco’s Optimized Roaming or Aruba ClientMatch to force better roaming behavior among these clients.

To observe roaming behavior on a Mac, I recommend WiFi Signal from Adrian Granados. It can be setup to generate macOS notifications when roaming events occur or the RSSI of the AP drops below a certain threshold.


Use Let’s Encrypt Certificates with FreeRADIUS


Let’s Encrypt is a certificate authority that generates TLS certificates automatically, and for free. It’s been great for web server administrators because it allows them to automate the process of requesting, receiving, installing, and renewing TLS certificates, taking the administrative overhead out of setting up a secure website. And did I mention it’s free and supported by all the major web browsers now?

Getting all of that to work with a RADIUS server is challenging however, mostly because of the way Let’s Encrypt works. The Let’s Encrypt client runs on a web server with a public domain name. The client requests a TLS cert from Let’s Encrypt and before Let’s Encrypt issues the cert, it verifies that the client is connecting from the same domain name that it is requesting a cert for, and that the client can put some hidden files on the server’s website. Do you see the problem? Unless you run a public-facing web server on your RADIUS server (unlikely), Let’s Encrypt will not issue certs to your server. It needs a web server it can interact with in order to validate the domain name of the client’s request.

Why use a certificate from a public CA like Let’s Encrypt for 802.1X/PEAP authentication? While a private CA offers more security, a public CA has the advantage of having a pre-installed root certificate on virtually all RADIUS supplicants, including BYOD clients that are unmanaged. If you don’t have an MDM or BYOD onboarding solution, you can’t get your private root cert onto BYOD clients very easily.

Unmanaged clients are a security risk, however, because the end-user can easily override security warnings that occur when connecting to an evil twin network with a bogus cert. A good MDM solution will allow network admins configure BYOD clients properly so that TLS failures cannot be bypassed.

A few considerations before you get too excited:

  • Again, a better, more secure solution is to use a private CA and distribute the RADIUS server cert to clients using an MDM solution and/or BYOD onboarding solution.
  • Let’s Encrypt certs are only good for three months at a time, and some supplicants will prompt users to accept the new certificate when it is renewed.
  • Build in some error handling, logging, and notification. E.g. an email from the web server when the cert renewal routine runs, including its output, and an email from the RADIUS server when it copies the new certs and reloads FreeRADIUS.
  • It works as root, but there’s probably a way to accomplish this without using root. Do it that way.
  • You can accomplish the same thing with Windows servers and Powershell.
  • You broke it, not me.

To get this working, we need a public web server with the same domain same as you’d use in your RADIUS server’s cert common name. This means internal domain names with a .local TLD won’t work.

I setup two Ubuntu servers, one running the nginx web server with a public IP, and another on my local network running FreeRADIUS. The web server will run the Let’s Encrypt client and create and renew the certs. The RADIUS server will copy those certs from the web server and use them for PEAP authentication. Once setup, the process of renewing and installing the certs on the RADIUS server happens automatically, just like it would on a web server.

First, a public DNS A record needs to be setup with the domain name which will be used on the TLS cert common name, we’ll use, and point it to the IP address of the web server.

Once that is done, you can install and run the Let’s Encrypt client on the web server. It works with Apache too, but if you prefer nginx like me, follow these directions to get it setup with Ubuntu 14.04 or Ubuntu 16.04. Don’t skip over the part about using cron to run the renewal routine.

Now that we have the certs on the web server, we’ll turn our attention to the RADIUS server. The first thing we need to do is setup ssh public key authentication between the two servers. I used the root account on both servers to do this, so that I would have permissions everywhere I needed it. With public key authentication in place securely copying the certs in the future can happen automatically, without getting stopped by a password request. Here are instructions to get that working.

Now we’ll start configuring FreeRADIUS on the RADIUS server. I’m assuming you already have a working FreeRADIUS server. I’m using FreeRADIUS 3, and you should be too. I like to use a separate directory for the Let’s Encrypt certs.

root@freeradius:~# mkdir /etc/freeradius/certs/letsencrypt/

Now let’s try copying the certs from the web server to this directory on the RADIUS server. If public key authentication is working, you should not be prompted for a password.

root@freeradius:~# scp /etc/freeradius/certs/letsencrypt/
root@freeradius:~# scp /etc/freeradius/certs/letsencrypt/

Did it work? If so, you should see the certs in the new folder we created.

root@freeradius:~# ls /etc/freeradius/certs/letsencrypt/
fullchain.pem  privkey.pem

Now we need to configure FreeRADIUS to use the Let’s Encrypt certs for PEAP authentication. I have a previous blog about using different CA’s for PEAP and EAP-TLS on FreeRADIUS that should come in handy here. If you are using EAP-TLS too, be sure not to change that CA from your private CA! All we need to do now is modify /etc/freeradius/mods-enabled/eap with our new certs in the TLS section used for PEAP.

root@freeradius:~# nano /etc/freeradius/mods-enabled/eap

tls-config tls-peap should be changed to:

tls-config tls-peap {
 private_key_file = ${certdir}/letsencrypt/privkey.pem
 certificate_file = ${certdir}/letsencrypt/fullchain.pem

If you aren’t using multiple TLS configurations, this section is named tls-config tls-common. You can leave it like that.

Reload FreeRADIUS for the change to take effect.

root@freeradius:~# service freeradius reload
 * Checking FreeRADIUS daemon configuration...               [ OK ] 
 * FreeRADIUS daemon is running
 * Reloading FreeRADIUS daemon freeradius                    [ OK ]

Now when connecting to the WLAN that is configured to use this RADIUS server for 802.1X/PEAP  authentication, the client is presented with a valid Let’s Encrypt server certificate.


OK, we have a working FreeRADIUS server using Let’s Encrypt certs for 802.1X/PEAP authentication. Now let’s automate the process of getting renewed certs from the web server to the RADIUS server. We’ll use scp and cron to get this done.

On the RADIUS server, add these commands to root’s crontab, with the appropriate domain names.

root@freeradius:~# crontab -e
# m h dom mon dow command
0 3 * * 1 scp /etc/freeradius/certs/letsencrypt/
0 3 * * 1 scp /etc/freeradius/certs/letsencrypt/
5 3 * * 1 service freeradius reload

At 3:00 AM every Monday, cron will run copy the TLS certs from the web server the reload FreeRADIUS at 3:05 AM to put them into production. Now the Let’s Encrypt certs are automatically installed on the RADIUS server a few minutes after they are renewed on the web server. The certs are good for three months at a time and renewable one month in advance, so you’ll get renewed certs automatically installed every two months.

Presto! You now have Let’s Encrypt certs automatically renewed and installed on your RADIUS server. While a private CA is a better solution for 802.1X authentication, this isn’t bad for a $0 software stack.

Clear To Send Podcast Episode 62: K12 Wi-Fi Deployments

podcast_logoI recently had the pleasure of joining Rowell Dionicio on the Clear to Send Podcast to talk about Wi-Fi in K12 schools. Clear To Send is a great podcast about enterprise wireless networking and a great way to stay current with the Wi-Fi community.

We talked about K12 requirements, challenges, funding, my design process, security, and everyone’s favorite K12 subject, 1 AP per classroom!

After listening to the podcast, I thought about some other K12 Wi-Fi considerations that I didn’t bring up on the air.

  • K12 often has requirements for mDNS applications like Apple AirPlay for AppleTV or Google Cast for Chromecast. This is a challenge in an enterprise network because mDNS does not cross layer 2 boundaries. It’s important to consider that when designing a new WLAN and selecting the vendor. Many WLAN vendors do have features that can assist with relaying mDNS traffic between vlans. Be careful to limit this traffic to only the vlans where it is required.
  • Excessive multicast traffic can be a burden on channel utilization when it is not controlled. Many WLAN vendors have features that intelligently filter broadcast/multicast traffic, instead of always forwarding it out the AP radio interfaces at the lowest data rate. If you are dealing with mDNS or large subnets (common in K12) it’s worthwhile to understand how the WLAN can manage broadcast/multicast traffic.
  • MSP’s are a great way to get well-designed enterprise Wi-Fi into small to medium size schools that don’t have the internal resources to handle it themselves. MSP’s can be hired to support and operate the WLAN after installing it, which gives them an incentive that VAR’s who just sell the hardware might not have–to design the WLAN properly. E-Rate funding is now available to reimburse schools for managed services contracts with MSP’s.
  • eduroam is available for K12 schools, not just higher education. Check it out!
  • It’s hard to listen to the sound of your own voice.

I really enjoyed talking Wi-Fi with Rowell and I’d love to return to the podcast in the future. Maybe we can talk about healthcare Wi-Fi next? Thanks Rowell!

Have a listen here: CTS 062: K12 Wi-Fi Deployments – Clear To Send

Chrome OS Wi-Fi Diagnostics


In the K-12 market Chromebooks are the most common devices used in 1:1 programs. If you are designing high density Wi-Fi networks for Chromebook 1:1 programs, it helps to know how to access their Wi-Fi statistics, logs, and networking tools. This knowledge is valuable for troubleshooting day-to-day Chromebook Wi-Fi issues as well.

The Basics

Despite its simplicity, Chrome OS, the Linux variant that Chromebooks run, does have some useful diagnostics tools that can help troubleshoot Wi-Fi problems. Most of these tools are included in the crosh shell, which you can open by typing Control-Alt-T. Here are some of my go-to crosh networking commands that don’t require an explanation.



This command provides some good Wi-Fi stats like retries, MCS index, and also RoamThreshold, which is the SNR at which this Chromebook will attempt to roam to a new BSS. Hopefully, one day we’ll be able to modify this value on enterprise-managed Chromebooks through the Google Apps admin console.

crosh> connectivity show devices

  Address: 485ab6######
  BgscanMethod: simple
  BgscanShortInterval: 30
  BgscanSignalThreshold: -50
  ForceWakeToScanTimer: false
  IPConfigs/0: /ipconfig/wlan0_0_dhcp
  Interface: wlan0
  LinkMonitorResponseTime: 3
  LinkStatistics/0/AverageReceiveSignalDbm: -61
  LinkStatistics/1/InactiveTimeMilliseconds: 8002
  LinkStatistics/2/LastReceiveSignalDbm: -62
  LinkStatistics/3/PacketReceiveSuccesses: 63919
  LinkStatistics/4/PacketTransmitFailures: 25
  LinkStatistics/5/PacketTrasmitSuccesses: 34432
  LinkStatistics/6/TransmitBitrate: 52.0 MBit/s MCS 11
  LinkStatistics/7/TransmitRetries: 60969
  Name: wlan0
  NetDetectScanPeriodSeconds: 120
  Powered: true
  ReceiveByteCount: 1610461765
  RoamThreshold: 18
  ScanInterval: 60
  Scanning: false
  SelectedService: /service/5
  TransmitByteCount: 133127986
  Type: wifi
  WakeOnWiFiFeaturesEnabled: not_supported
  WakeToScanPeriodSeconds: 900


This command is very useful in troubleshooting 802.1X issues. It shows more layer 2 details on all the BSS’s that have been discovered. In this case, /service/12 is an 802.1X network that the Chromebook is associated with, and /service/15 an open network also in range.

crosh> connectivity show services

  AutoConnect: true
  CheckPortal: auto
  Connectable: true
  ConnectionId: 2069398120
  Country: US
  DNSAutoFallback: false
  Device: /device/wlan0
  EAP.AnonymousIdentity: anonymous
  EAP.Identity: <username>
  EAP.InnerEAP: auth=MSCHAPV2
  EAP.KeyMgmt: WPA-EAP
  EAP.RemoteCertification/0: /OU=Domain Control Validated/CN=<cn>
  EAP.RemoteCertification/1: /C=US/ST=Arizona/L=Scottsdale/, Inc./OU= Daddy Secure Certificate Authority - G2
  EAP.RemoteCertification/2: /C=US/ST=Arizona/L=Scottsdale/, Inc./CN=Go Daddy Root Certificate Authority - G2
  EAP.RemoteCertification/3: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
  EAP.UseProactiveKeyCaching: false
  EAP.UseSystemCAs: true
  Error: Unknown
  GUID: 5137BA48-0424-41B0-B5DE-29A427084925
  HTTPProxyPort: 34599
  IPConfig: /ipconfig/wlan0_1_dhcp
  IsActive: true
  LinkMonitorDisable: false
  ManagedCredentials: false
  Mode: managed
  Name: <SSID name>
  PassphraseRequired: false
  PreviousErrorSerialNumber: 0
  Priority: 0
  PriorityWithinTechnology: 0
  Profile: /profile/chronos/shill
  SaveCredentials: true
  SavedIP.Mtu: 0
  SavedIP.Prefixlen: 26
  SavedIPConfig/2/Mtu: 0
  SavedIPConfig/5/Prefixlen: 26
  Security: 802_1x
  SecurityClass: 802_1x
  State: online
  Strength: 35
  Tethering: NotDetected
  Type: wifi
  Visible: true
  WiFi.BSSID: 00:11:74:##:##:##
  WiFi.Frequency: 5240
  WiFi.FrequencyList/0: 2412
  WiFi.FrequencyList/1: 2462
  WiFi.FrequencyList/2: 5240
  WiFi.FrequencyList/3: 5320
  WiFi.HexSSID: ########
  WiFi.HiddenSSID: false
  WiFi.PhyMode: 7
  WiFi.ProtectedManagementFrameRequired: false
  WiFi.RoamThreshold: 0
  WiFi.VendorInformation/0/OUIList: 00-03-7f

  AutoConnect: false
  CheckPortal: auto
  Connectable: true
  ConnectionId: 0
  Country: US
  DNSAutoFallback: false
  Device: /device/wlan0
  EAP.KeyMgmt: NONE
  EAP.UseProactiveKeyCaching: false
  EAP.UseSystemCAs: true
  Error: Unknown
  HTTPProxyPort: 0
  IsActive: false
  LinkMonitorDisable: false
  ManagedCredentials: false
  Mode: managed
  Name: <SSID name>
  PassphraseRequired: false
  PreviousErrorSerialNumber: 0
  Priority: 0
  PriorityWithinTechnology: 0
  SaveCredentials: true
  Security: none
  SecurityClass: none
  State: idle
  Strength: 44
  Tethering: NotDetected
  Type: wifi
  Visible: true
  WiFi.BSSID: 7c:69:f6:##:##:##
  WiFi.Frequency: 5320
  WiFi.FrequencyList/0: 5240
  WiFi.FrequencyList/1: 5320
  WiFi.HexSSID: ##########
  WiFi.HiddenSSID: false
  WiFi.PhyMode: 7
  WiFi.ProtectedManagementFrameRequired: false
  WiFi.RoamThreshold: 0
  WiFi.VendorInformation/0/OUIList: 00-10-18


This command brings up a lot of valuable information including a dump of the latest full channel scan and the Wi-Fi chipset’s capabilities, among other useful data.

crosh> network_diag --wifi

iw dev wlan0 survey dump:
Survey data from wlan0
 frequency: 2412 MHz
 noise: -92 dBm
 channel active time: 63 ms
 channel busy time: 49 ms
 channel receive time: 45 ms
 channel transmit time: 0 ms
Survey data from wlan0
 frequency: 2417 MHz
 noise: -93 dBm
 channel active time: 62 ms
 channel busy time: 47 ms
 channel receive time: 41 ms
 channel transmit time: 0 ms
Survey data from wlan0
 frequency: 2422 MHz
 noise: -92 dBm
 channel active time: 63 ms
 channel busy time: 4 ms
 channel receive time: 0 ms
 channel transmit time: 0 ms


Survey data from wlan0
 frequency: 5220 MHz
 noise: -94 dBm
 channel active time: 124 ms
 channel busy time: 0 ms
 channel receive time: 0 ms
 channel transmit time: 0 ms
Survey data from wlan0
 frequency: 5240 MHz [in use]
 noise: -94 dBm
 channel active time: 15723 ms
 channel busy time: 513 ms
 channel receive time: 185 ms
 channel transmit time: 3 ms
Survey data from wlan0
 frequency: 5260 MHz
 noise: -94 dBm
 channel active time: 85031 ms
 channel busy time: 84907 ms
 channel receive time: 84907 ms
 channel transmit time: 84907 ms


iw dev wlan0 station dump:
Station 00:11:74:##:##:## (on wlan0)
 inactive time: 5444 ms
 rx bytes: 11797197
 rx packets: 38419
 tx bytes: 1703260
 tx packets: 9779
 tx retries: 14295
 tx failed: 43
 signal: -58 dBm
 signal avg: -60 dBm
 tx bitrate: 24.0 MBit/s
 rx bitrate: 300.0 MBit/s MCS 15 40MHz short GI
 authorized: yes
 authenticated: yes
 preamble: long
 WMM/WME: yes
 MFP: no
 TDLS peer: no
iw dev wlan0 scan dump:
BSS 00:11:74:##:##:##(on wlan0) -- associated
 TSF: 61418055#### usec (7d, 02:36:20)
 freq: 5240
 beacon interval: 100 TUs
 capability: ESS Privacy SpectrumMgmt ShortSlotTime (0x0511)
 signal: -60.00 dBm
 last seen: 847370 ms ago
 Information elements from Probe Response frame:
 Supported rates: 24.0* 36.0 48.0 54.0 
 DS Parameter set: channel 48
 Country: US Environment: Indoor/Outdoor
 Channels [36 - 36] @ 24 dBm
 Channels [40 - 40] @ 24 dBm
 Channels [44 - 44] @ 24 dBm
 Channels [48 - 48] @ 24 dBm
 Channels [52 - 52] @ 23 dBm
 Channels [56 - 56] @ 23 dBm
 Channels [60 - 60] @ 23 dBm
 Channels [64 - 64] @ 23 dBm
 Channels [100 - 100] @ 24 dBm
 Channels [104 - 104] @ 24 dBm
 Channels [108 - 108] @ 24 dBm
 Channels [112 - 112] @ 24 dBm
 Channels [116 - 116] @ 24 dBm
 Channels [120 - 120] @ 24 dBm
 Channels [124 - 124] @ 24 dBm
 Channels [128 - 128] @ 24 dBm
 Channels [132 - 132] @ 24 dBm
 Channels [136 - 136] @ 24 dBm
 Channels [140 - 140] @ 24 dBm
 Channels [144 - 144] @ 24 dBm
 Channels [149 - 149] @ 30 dBm
 Channels [153 - 153] @ 30 dBm
 Channels [157 - 157] @ 30 dBm
 Channels [161 - 161] @ 30 dBm
 Channels [165 - 165] @ 30 dBm
 Power constraint: 3 dB
 BSS Load:
 * station count: 2
 * channel utilisation: 4/255
 * available admission capacity: 31250 [*32us]
 HT capabilities:
 Capabilities: 0x9ef
 SM Power Save disabled
 RX STBC 1-stream
 Max AMSDU length: 7935 bytes
 Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
 Minimum RX AMPDU time spacing: 8 usec (0x06)
 HT TX/RX MCS rate indexes supported: 0-15
 HT operation:
 * primary channel: 48
 * secondary channel offset: below
 * STA channel width: any
 * RIFS: 1
 * HT protection: no
 * non-GF present: 1
 * OBSS non-GF present: 0
 * dual beacon: 0
 * dual CTS protection: 0
 * STBC beacon: 0
 * L-SIG TXOP Prot: 0
 * PCO active: 0
 * PCO phase: 0
 VHT capabilities:
 VHT Capabilities (0x338001b2):
 Max MPDU length: 11454
 Supported Channel Width: neither 160 nor 80+80
 short GI (80 MHz)
 RX antenna pattern consistency
 TX antenna pattern consistency
 VHT RX MCS set:
 1 streams: MCS 0-9
 2 streams: MCS 0-9
 3 streams: not supported
 4 streams: not supported
 5 streams: not supported
 6 streams: not supported
 7 streams: not supported
 8 streams: not supported
 VHT RX highest supported: 0 Mbps
 VHT TX MCS set:
 1 streams: MCS 0-9
 2 streams: MCS 0-9
 3 streams: not supported
 4 streams: not supported
 5 streams: not supported
 6 streams: not supported
 7 streams: not supported
 8 streams: not supported
 VHT TX highest supported: 0 Mbps
 VHT operation:
 * channel width: 1 (80 MHz)
 * center freq segment 1: 42
 * center freq segment 2: 0
 * VHT basic MCS set: 0xfffc
 WMM: * Parameter version 1
 * u-APSD
 * BE: CW 15-1023, AIFSN 3
 * BK: CW 15-1023, AIFSN 7
 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec
 RSN: * Version: 1
 * Group cipher: CCMP
 * Pairwise ciphers: CCMP
 * Authentication suites: IEEE 802.1X FT/IEEE 802.1X
 * Capabilities: PreAuth 1-PTKSA-RC 1-GTKSA-RC MFP-capable (0x0081)
 * 0 PMKIDs
 * Group mgmt cipher suite: AES-128-CMAC
iw dev wlan0 link:
Connected to 00:11:74:##:##:## (on wlan0)
 freq: 5240
 RX: 11797197 bytes (38419 packets)
 TX: 1703260 bytes (9779 packets)
 signal: -58 dBm
 tx bitrate: 24.0 MBit/s

 bss flags: short-slot-time
 dtim period: 1
 beacon int: 100

That’s a lot more Wi-Fi data than most other platforms make natively accessible.

Additionally, to view most of this data without crosh, use this internal Chrome URL. Just enter it into the address bar and hit enter.


Areas of interest for Wi-Fi data:

  • network-devices – same output as the “connectivity show devices” crosh command
  • network-services – same output as the “connectivity show services” crosh command
  • wifi_status – same output as the “network_diag –wifi” crosh command
  • lspci – you can see the Wi-Fi chipset hardware here (more on that later)
  • network_event_log
  • netlog

Viewing Logs

You can start logging Wi-Fi events using this crosh command.

crosh> network_logging wifi

Old flimflam tags: []
Current flimflam tags: [device+inet+manager+service+wifi]

method return sender=:1.1 -> dest=:1.146 reply_serial=2
Old wpa level: info
Current wpa level: msgdump

View the resulting device event logs at this internal Chrome URL: chrome://device-log/

Run this command to view the kernel log, which includes a lot of Wi-Fi events. I wish there was a –follow option, but currently there is not.

crosh> dmesg

A restart will return the Chromebook to normal logging levels.

And if you really want to bury yourself in logs, go to chrome://net-internals/#chromeos, click Wi-Fi to enable debugging on that interface, let the “capturing events” count creep up while you perform a task, then click “Store debug logs” to save a debug-logs_<date>.tgz archive in your Downloads folder. Be warned, the signal to noise ratio is very low with this approach. Google provides a log analyzer that you can upload these files to, but I’ve never had the need to go that far down the road. This is best used if you need to submit logs to the Google Apps Enterprise Support Team or a hardware manufacturer.

Advanced Wi-Fi Analysis with Developer Mode

But wait, there’s more! If you can put a Chromebook into Developer Mode, you can run packet captures and break into the Linux bash shell. Most enterprise-managed Chromebooks will have this mode disabled for obvious reasons, but it’s easy enough to move your test Chromebook into a test OU and disable this and other restrictions for testing purposes. (That’s IT testing, not high-stakes student testing! Make sure your OU’s clearly differentiate the two.)

Packet Capture

First, determine which channel’s frequency you’d like to run the capture, and also if channel bonding is in use. The internal URL from above will work for this as well as the “network_diag –wifi” crosh command. The frequency of the currently associated BSS is displayed at the end of that output here.

iw dev wlan0 link:
Connected to 00:11:74:##:##:## (on wlan0)
 freq: 5240
 RX: 11797197 bytes (38419 packets)
 TX: 1703260 bytes (9779 packets)
 signal: -58 dBm
 tx bitrate: 24.0 MBit/s

 bss flags: short-slot-time
 dtim period: 1
 beacon int: 100
Screenshot 2016-05-09 at 2.37.00 PM
Disable the Wi-Fi NIC here.

Now turn off the Wi-Fi NIC in the GUI so it can be put into monitor mode.

You can now run the packet capture using the crosh command below.

Optionally, specify a secondary channel above or below the primary if you are doing a 40 MHz 802.11n capture by appending the “–ht-location <above|below>” flag.


crosh> packet_capture --frequency <frequency in MHz>

Capturing from phy0_mon.  Press Ctrl-C to stop.
^CCapture stored in /home/chronos/user/Downloads/packet_capture_7K08.pcap

You’ll get a pcap file complete with Radiotap headers if the hardware supports it saved in the Downloads folder which you can send to another machine to do analysis. If the Chromebook is all you have available, you can upload the pcap to CloudShark for analysis.

Wi-Fi Troubleshooting in Bash

Once you’ve got Developer Mode enabled, you can use the bash shell and follow the network log (or any other log) as things happen. This is my preferred way to troubleshoot Chromebook Wi-Fi issues in real time.

crosh> shell
chronos@localhost / $ tail -f /var/log/net.log

Now go do something to the Wi-Fi connection and watch the log scroll by.

A few Linux networking commands you may already know are available here as well like ifconfig, arp, and netstat.

Wi-Fi Chipset and Driver Information

While you’re in the bash shell, you can also determine the Wi-Fi chipset hardware in use. The output of this lspci command will only show the Wi-Fi adapter and the driver it is using. The basic output of lspci is included in chrome://system, but this method allows you to get more data. Add a -v flag or two to see even more.

crosh> shell
chronos@localhost /sys $ sudo lspci -nnk | grep -A2 0280

01:00.0 Network controller [0280]: Qualcomm Atheros AR9462 Wireless Network Adapter [168c:0034] (rev 01)
        Subsystem: Foxconn International, Inc. Device [105b:e058]
        Kernel driver in use: ath9k

This Acer C720 Chromebook has a Qualcomm Atheros AR9462 and uses the ath9k driver.

Run this command to discover the Wi-Fi chipset driver version. This is helpful if you want to know if the Wi-Fi chipset drivers were updated during a system update.

crosh> shell
chronos@localhost / $ sudo ethtool -i wlan0

driver: ath9k
bus-info: 0000:01:00.0
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

In this case no version number is reported, perhaps because the OS is using a generic Atheros driver that is packaged with the Linux kernel.

Below is the output of the same commands on an HP Chromebook 11 G4 running Chrome OS 41. This machine has an Intel Wireless-AC 7260 chipset and the driver and firmware-version are listed.

crosh> shell
chronos@localhost / $ sudo lspci -nnk | grep -A2 0280

01:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] (rev c3)
        Subsystem: Intel Corporation Dual Band Wireless-AC 7260 [8086:c070]
        Kernel driver in use: iwlwifi
crosh> shell
chronos@localhost / $ sudo ethtool -i wlan0

driver: iwlwifi
version: 3.10.18
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

The driver version appears to just be the Linux kernel version. The firmware-version is the chipset driver version.

Interestingly, after updating this HP Chromebook to Chrome OS 50, the Wi-Fi chipset firmware-version changed… but went down.

crosh> shell
chronos@localhost / $ sudo ethtool -i wlan0

driver: iwlwifi
version: 3.10.18
firmware-version: 16.229726.0
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

An inspection of the iwlwifi version history shows that this driver is actually newer than the previous version. Before version 16 it was the third number in the version that indicated what major branch it came from, so version was actually from the version 10 branch. Thankfully, that’s cleared up in newer versions of the driver so that the first number is the version branch.

It’s good to see that Google includes Wi-Fi chipset driver updates with Chrome OS updates. This is especially nice as system updates are downloaded and installed automatically to Chromebooks. Personally, I’ve seen system updates resolve odd Chromebook Wi-Fi problems and it’s possible the newer drivers are the solution.

Making RRM Work

There’s been a lot of good discussion within the Wi-Fi community recently about the viability of radio resource management (RRM), or the automatic selection of channels and Tx power settings by proprietary vendor algorithms. At Mobility Field Day 1 there was this excellent roundtable.

Personally, I usually fall into the static design camp, for many of the same reasons as others. I don’t want RRM to change the carefully tuned design I put in place and create an unpredictable RF environment, I’ve seen RRM do some very peculiar things like put adjacent AP’s on the same channels or crank up the Tx power of 2.4 GHz radios in an HD environment, RRM doesn’t disable 2.4 GHz radios when CCC is present, and it doesn’t plan DFS channels properly. Still, I’ve tried to keep an open mind.

Static designs have their limitations too. Statically designed WLAN’s can’t react to new neighboring networks contending for the same airtime, or new sources of RF interference that weren’t there when the static design was developed. It’s a real benefit of RRM that it does automatically correct for these problems.

Let me propose a hybrid approach that uses static design to handle the things that RRM does poorly, while still allowing RRM to react to the changing RF environment.

Static Design Elements

  • Tx power levels should be statically assigned. Once finely tuned as part of the design process, why would they ever need to change?
  • Excess 2.4 GHz radios in high density environments should be manually disabled because RRM simply won’t do this.
  • DFS channels should be statically planned. RRM can clump DFS channels near one and other, resulting in a 5 GHz dead zone for clients without DFS support. Also, because of these clients, DFS channels should only be used when non-DFS channels are all already deployed. Therefore, statically plan DFS channels when needed in areas where non-DFS channels create secondary coverage, and let RRM dynamically plan the other bands. It’s less likely to have a neighbor or transient hotspot appear in the DFS bands anyway.
  • Set channel channel bandwidth statically. The design process includes considering the capacity requirements of the WLAN to determine the appropropriate 5 GHz channel bandwidth. RRM algorithms don’t know what your capacity requirements are. 2.4 GHz should always be 20 MHz.

Things Left to RRM

  • 2.4 GHz channel planning, once excess radios are disabled. Channels 1, 6, and 11 only, of course.
  • 5 GHz channel planning, once DFS channels are statically assigned.
  • That’s all.

The benefit of this approach is that it addresses many of the shortcomings of RRM while still retaining its main benefit: the WLAN can dynamically react to RF interference and transient neighbors by moving affected AP radios to clear spectrum. The things that RRM can’t do or does poorly are simply removed from its control.

Even within these constraints, there are still some vendor’s RRM algorithms I trust more than others. And even those I trust enough to try this with, I’d still want to monitor regularly to make sure the WLAN hasn’t turned into the RRM trainwreck the I’ve seen all too often when RRM is given free reign.

This is How Wi-Fi Actually Works

I decided to write this blog because there appears to be a very common misunderstanding about how Wi-Fi works among end-users and even many network administrators as well. Instead of repeating myself, I can share this link with folks that need a little lesson in 802.11 operation.

Wi-Fi is does not work like AM/FM broadcast radio.

Well, in some ways it does, Wi-Fi radios transmit and receive radio frequency energy (RF) just like AM/FM stations do, but it’s operation is much more complex. If you are stuck in the AM/FM radio analogy, you’ll make several mistakes with Wi-Fi, such as:

  • Coverage is considered, not capacity. Again, if Wi-Fi were a one-way radio broadcast like AM/FM radio, you’d only need to provide a strong “Wi-Fi signal” for everything to work well. This leads you down this next path.
  • The “Wi-Fi signal” (using this term might be a tell that the person speaking is stuck in the AM/FM radio analogy) is too low, so crank up the AP’s transmit power to make it louder.
  • Every problem is thought of as an infrastructure problem, client radios are not considered when troubleshooting.
  • Getting hung up on the vendor’s name that is on the access point, without considering what is much more crucial, the overall design that went into the network.

How Wi-Fi Actually Works

Wi-Fi is not a one-way broadcast from AP to clients like AM/FM radio. This is not how Wi-Fi works:

Nope. Not like this.


It’s a network. The AP and clients connected to it must all be able to transmit and receive to and from each other, more like this:

Note that while the intended destination of a transmitted frame is usually just one other radio, real RF transmissions radiate in all directions, and are heard by all clients.


Because they are all operating on the same channel, each client or AP must wait for the others to stop transmitting before it can transmit. It works just like Walkie Talkie radios. Only one radio can transmit at a time, everyone else must listen and wait. Additionally, they all need to be close enough to hear each other so that they do not transmit overtop of each other, causing interference that corrupts the communications. The channel they are using is what’s called a shared medium.

If they can’t all hear each other, they will transmit overtop of each other which results in corrupted frames (not packets, Wi-Fi operates at layer 2) that must be retransmitted. The bigger the cell, the worse this problem becomes (the hidden node problem). So when you crank up the transmit power of an AP to increase its coverage, you exacerbate this problem, because the AP is now serving clients that are further apart from one and other.

In many networks, the majority of Wi-Fi clients are smartphones with low-power radios and meager antennas. They already have difficulty hearing other clients further away in the cell. For networks like this, performance can be greatly improved by lowering the transmit power of the AP rather than increasing it.

Further, because the channel is a shared-medium, it has limited capacity. There is only so much available capacity to transmit in a single channel. Faster clients can transmit, well faster, and therefore use less of that capacity, known as airtime. Older or cheaper clients that are slower use more airtime to transmit the same amount of data. It doesn’t matter what vendor’s name is on the access point, airtime is airtime. Once a channel is saturated, that’s it. You can’t add more clients to it without leading to degraded performance. You can’t alter the laws of physics. At this point you need to add another AP to utilize the capacity of a different channel, or replace slow clients with faster ones.

Regardless, it’s worthwhile to intuitively understand the nature of Wi-Fi networks, so that these common pitfalls can be avoided. Many other Wi-Fi best practices that I haven’t outlined here stem from this foundational knowledge. Based on this, can you think of other things that might affect Wi-Fi performance?


This is a simplification of 802.11 operation meant to give those new to the subject a casual understanding of how it works. Sometimes 802.11 frames are broadcast, one-way-only, from the AP to all clients in the network. Some management frames and broadcast frames from the wired network are broadcast this way. The important point to remember is that this is the exception, not the rule, and if all clients cannot hear each other, there is still the possibility that this broadcast traffic could be corrupted by another client transmitting over it.