First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

Raspberry Pi capture of 802.11 packets not showing data packets

I am trying to capture 802.11 data packets with the RTL8812AU driver (TPLink Archer T2U Nano adapter) on a Raspberry Pi but I am only able to collect management packets (RTS-CTS, Probe Request, ACKs). I have confirmed that my interface is in monitor mode and on the right channel. There has been previous posts about this question but I believe no one has found the answer to why this happens. Any help would be appreciated.

lukedj2's avatar
1
lukedj2
asked 2023-09-01 23:15:36 +0000, updated 2023-09-01 23:16:22 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

0

Limited information is provided, but the most likely cause is explained many times here; for example:

  1. https://ask.wireshark.org/question/20...
  2. https://ask.wireshark.org/question/10...
  3. https://ask.wireshark.org/question/28...

All of these are related to same root cause: capture envelope not large enough to capture traffic under review. Data frames are highly modulated, while control/management are not and therefore are easier to pick up.

The RTL8812 devices are not great, but can collect traffic. Is it configured correctly - especially in context to channel width (20/40/80)? Could be your traffic under review is 11ax, and you are trying to capture with a 2x2 11ac adapter? Perhaps capture is too far away to collect highly modulated frames? There is a sharkfest presentation from a couple of years ago on the topic: https://www.youtube.com/watch?v=p3Ik_pcwp9c

Bob Jones's avatar
1.5k
Bob Jones
answered 2023-09-02 13:02:52 +0000
edit flag offensive 0 remove flag delete link
more

Comments

Thanks for the detailed and prompt reply, Bob. I am using a WRT160NL router on 802.11n mode. I have all my devices in my room- the router, a Raspberry Pi for sniffing, and a laptop which is on the router's network. I am having my laptop ping the router and I want to be able to sniff the 802.11 headers of the ICMP requests sent from the laptop on the Pi. When I put the Pi's T2U nano adapter into managed mode and connect to the router's network, I am able to pick up ICMP packets, but when I use the same adapter in monitor mode, I can only hear 802.11 management traffic, no data packets. I am using a Raspberry Pi 4. I get the same result when I try to use the WiFi adapter with my desktop that is also nearby the ... (more)

lukedj2's avatar lukedj2 (2023-09-02 19:08:18 +0000) edit
more
  • delete

What I would do - in no particular order:

  1. Try another adapter - select preferred from here: https://github.com/morrownr/USB-WiFi
  2. Try another capture platform, like a Macbook
  3. RTL8812au driver is not part of Linux kernel, so it needs to be built. They are many driver variants on gihub - different versions and different sources. Try a different one (or two).
  4. Make sure this is not an issue with decryption - wlan.fc.type_subtype in {0x20, 0x28} will show 802.11 data/qos-data frames
  5. Reduce AP to 802.11a/g only - no 802.11n/ac/ax.
  6. Provide a capture here so we can take a look - provide the filters you are using and mac addresses you are looking for. With real information, this might be easier to find root cause of the issue.
Bob Jones's avatar Bob Jones (2023-09-03 11:25:42 +0000) edit
more
  • delete

Hi Bob, I am forced to use the T2U Nano adapter. I tried using a Macbook and it is much more consistent at capturing the UDP traffic, unfortunately, I am teaching a class on packet sniffing and students are supposed to use T2U Nano devices on Pi's. I am using Aircrack-ng's RTL8812 driver: https://github.com/aircrack-ng/rtl8812au. I am filtering by 0x20 and 0x28 and only one or two data packets show up for a 3 minute capture of busy network traffic. All the devices on the network and the Pi sniffer are in the same room.

Here is a capture of some traffic: https://drive.google.com/file/d/1atSG.... I am having 7c:21:4a:9f:fe:25 send UDP packets with data "This is a test" to IP 192.168.1.179 every 2 seconds. The only time when I am able to capture ... (more)

lukedj2's avatar lukedj2 (2023-09-04 18:21:48 +0000) edit
more
  • delete

Have a look at your channels in this capture - something is making your adapter move across all channels, 2.4 and 5GHz. I would not recommend scanning channels when trying to pick up actual data frames for analysis. Is NetworkManager disabled, or any other software package that takes control of the adapter?

Bob Jones's avatar Bob Jones (2023-09-04 18:44:52 +0000) edit
more
  • delete

You are totally right. In that packet capture my channel is varying quite a bit, thanks for pointing that out. Unfortunately, now, when I use airmon-ng to kill all the channel-changing processes and I can confirm in Wireshark that the channel frequency is not moving from the frequency of the network I am sniffing, I do not get any data packets at all. Here is the link to my new capture: https://drive.google.com/file/d/1tuAr...

lukedj2's avatar lukedj2 (2023-09-04 20:01:22 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer