In the packet flow the frame #16 should be the TCP SYN-ACK response from the server, but as you see there was no IP (or TCP) header shown at all, there was just “IEEE 802.11 QoS Data” and 48 bytes of plain unidentified data. But still, the incoming frames did not have any meaningful IP information but a protocol stack like this, as shown in Wireshark packet details pane: And yes, it was confirmed that the WiFi was provided by a small Huawei mobile AP, and the laptop had the Intel MAC address.

When I looked at the frame list again I realized that apparently the 802.11 frames were not just some useless WiFi signaling frames (we weren’t troubleshooting WiFi here) but they were actually the incoming data frames from the WiFi access point to the laptop. I even asked the consultant if the capture file surely included all the two-way communication and he said that there is everything included. I expected to see a nice capture of the laptop’s IP communication, but instead I got only one-way communication of client (192.168.8.100) to server (10.192.10.55), and the rest was some weird 802.11 radio-related stuff (as I saw it), as the laptop was WiFi-connected. Actually quite easy task for this short snippet.) (Note: I needed to anonymize the data for showing here but because of the file format (“Microsoft NetMon 2.x” as Wireshark said) I couldn’t use TraceWrangler, so I exported the packet dissections as text in Wireshark and then replaced the client data in a text editor, from where the screenshots here are as well. I got the resulted capture file and opened it in Wireshark, but I was puzzled about the output:

The consultant doing the capture was not using Wireshark as I would have expected but he was using Microsoft Network Monitor.

I won’t go into application or problem details here but the process eventually involved capturing traffic on a customer laptop to see what was actually happening. Once again I was asked to get involved when a customer had problems with an application.

Django port 8000 wireshark captures