Networking/Computing Tips/Tricks

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:
Inline image 1
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 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:
Inline image 2
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:
Inline image 3
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:
Inline image 5
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:
Inline image 6
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.


Subscribe to our Newsletter!

Our Tag Cloud

4G Networks 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az Addressing Airlines Analysis Ansible Architecture ARP Associations ATM AToM Bandwidth BGP Billing Bloom's Taxonomy Cable CellStream Central Office Cheat Sheet Cisco Click Model Cloud Computer Consulting Crowd Funding Data Center Data Networking Decryption Design DHCPv6 dig DNS Documentation Early Adopter Ethernet Ethics Filter Fragmentation GNS3 Google Hands-On Hiring History Home Network HTTPS ICMP ICMPv6 Image Size Internet IoT IPv4 IPv6 IS-IS L2VPN L3VPN LDP Linux LLN M-BGP MAC Macro Management mergecap Microsoft mininet Monitoring MPLS Multicast Netcat NetMon netsh Networking News nmap NMS nslookup Online School OpenFlow OSPF OSX OTT PDF Personnel Policy POTS POTS to Pipes PPP Preview Privacy Profile Project Management PW3E QoS Remote Desktop Requirements RFI RIP Routing RPL RSVP Rural Scanning SDN Security Sensor Service Provider Small Business SONET Spam Speed SS7 SSL Subnetting SWOT T-Shark TCP TCP/IP Technology Telco Telecommunications Terminal TLS Tools TR-069 Traffic Engineering Training TRANSUM Travel Tunnel Ubuntu Utility Video Virtualization VoIP VRF WAVE Wi-Fi WiFi Windows Wireless Wireless 5G Wireshark WLAN ZigBee

Our Twitter Feed