Post Views: 221
Sometimes troubleshooting in Wireshark is easy-ish, you find a missbehaving protocol behavior or pattern or even a bad packet, sometimes it is tricky and takes a while to find something, and sometimes it is as clear as mud.
For that reason you always have to approach Wireshark analysis as an evidence gathering process: making note of what you are finding and what you are thinking. I like to capture screen shots as I work and take notes in Evernote (but you could use anything similar).
What we have below is, thanks to one of our students, a capture done at a single Access Point Wi-Fi network. Troubleshooting it was clear as mud. The user was complaining that the network was running slow – “slow Internet”.
A capture was done using Microsoft NetMon using a Windows machine to see the wireless packet data. You can read my article on this here.
Side Note: Using Microsoft NetMon creates .cap files.
Normally Wireshark has no issue processing these.
However, when you use NetMon to put the Wireless adapter into monitor mode,
NetMon uses special wireless headers, not the standard Radiotap headers.
Wish this were not true, but they do.
The result is that while you can open the .cap file in Wireshark,
you cannot Export or Save it at the time this article is written.
This also means that anonymizing the file is not possible.
So the capture can't be shared. Sorry!
Here is how my brain worked as I analyzed the capture:
1. I started where I always start – I clicked on Analyze> Expert Info and got this:
Lots of error and warnings. The Checksum errors can be ignored. Not sure why the tag length is an issue – it is only in the vendor specific area of the LAN management frame. Could be a decoding issue, not sure. It would be interesting to know if these go away if we can get to the bottom of the issue.
2. ICMP Errors – no responses to pings – these all seem to be going to 8.8.8.8 but no answer is heard. First – I love to see these in a capture – it is a way of baselining the connection and provides vital evidence. So the WLAN side looks OK, but indicates possible issue on exit to WAN side.
3. TCP session resets – there are more than usual. This is on port 443 (SSL). An SSL problem?, doubt it at this point.
4. There are a ton of retransmission bits being detected:
Wow – this is heavy collisions or missing ACKs. I filtered for just these packets. The source is the Comtrend (which I note from the beacon frames – this is the AP), and these are all in the 5GHz channel:
That tells me that the AP could not hear the ACKs from the Station in the 5GHz range. A common problem – meaning that the station can hear the AP but not vice versa. All these retransmission will result in slow throughput by impacting any TCP session.
5. The next notes indicate – sure enough – a ton of TCP duplicate ACK’s:
Duplicate ACK’s are when TCP sessions essentially are banging against their retransmission timeouts – meaning they ACK’ed and sent something, and did not hear from the other side, so they resend the ACK, assuming that their previous ACK was lost. To me, this looks like the result of all those Layer 2 retransmissions. I would also throw in the TCP resets into this thought.
6. I note that when we see the wireless data rate – it is running at 6Mb/s:
And that stays consistent, so the news is good there, though it could be better.
With those pieces of evidence, I cannot rule out the wireless side because of all those retransmissions, indicating that the station can hear the AP but the AP is struggling to hear the station. Further there appears to be problems converting from the WLAN to the LAN/WAN side of things. This would indicate an AP problem perhaps, so swapping the AP makes sense.
This was, as I said, clear as mud. However, swapping the AP worked.
I hope you find this interesting and educational.
