Troubleshooting Notes

These notes are derived from Wireshark for Wireless video series by Jerome Henry and James Garringer distributed by Pearson and accessed on or around 2018-12-10.

Helpful Links:

Retransmissions

Excessive 802.11 retransmissions can be diagnostic in determining why "wifi is slow."

Analyzing total retransmissions (wlan.fc.retry == 1) as a ratio of total frames (frame) is helpful. Retransmissions should be ~ 5% of that traffic. It can be further diagnostic to look into which direction the retransmissions are happening. To the distribution system (from the laptop to the AP) (wlan.fc.retry == 1 && wlan.fc.tods == 1) and from the DS (wlan.fc.retry == 1 && wlan.fc.fromds == 1) will help understand some underlying issues. If beacons are primarily going to the DS, then the device's wifi card may not be transmitting with enough power to make it to the AP even though it can read from the AP. Graphing this in Wireshark's I/O graph is helpful.

Channel Utilization

Channel Utilization should be <= ~ 40% before end users will start to notice lag. Channel utilization is calculated using a formula but I'll hand wave and say that finding wlan.qbss.cu values > 102 (the max, 255 * 0.40) indicates that the channel is becoming congested.

NAV

Network Allocation Vector. When a laptop is Ready To Send a packet, it will send a RTS packet to the AP. The AP will reply with a Clear To Send (CTS). Then data is sent with an ACK. NOTE: I didn't quite grok this fully in the video but the practical application to WiFi troubleshooting is that measuring the NAV duration on the medium is an indicator of wireless network health. Long durations indicate stations are waiting a long time before sending their frames.

"2.8ms [28000 microseconds] is a very long time"

Graphing this is helpful for diagnosis. In an I/O graph: Display filter = wlan.fcs.status == 1 && wlan.fc.type == 1. Y field = wlan.duration.

Bad Frame Check Sequence (FCS)

wlan.fcs.status == 0 can be indicative of the near/far problem: A laptop farther away from the AP will receive these bad checksum messages and then will have to wait for sending/receiving transmissions. A laptop closer to the AP is able to transmit/receive more quickly and less susceptible to corrupted checksumming. Look for the count of bad checksums over time to understand this.

Frame Ratios

Management frames (wlan.fc.type == 0)
Control frames (wlan.fc.type == 1)
Data frames (wlan.fc.type == 2)

Ratios matter. In the I/O graph, creating three line graphs (with each ALSO filtering for good FCS sequences wlan.fcs.status == 1) would reveal mostly data packets. If mgmt packets are dominating then it's a symptom of something unhealthy.

Ubuntu - Prepare wireless cards for WIFI analysis

Wifi cards should be in monitor and promisuous mode to observe wireless traffic coming from and going to APs in the area. I'm using Ubuntu 18.10 on an Intel NUC device.

Monitor mode commands:

sudo ifconfig wlp58s0 down
sudo iwconfig wlp58s0 mode monitor
sudo ifconfig wlp58s0 up

Set channel (in this case, channel 6): iwconfig wlan0 freq 2.437G

source attribution

Check that it worked:

sudo iw dev

type monitor should appear in the output

Ubuntu's network manager will sometimes override the configuration after a few seconds. It's obnoxious for this use case but really handy for just about everything else. Disable the automation by turning off the network manager service:

sudo systemctl stop NetworkManager

Note this will disable all other network devices!

Promiscuous mode commands:

sudo ifconfig wlp58s0 promisc

It may be necessary to turn off power management. I'm not sure how this affects analysis: sudo iwconfig wlp58s0 power off

Captures

To capture on euclid (one of the hosts in my data center): sudo tshark -i wlxe091f59d9f60 -b duration:3600 -b files:36 -q -w /tmp/channel6.pcapng

brycemcd/troubleshooting-wifi-notes.md