Cannot capture 'TCP Data' packet in monitor mode on 5.2GHz

edit

There are 2209 packets that contain TCP in the 'short' capture; try the following filter:

tcp

I don't know if this is the specific traffic you are looking for but you have at least one-way communication of TCP (this is all ToDS as well, so you are missing the FromDS of this stream as well as the reverse TCP traffic). Is this capture taken with the Alfa radio?

The other traffic is indicated by naked Block ACKs - just ACKs so we know there was data, but the capture system did not pick it up. Most likely due to modulation issues - a common culprit is SGI but I see both in the capture. After that, look at LDPC setting as a possible reason that you cannot pick up everything, along with the usual spatial streams, MCS index, etc. It is likely not due to signal strength issues since they appear ...(more)

Hi Bob, Yes, I have been using the TCP filter. Also wlan.ra and wlan.ta in case the issue was with TCP dissection and the underlying 802.11 frames were OK. But it seems (and I think you agree) that the frames are completely missing! (but as you say, the rest of the information is present)

This was acquired with the Intel radio, although I have identical capture logs from the Alfa radio.

It is not signal strength as there is only about 1 meter clear line of sight between all the items in this test.

Please can you point me at LDPC, MCS etc?, I am not familiar with those.

I purchased the Alfa unit as I originally ran into this issue with the Intel chipset and wondered if it was a driver / chipset limitation. Hence I was rather surprised to find exactly the same issue with a ...(more)

Best thing to do is to grab the probe and association requests/responses for the devices under review (i.e. the devices that are actually communicating) as they will announce their capabilities. This, coupled with the capture capability info (from something like iw phy phy0 info), will start to guide you into what could be wrong. The capture envelope has to be at least as big as the DuT to be able to capture and decode it.

Options include: use another WiFi adapter to try and capture, like a Macbook, or some other PCIe/USB chips maybe: RTL8812AU --> what you have, supports 2SS and no LDPC RTL8814AU --> supports 3SS and LDPC MT7612U --> (example: https://www.alfa.com.tw/products_deta...) supports 2SS and LDPC

Or try to 'dumb down' the AP - set to, for example, 802.11a or 802.11bg ONLY and none of the advanced modulations will ...(more)

Hi, By way of update, I switched my AP to be 'a/n' rather than 'ac', and it does indeed work much better. I looked at the 'probe/response' when the initial connection is made, and realised it is rather complex!! I also realised that Google Cast works by sending a huge chunk of data right at the start of the playback, and then smaller regular updates. But the total amount of data seems to be larger than the source file by a factor of 2. The other interesting observation is that the media is cached in the playback device, so if I play the same track on repeat, I just don't get as much data second time around. These details vexed me for a while as I mistakenly assumed that the data would be streamed 'as required'. Next week I will look at the 'ac' issue some more ...(more)