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:
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

Find by Tag

4G Networks 5G Networks 6LoWLAN 6LoWPAN 802.11 802.11ah 802.11ax 802.11ay 802.11az Ad-Hoc Addressing Analysis Ansible Architecture ARP Assessment AToM Automation Baseline BGP Bloom's Taxonomy Cable cat CellStream Cellular Central Office Cheat Sheet Chrome Cisco Cloud CMD Company Policy Computer Consulting Data Center Data Networking Dependencies DHCPv6 DNS Docker Documentation Dublin-Traceroute dumpcap Earth Earthquakes ECMP Ethernet Ethics Etiquette Evaluation Field Operations Fragmentation G-MPLS Gauge GeoIP GNS3 Google GQUIC Hands-On History Home Network ICMP ICMPv6 IEEE 802.11p IEEE 802.15.4 India Internet IoT IPv4 IPv6 IRINN IS-IS L2VPN L3VPN LDP LifeNet Linux LLN LoL M-BGP MAC Macro Microsoft Milky Way mininet Monitoring MPLS mtr MTU Multicast Murphy Name Resolution Netcat NetMon netsh Networking nmap NSE Observations OLPC Online School OpenFlow OSPF OSPFv2 OSPFv3 OSX OTT Paris-Traceroute Parrot PIM PMTU Policy POTS POTS to Pipes PPP Profile Project Management PW3E QoS QUIC Railroad Remote Desktop Requirements Resume Review RIP Routing RPL RSVP Rural SDN Security Service Provider Small Business SONET Speed SSL Status Storms Subnetting SYSCTL T-Shark TCP TCP/IP Telco Telecom 101 Telecommunications Telephone Testing Tools Traceroute Traffic Engineering Training Travel Tunnel Ubuntu Utility Video Virtualbox Virtualization VoIP VRF VXLAN Wi-Fi Wi-Fi 4 Wi-Fi 5 Wi-Fi 6 Windows Wireless Wireless 5G Wireshark WLAN Writing Zenmap ZigBee

Twitter Feed