Not seeing exact packet flow in packet capture with Wireshark

Can you post the capture somewhere to the web (cloudshark, Google drive, MS one drive, ...) and add a link to it to your Question (use edit to do that)?

Hi Sindy,

Actually I had two questions. 1) ACK is not captured for unicast frames. 2) Does wireshark helps me in capturing the packets in exact order under any circumstances?

After your request, I cross checked the packets, packets which didn't receive ACK are re-transmitted. So first query is clarified.

Can you please address the second query. If I am running streaming between AP and 20 stations, will wireshark help in capturing the packets in exact order? I heard from friends, some times wireshark will not capture / show the packets in exact order under heavy traffic / noisy circumstances. If so, kindly suggest which tool can help here.

I would not be as much afraid about frame order as of difference between what the actual devices in conversation have received and what the monitoring WLAN adaptor has received.

This is because, unless all these three items are in the same shielded cage and within 2 m from each other (or in the middle of nowhere with no other WLAN 1 km around), the monitoring WLAN adaptor may receive more interference and less useful signal than the intended recipient of a given frame. This might cause that the capturing device would completely miss or, more likely, receive as corrupt, some frames which the intended recipient has received fine. Or the situation can be reverse, i. e. the capturing device may correctly receive a frame which the intended recipient has dropped it because it couldn't receive it correctly.

Due to the above, the order of packets may seem weird if things go really unfavourably. In an extremely unlikely example, there would be

1. data A->B
2. ACK B->A
3. the same data A->B again because A has not "heard" the ACK
4. ACK B->A again

in the air, and the monitoring device would catch only 2 and 3, so it would seem from the capture that the ACK was sent before the data packet which it ACKs.

If we don't talk about packet order but about exact timing, that may be a different story. On wired interfaces, the timestamp in the frame header is assigned by libpcap/WinPcap as late as when it starts handling the packet, which may be quite long after the packet has physically arrived to the network adaptor. The network adaptor stores the received frames in a memory buffer and raises an irq once it is not empty, and the CPU may not be able to serve the irq immediately so more than one frame may enqueue in the buffer until the CPU starts processing it.

Luckily for you, the wireless driver in monitoring mode normally populates the radiotap header with a value called "MAC Timestamp" (radiotap.mactime) which should be derived from a hardware clock. So when you want to compare time delta between frames, use this value instead of frame.time_epoch you would use for wired interfaces. More details about MAC timestamp have been given in this older Question.