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

Hi All,

My goal is to capture and analyse the WiFi traffic between my access point and my 'WiFi speaker'. It is a Google Cast system. I have achieved this at 2.4GHz, but am failing at 5.2GHz (apart from one time that it did work and I captured some data, but I cannot repeat it)

I have my mobile phone 'casting' music to my WiFi speaker via my TP-Link Archer C50 access point. The access point is locked to Channel 36 and with all security turned off.

I can see most of the packet transfer around my wireless LAN depending on what filtering I use, but I just cannot find the actual data. And it is the data that I need to analyse!

I have a Linux Mint (kernel 5.4.0-53) Laptop with either built in WiFi (Intel 7260) or external USB WiFi adapter (Alfa AWUS036ACH). Both WiFi adapters behave in the same way.

I am using Wireshark 3.2.3

I have tried two approaches for putting the network adapter into monitor mode (both methods start with airmon-ng check kill):

• airmon-ng start wlan0

or

• ip link set wlan0 down, iw dev wlan0 set type monitor, ip link set wlan0 up, iw dev wlan0 set channel 36 and then fire up Wireshark.

Either way gives the same result - I can see most of the packets, but not the data packets.

I have also uploaded a short capture where there is no data: http://www.red-horizon.co.uk/uploads/...

I would really value somebody who knows telling me why I cannot capture the data. It must be there as the music is playing!

Thankyou.

Chris.

edit retag close merge delete

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)

( 2020-11-13 20:14:22 +0000 )edit

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)

( 2020-11-13 22:04:05 +0000 )edit

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)

( 2020-11-15 11:44:34 +0000 )edit

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)

( 2020-11-20 17:49:16 +0000 )edit

you may need to get a wifi adapter from those best 5.2GHz compatible usb wireless adapter for kali linux

( 2021-06-19 16:19:49 +0000 )edit