Networking/Computing Tips/Tricks

Rate this content:
0 of 5 - 0 votes
Thank you for rating this article.

Check out these great references as well: 

 Our custom profiles repository for Wireshark
 Our Udemy course on Wireshark 
 Our Udemy course on Wireless Packet capture

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:
realworld1
 
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:
realworld2
 
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:
 
realworld3
 
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:
realworld4
 
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:
realworld5
 
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.

 

Comments powered by CComment

Did you learn something?
Did I save you time? 

Buy me a coffeeBuy me a coffee!

Find by Tag

5G Networks 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az ACL Addressing Analysis Ansible Architecture ARP Assessment AToM Backup Bandwidth BGP Biography Bloom's Taxonomy Briefings CBRS CellStream Cellular Central Office Cheat Sheet Chrome Cisco Clock Cloud Computer Consulting CPI Data Center Data Networking Decryption DHCPv4 DHCPv6 Display Filter DNS Documentation ECMP EIGRP Ethernet Ethics Flipping the Certification Model Follow Me Fragmentation Git GNS3 Google GQUIC Hands-On History Home Network HTTPS ICMP ICMPv6 IEEE 802.11p IEEE 802.15.4 In A Day Internet IOS Classic IoT IPv4 IPv6 IS-IS L2 Switch L2VPN L3VPN LDP Learning Services Linux LLN Logging LoL M-BGP MAC MAC OSx Macro Microsoft mininet Monitoring Monitor Mode MPLS Multicast Name Resolution Netflow NetMon netsh Networking Network Science nmap Npcap nslookup Online Learning Online School OpenFlow OSPF OSPFv2 OSPFv3 OSX Parrot PIM Ping Policy POTS POTS to Pipes PPP Profile Profiles Programming Project Management PW3E Python QoS QUIC Requirements RIP Routing RPL RSVP Rural SAS SDN Security Self Certification Service Provider Services Sharepoint Small Business Smartport SONET Speed SSH SSL Subnetting T-Shark TCP TCP/IP Telco Telecom 101 Telecommunications Telephone Telnet Terminal TLS Tools Traceroute Traffic Analysis Traffic Engineering Training Travel Tunnel Utility Video Virtualbox Virtualization Voice VoIP VRF VXLAN Webex Wi-Fi Wi-Fi 6 Wi-Fi 6/6E Windows Wireless Wireless 5G Wireshark Wireshark Tip WLAN ZigBee Zoom

Twitter Feed