Chrome OS Wi-Fi Diagnostics

chromebook-logo

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.

ping
route
tracepath

 

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

/device/wlan0
  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

/service/12
  AutoConnect: true
  CheckPortal: auto
  Connectable: true
  ConnectionId: 2069398120
  Country: US
  DNSAutoFallback: false
  Device: /device/wlan0
  EAP.AnonymousIdentity: anonymous
  EAP.CACert: 
  EAP.CACertID: 
  EAP.CACertNSS: 
  EAP.CertID: 
  EAP.ClientCert: 
  EAP.EAP: PEAP
  EAP.Identity: <username>
  EAP.InnerEAP: auth=MSCHAPV2
  EAP.KeyID: 
  EAP.KeyMgmt: WPA-EAP
  EAP.PIN: 
  EAP.PrivateKey: 
  EAP.RemoteCertification/0: /OU=Domain Control Validated/CN=<cn>
  EAP.RemoteCertification/1: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
  EAP.RemoteCertification/2: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, 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.SubjectMatch: 
  EAP.UseProactiveKeyCaching: false
  EAP.UseSystemCAs: true
  Error: Unknown
  ErrorDetails: 
  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
  PortalDetectionFailedPhase: 
  PortalDetectionFailedStatus: 
  PreviousError: 
  PreviousErrorSerialNumber: 0
  Priority: 0
  PriorityWithinTechnology: 0
  Profile: /profile/chronos/shill
  ProxyConfig: 
  SaveCredentials: true
  SavedIP.Address: 192.168.1.20
  SavedIP.Gateway: 192.168.1.1
  SavedIP.Mtu: 0
  SavedIP.NameServers: 192.168.1.1
  SavedIP.PeerAddress: 
  SavedIP.Prefixlen: 26
  SavedIPConfig/0/Address: 192.168.1.20
  SavedIPConfig/1/Gateway: 192.168.1.1
  SavedIPConfig/2/Mtu: 0
  SavedIPConfig/3/NameServers/0: 192.168.1.1
  SavedIPConfig/4/PeerAddress: 
  SavedIPConfig/5/Prefixlen: 26
  Security: 802_1x
  SecurityClass: 802_1x
  State: online
  Strength: 35
  Tethering: NotDetected
  Type: wifi
  UIData: 
  Visible: true
  WiFi.AuthMode: 
  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.PreferredDevice: 
  WiFi.ProtectedManagementFrameRequired: false
  WiFi.RoamThreshold: 0
  WiFi.VendorInformation/0/OUIList: 00-03-7f

/service/15
  AutoConnect: false
  CheckPortal: auto
  Connectable: true
  ConnectionId: 0
  Country: US
  DNSAutoFallback: false
  Device: /device/wlan0
  EAP.AnonymousIdentity: 
  EAP.CACert: 
  EAP.CACertID: 
  EAP.CACertNSS: 
  EAP.CertID: 
  EAP.ClientCert: 
  EAP.EAP: 
  EAP.Identity: 
  EAP.InnerEAP: 
  EAP.KeyID: 
  EAP.KeyMgmt: NONE
  EAP.PIN: 
  EAP.PrivateKey: 
  EAP.SubjectMatch: 
  EAP.UseProactiveKeyCaching: false
  EAP.UseSystemCAs: true
  Error: Unknown
  ErrorDetails: 
  GUID: 
  HTTPProxyPort: 0
  IsActive: false
  LinkMonitorDisable: false
  ManagedCredentials: false
  Mode: managed
  Name: <SSID name>
  PassphraseRequired: false
  PortalDetectionFailedPhase: 
  PortalDetectionFailedStatus: 
  PreviousError: 
  PreviousErrorSerialNumber: 0
  Priority: 0
  PriorityWithinTechnology: 0
  Profile: 
  ProxyConfig: 
  SaveCredentials: true
  Security: none
  SecurityClass: none
  State: idle
  Strength: 44
  Tethering: NotDetected
  Type: wifi
  UIData: 
  Visible: true
  WiFi.AuthMode: 
  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.PreferredDevice: 
  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

[truncated]

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

[truncated]

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
 RX LDPC
 HT20/HT40
 SM Power Save disabled
 RX HT20 SGI
 RX HT40 SGI
 TX STBC
 RX STBC 1-stream
 Max AMSDU length: 7935 bytes
 No DSSS/CCK HT40
 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
 RX LDPC
 short GI (80 MHz)
 TX STBC
 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.

chrome://system/

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
version: 
firmware-version: 
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
firmware-version: 23.14.10.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

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 23.14.10.0 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.

Advertisements

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.

Why K12 Schools Need Wi-Fi Design

Chalk drawing of WIFI

Enterprise Wi-Fi is expensive, very expensive. For schools with limited budgets and a responsibility to be good stewards of tax dollars, it is important to get it right, without spending more than necessary on the initial deployment, ongoing support, or fixing costly mistakes. Any savings can be used in other ways to improve education, so unnecessary spending on Wi-Fi can have an impact on the quality of education in schools.

That’s why it is critical for schools to work with Wi-Fi professionals to develop a sound design for the network before it is purchased and deployed. Fixing mistakes after the fact costs a lot of money. The usual “fix” of installing extra access points in areas where performance is poor can often make the situation worse, when the real solution might be to remove an AP or correct a bad channel plan.

What often happens is this: A vendor talks the school into purchasing one AP per classroom and then the channel planning is left up to auto-channel algorithms (known as RRM, or radio resource management). This is a very simple and seemingly easy way to get Wi-Fi in schools that doesn’t involve the headaches of procuring CAD drawings, performing multiple site surveys, collecting client device data, and other things that delay the installation of the Wi-Fi network and increase the up-front costs.

Don’t do it!

The big problem here is that this is extremely inefficient. Do schools need one AP per classroom? Some do, some don’t. You’ll only find out by doing a proper network design. Maybe the design process reveals that a school only needs one AP per two classrooms. A school like this that doesn’t bother with a design and just does one AP per classroom has spent 100% more money than it needed to.

Capacity issues aside, what about channel planning and radio transmit power control?Nearby AP’s on the same channel interfere with each other. Vendors love to tout their RRM as effective means to automatically set these controls optimally. Just turn it on and let the magic happen.

The truth is, RRM just can’t be trusted. It may work for a while, and then it changes something and it doesn’t. My experience has shown that RRM is fine for simple networks with few neighbors, but in the high density, busy RF environment of K12 schools it often fails miserably. Neighboring AP’s end up on the same channel resulting in interference with one and other. Transmit power goes up and down unpredictably. Your Wi-Fi network is an unpredictable moving target. What you measured and validated at one location one day is different the next day, and so on. The ongoing cost of supporting a network in this state is much higher than one that began with a proper design.

While some vendors’ RRM is better than others, no vendor is immune to this. A better solution is a proper design where channels and transmit power are determined by a Wi-Fi professional who is informed by years of experience and site survey data that RRM algorithms can’t factor into their decision making.

It is critical that schools include a proper Wi-Fi design in their Wi-Fi deployments to save tax dollars that would better be spent on other educational needs, and prevent many future headaches that result from over/under capacity networks and bumbling RRM algorithms. The Wi-Fi design process avoids these issues, and leaves schools with efficient, stable networks and the confidence in knowing that the network was validated against their needs, with the data to prove it.

Beyond the tax dollars, in a 21st century classroom, what is the true cost of poor Wi-Fi?

 

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:

badfi
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:

goodfi
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?

Footnote

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.

Configure FreeRADIUS with Different CA’s for PEAP and EAP-TLS

Many WLAN’s administrators purchase commercial SSL certificates for their RADIUS server to use for PEAP 802.1X authentication. The advantage of this approach is that a cert from a common commercial CA is likely to have its root CA cert already installed on all the clients accessing the network. Although many clients will still prompt the user to trust the server’s cert, they won’t warn them that the certificate is invalid.

While many WLAN’s are configured this way, it’s become increasingly
easy to deploy EAP-TLS, which offers greater security that PEAP. Windows clients, Macs, iOS clients, and now Chromebooks can all automatically request and install a client cert from Windows Server Active Directory Certificate Services (ADCS), making its deployment much simpler than in the past.

Some organizations might desire to enable EAP-TLS for company-owned clients while preserving PEAP for BYOD clients that don’t benefit from the automatic certificate deployment that a managed, company-owned client does. They’d like to keep their commercial cert to use to authenticate PEAP clients, but also deploy a private CA to issue client certs for EAP-TLS authentication.

freeradius_logoWith Windows Server NPS as a radius server, this is simple to setup. The same has not been true for FreeRADIUS, until version 3 was released. With FreeRADIUS 3.0.x one can specify a unique TLS configuration for each tunneled EAP method. This eap.conf snippet shows how that can be done.

# Supported EAP-types
tls-config tls-peap {

private_key_file = ${certdir}/peap/public-cert-key.pem
certificate_file = ${certdir}/peap/public-cert.crt
# ca_file = ${cadir}/
dh_file = ${certdir}/dh
ca_path = ${cadir}
cipher_list = "HIGH"
ecdh_curve = "prime256v1"
cache {
enable = yes
lifetime = 24 # hours
max_entries = 255

}

verify {
}

ocsp {

enable = no
override_cert_url = yes
url = "http://127.0.0.1/ocsp/"

}

}
tls-config tls-common {

private_key_password = password
private_key_file = ${certdir}/eap-tls/private-server-cert-key.pem
certificate_file = ${certdir}/eap-tls/private-server-cert.crt
ca_file = ${cadir}/eap-tls/private-ca.pem
dh_file = ${certdir}/dh
ca_path = ${cadir}
cipher_list = "HIGH"
ecdh_curve = "prime256v1"

cache {

enable = yes
lifetime = 24 # hours
max_entries = 255

}

verify {
}
ocsp {

enable = no
override_cert_url = yes
url = "http://127.0.0.1/ocsp/"

}

}

tls {

tls = tls-common

}
peap {

tls = tls-peap
default_eap_type = mschapv2
copy_request_to_tunnel = no
use_tunneled_reply = no
virtual_server = "inner-tunnel"

}
mschapv2 {

send_error = no

}

With FreeRADIUS 2, it was not possible to configure multiple tls-config’s. Some admins were able to make it work by creating a combined cert with both the private CA cert and commercial CA cert and using that in the EAP-TLS ca_file. That’s a very bad idea as it then allows anyone with a cert from the commercial CA to authenticate to your network!

With FreeRADIUS 3, you can specify unique TLS parameters for each EAP method.

Get Your WLAN Ready for Carrier Wi-Fi Calling

To follow-up my last post where I expressed concern about marking cellular carrier Wi-Fi calls with the proper QoS class, I’m please to see that Cisco will include application signatures for Wi-Fi Calling in it’s upcoming AVC Protocol Pack 15 update. Other vendors should follow suit.

Keep in mind that changing the classification of VoWiFi packets on the WLAN only affects downstream packets from an AP. Upstream is up to the client.

Do Wi-Fi Calling smartphones mark upstream VoWiFi packets for the WMM AC_VO queue? If so, that could pose a problem in high density networks, as a large group of these clients will demand immediate airtime and limit other clients’ access to the medium. Imagine a future where Apple, AT&T, and Verizon all support WiFi Calling and enable it by default to off-load data from their LTE networks. This could happen as early as 2016. High density networks that were designed for best effort data suddenly have to deal with these demanding clients who can dominate the 802.11 contention window. Wireless engineers that haven’t handled voice on the WLAN in the past will now be forced to deal with it.

The first thing to consider is making WMM Admission Control (WMM-AC) mandatory for voice to prevent voice clients from dominating a channel’s contention window. I suggest doing this before all the major cellular carriers enable Wi-Fi calling and these clients show up en masse on your WLAN. To date, the Wi-Fi Alliance has certified 77 smartphones for WMM-AC. The elephant in the enterprise room is the iPhone, which lacks WFA certification for WMM-AC, although it may still support it. I suspect that most newer clients that support WMM probably are WMM-AC capable as well, but that is just a hunch. A client that doesn’t support WMM-AC just won’t gain access to the AC_VO queue, but it can still pass voice traffic without higher priority.

Wireless engineers may also choose to tweak the default WMM AC_VO AIFSN and contention window min/max settings to give these packets less airtime priority. Given today’s PHY rates, that may not cause a significant impact on the performance of these applications when channel utilization is low to moderate.

The goal will be to strike a balance between voice performance without significantly degrading the performance of best-effort data clients. WLAN’s that were designed with voice in mind will have an advantage as they provide higher minimum SNR and therefore higher minimum PHY rates, as well as better roaming characteristics. If your WLAN doesn’t provide fast roaming now, expect it to be a requirement in the future. (Queue the lack of client support for 802.11r rant, with a hat tip to Apple)

What other approaches are out there for dealing with a sudden increase in voice clients?

Update 10/9/2015

Yesterday, AT&T enabled Wi-Fi calling for iPhones on its network. AT&T is by far the largest carrier in the US to enable this feature, so expect to see an increase in Wi-Fi calling on your WLAN soon. Twitter user @wirelessguru posted this packet capture, which shows an iPhone with service from AT&T sending Wi-Fi voice packets with WMM AC_VO QoS markings (and some odd layer 3 markings as well).

The time is upon us to flip the WMM-AC mandatory bit for the voice queue, and consider enabling AVC QoS markings for downstream Wi-Fi calling traffic if available.

Layer 7 Firewalls and QoS on the WLAN

Several WLAN vendors offer layer 7, or application layer, firewalls and quality of service tools. The feature has different names depending on the vendor (Application Visibility and Control, Layer 7 Visibility, AppRF, etc.), but they all try to do the same thing. These tools work at the application layer to identify packets for processing through firewall or QoS rules, which is very useful in today’s world where so many applications are served over the Internet on ports 80 and 443. Traditional stateful firewalls aren’t much use when you want to say, ratelimit Netflix traffic.

At first, you may be tempted to identify all the applications commonly used on your WLAN and assign each of them to a QoS queue. Mission-critical applications get higher priority while social networks and video streaming services are deprioritized. Mark everything!

However, like other features of enterprise gear, while it’s tempting to turn it on and go nuts, you should use restraint, and here’s why: Layer 7 traffic analysis can be very CPU intensive, so the more layer 7 rules in your ACL’s, the more work the AP or controller must do to enforce them. That can result in a performance penalty during high traffic periods. At least one WLAN vendor tacitly acknowledges this by providing an undocumented “Turbo Mode” that will “disable QoS policies and improve Wi-Fi performance.”

Also keep in mind that layer 7 traffic analysis is a bit more of an art than the hard science of stateful packet inspection. Traffic flows are compared to vendor proprietary signatures for proper identification, and that’s not always 100% reliable. An application update or backend infrastructure change may require the development of a new signature for proper identification. WLAN vendors need to provide customers with regular updates to their application signature databases to ensure proper identification is occurring.

With that aside, what are some good uses of layer 7 firewalls and QoS?

Background Data Hogs

RF is a shared medium and as such it is often a bottleneck in busy networks. Software update utilities that run in the background on client machines can be problematic when there are a lot of stations sharing a channel. These applications like to all run at the same time, triggered by events like shifting from a 4G connection to Wi-Fi or right after a machine boots up.

In a school environment, this could happen during first period when everyone pulls out their Chromebook and they all automatically check for updates in the background, while at the same time students’ iPhones notice the Wi-Fi connection and decide now is the time to download that massive iOS update. The WLAN can slow to a crawl without any end-user interaction other than walking in the door.

I think this is where layer 7 QoS shines. By marking Apple Software Update and Chrome OS update packets for the background queue (AC_BK), for example, other applications that users are interacting with in the foreground of their clients take priority on the network. Of course, you will customize these rules to your IT environment. A Microsoft shop will want to do this with traffic to their WSUS server, etc. If you have a lot of iOS clients, iCloud traffic is one to look out for. Dropbox might be a big one too. You may want to consider deprioritizing antivirus updates as well, as these applications sometimes update quite frequently in the background.

Chrome and Chrome OS Updates

Google Chrome LogoIncidentally, despite the overwhelming popularity of Chrome OS in K12, I am unaware of any vendor that provides application signatures for Chrome OS updates. If you can define custom applications within your WLAN (I know that Aerohive and Meraki can do this), use these URL’s to identify Chrome OS updates (these also cover Chrome web browser autoupdates for Windows/Mac/Linux):

https://dl.google.com
http://dl.google.com
https://cache.pack.google.com
http://cache.pack.google.com
https://tools.google.com
http://tools.google.com

Or, if you are really strapped for throughput, use firewall rules to block these applications altogether on the guest network, for example. If WAN throughput is really limited you may need to consider end-to-end QoS all the way to your WAN circuit. Most enterprise WLAN gear can translate WMM QoS markings to 802.1p or DiffServ markings on the ethernet network, but remember to configure QoS on every networking device between the AP and WAN. Do packet captures to confirm your configuration is working.

Recreational Applications

Is it standardized testing season and you are worried that students’ use of Pandora and Netflix is affecting your WLAN performance? No need to go to superiors or committees and ask to have them blocked. That’s a bit draconian anyway. Deprioritize those applications with layer 7 QoS rules.

Malicious and Illegal Applications

Stop bad traffic at the AP or controller before it gets to your content filter. This provides an extra layer of filtering and reduces the traffic the content filter must process. If you don’t enforce station isolation, it can also can block some LAN attacks that would otherwise not reach your content filter. At school, peer-to-peer file sharing applications like Bittorrent, proxy applications, Tor, and shady VPN services are all good candidates layer 7 firewall blocking. Just make sure your firewall rules comply with organizational policy.

Looking Ahead

RF design is the most important factor in meeting the needs of voice-over-Wi-Fi applications, and properly configuring QoS for the enterprise VoIP system has always been important as well. But now we’re seeing users making VoWiFi calls via their cellular carrier. Layer 7 traffic analysis can be used to identify this new traffic and push it to the proper WMM queue (AC_VO).

Going forward these tools might prove less effective as more and more network traffic is encrypted by default. In fact, all HTTP/2 traffic will be encrypted. The companies that develop the application signatures used by WLAN vendors have a challenge to do more with less. Our dependence on these products is increasing while at the same time it will become more difficult to identify application traffic on the network.