Ever since the folks at Aerohive decided to integrate HiveManger NG with CloudShark, we’ve been excited to play around see what exactly we can learn from looking at packet captures from wireless networks. So, naturally, our CloudShark dev and support guru Tom was happy to jump on it when we got some of their Access Points here at CloudShark.
Our network is a bit tricky, since our sister product CDRouter is busy testing all sorts of broadband routers and wireless APs with their networks on, so he brought it out of the noise and tested it at home for a night.
What most people do when network troubleshooting - ping
The first thing Tom tried was connecting to the AP using his laptop and desktop computers, and simple ping.
The first thing I did was setup the AP and connect my laptop and desktop up to it for a simple ping. As you can see in the Delta Time column, the delay between each outgoing ping and response is pretty low. That’s the baseline we’re looking for.
After getting a baseline with this Tom decided to go down to the edge of the yard by the woods. This is about 200 feet (60 meters) out from the AP. There he did another ping.
You can see the delta was bigger here, but just looking at the pings, you don’t see any lost packets. Could that really be true? How can we see the reason for the increase in delay?
Looking at WLAN Retries
Tom decided to dive deeper into the capture, specifically for WLAN Retry frames. Occurring at the MAC layer, retry frames are used by 802.11 systems to protect against packet loss, at the cost of some delay, while frames that were lost due to bad signals are retried. You can imagine this would be helpful for applications that are sensitive to packet loss, like voice or video.
Tom build a graph using CloudShark Graphs, so we can see just how many retries occurred during each interval.
Here’s a graph showing the retransmitted frames when standing right by the AP:
Compare this with the number of WLAN retries after walking to the edge of the woods:
That gray space in each column represents the number of retries. Now, the reason for the delay is clear!