Revision history [back]

What you describe all sounds typical for 802.11 packet capture - it can be difficult. A couple of points:

Much of what you describe is analyzed here as well
Passing wireless adapters into VMs can be problematic so I find it best to run native, i.e. wireless adapter running directly on the PC running Linux
To share pcap files, upload them to a publicly accessible location and add a link here. Make sure they are world-readable or no one will be able to access them for review.
Use monitor mode capture to analyze wifi-specific behavior; when possible, move to wired captures to analyze anything from layer3 and above. In summary, use wifi captures when you have to, not because you can.

Your questions:

sometimes it takes a few tries to get the entire seires of 4 EAPOL packets

Not unheard off. Packet loss is an issue that wireless networks have to deal with, so missing EAPOL frames would be a symptom of that. Give yourself the best chance: make sure the signal strength is solid, but not too high (say -30 to -65), there is minimal interference, both RF and wifi on the channel you are on, and that you don't have a lot of multipath going on (don't line your room with metal...)

BUT, wireshark is flagging a lot of tcp errors
tcp out of order, tcp previous segment not captured, tcp acked unseen segment
> it looks like the adapter is missing packets and/or recieving them out of order???

Not surprising; due to loss at the RF layer, Wireshark can struggle to manage TCP connection analysis. 802.11 retries and TCP retransmissions are not the same thing, but Wireshark does not really treat them any different. So the results are confounded - to analyze TCP traffic, grab it at the other side of the AP so some of this noise will be removed.

BUT I can only see broadcast and multicast IP packets
> where are my unicast https web browser data packets??

See the link in point 1 - this is most likely the same problem: capture envelope is not large enough for the test traffic under review.