Ask Your Question
0

Raspberry Pi capture of 802.11 packets not showing data packets

asked 2023-09-01 23:15:36 +0000

lukedj2 gravatar image

updated 2023-09-01 23:16:22 +0000

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.

edit retag flag offensive close merge delete
add a comment

1 Answer

Sort by » oldest newest most voted
0

answered 2023-09-02 13:02:52 +0000

Bob Jones gravatar image

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

edit flag offensive 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 gravatar imagelukedj2 ( 2023-09-02 19:08:18 +0000 )edit

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 gravatar imageBob Jones ( 2023-09-03 11:25:42 +0000 )edit

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 gravatar imagelukedj2 ( 2023-09-04 18:21:48 +0000 )edit

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 gravatar imageBob Jones ( 2023-09-04 18:44:52 +0000 )edit

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 gravatar imagelukedj2 ( 2023-09-04 20:01:22 +0000 )edit
see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

subscribe to rss feed

Stats

Asked: 2023-09-01 23:15:36 +0000

Seen: 674 times

Last updated: Sep 02 '23

Related questions

In a WiFi capture log, why the 11ac “beamformed” bit is shown as both “true” and “false” in wireshark version 2.4.2 (v2.4.2-0-gb6c63ae086)?

No HTTP protocols in scan results

Tshark conversation view output modification

only seeing acks with tshark

Can't decrypt WPA-PSK (WPA/WPA2) even with passphrase and EAPOL Handshake

Forcing Mac OS X to reconnect in monitor mode

ios 11 802.11 frames

Disable protocol and decoded by my lua script

How to Decode Radius MS-MPPE-Recv-Key

eapol malformed packets