This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Unable to capture unicast packets in monitor mode on wireshark

0
1

I have two RPi-3's and a desktop linux system. I have the two RPi-3's creating ping and iperf3 traffic between each other over wifi. I have the desktop linux system running wireshark in monitor mode, and have not been able to capture any data packets. Things I have done/tried include:

  • I am currently running wireshark with ubuntu 14.04 lts using an ASUS PCE-N10 (pci-e) network card
  • I am running wireshark Version 1.10.6 (v1.10.6 from master-1.10)
  • I have tried 6 different wifi cards (5 usb, 1 pci-e)
  • I am capturing 802.11n (no 5G ac)
  • I have set wireshark 802.11 encryption keys, and enabled encryption
  • I have enabled monitor mode multiple ways (wireshark capture options, airmon-ng, iwconfig, ...)
  • I have tried various settings for 802.11 protocol "Ignore Protection bit" and "Assume packets have FCS"
  • I have set the channel to match the wifi router (iwconfig or airmon-ng)
  • I see lot of broadcast packets
  • List item

eth0 Link encap:Ethernet HWaddr f0:4d:a2:f6:15:82 inet addr:10.10.3.16 Bcast:10.10.3.255 Mask:255.255.255.0 inet6 addr: fe80::f24d:a2ff:fef6:1582/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1583160 errors:0 dropped:80 overruns:0 frame:0 TX packets:3340647 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:213443629 (213.4 MB) TX bytes:4339356507 (4.3 GB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:810841 errors:0 dropped:0 overruns:0 frame:0 TX packets:810841 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4257012230 (4.2 GB) TX bytes:4257012230 (4.2 GB)

mon0 Link encap:UNSPEC HWaddr F0-79-59-EB-24-78-3A-30-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:32865 errors:0 dropped:22794 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7563887 (7.5 MB) TX bytes:0 (0.0 B)

wlan5 Link encap:UNSPEC HWaddr F0-79-59-EB-24-78-00-00-00-00-00-00-00-00-00-00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:329980 errors:0 dropped:164334 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:76222872 (76.2 MB) TX bytes:0 (0.0 B

Does anyone have any suggestion on what I could be doing wrong

asked 06 May '16, 14:23

mw-ed's gravatar image

mw-ed
6235
accept rate: 100%

edited 09 May '16, 11:42

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196

1

have not been able to capture any data packets

I.e., you are not seeing any 802.11 packets with a "Type and subtype" field of "Data" or "QoS Data" or some other "Data" type?

If you are seeing them, please indicate what you mean by "have not been able to capture any data packets" - do you mean that nothing gets dissected past the 802.11 layer?

(06 May '16, 15:06) Guy Harris ♦♦

I have seen some broadcast packets, but no "Type and subtype" field of "Data" or "QoS Data" packets

(06 May '16, 15:36) mw-ed
1

Just to be sure, does the above mean that you cannot see any 802.11 frames whose wlan.da field would differ from ff:ff:ff:ff:ff:ff (applying a display filter !(wlan.da == ff:ff:ff:ff:ff:ff) will show you whether any such frame remains in the packet list pane) or that such frames are there but you cannot decrypt their contents?

If there are really no frames but those with broadcast destination address, and if you are sure that the RPi-3s don't use 802.11ac mode, it may be a linux regression, as @Bob Jones pointed out in his comment from 30 Apr, 05:48 to this answer.

In general, it doesn't matter how many different WLAN adaptors you have but how many different chipsets they are built on, as any number of adaptors based on the same chipset will behave the same - at least in linux where adaptor manufacturer's specific modifications of generic drivers for a chipset are really rare.

(06 May '16, 23:03) sindy

Can you share a trace of what you are seeing? Otherwise we are just guessing at what you might or might not observe.

(07 May '16, 10:36) Bob Jones

I am currently using ASUS PCE-N10 (pci-e) which is a rtl8192ce chipset (as are most). Other adapters also include and rtl8192cu and Atheros ath9k chipsets. I have also tried running it on a RPi3, but the RPi3 does not seem to support monitor mode.

(09 May '16, 05:20) mw-ed

alt text

(09 May '16, 05:53) mw-ed

So what is the value of the "Type and subtype" field in the "LLC" frames?

(09 May '16, 11:23) Guy Harris ♦♦

Unfortunately, screen shots do not provide enough details to provide analysis. It is best to post a PCAP file with the capture in question to Cloudshark, Google drive, etc. and share it so others can download the file.

With that said, did you try the other suggestions made above:

  1. Configure the WLAN (if possible) to 802.11a/b/g so that the higher coding schemes are not used. I suspect the WiFi chipsets do not support the higher modulation schemes offered in an 802.11ac networks.

  2. Apply the following filter to ensure no Data and/or QoS-Data packets are being captured: wlan.fc.type eq 2 and !(wlan.fc.subtype eq 4 or wlan.fc.subtype eq 12) If you apply the filter and see nothing, then you know that no Data and/or QoS-Data frames are not captured.

(09 May '16, 11:27) Amato_C

"Type and subtype" field in the "LLC" frames?

Type/Subtype: Data (0x20)
(09 May '16, 11:29) mw-ed

OK, so you are seeing 802.11 packets with a "Type and subtype" field of "Data" or "QoS Data" or some other "Data" type.

I.e., you are capturing data packets; that's what those LLC packets are.

What you don't appear to be capturing are unicast packets.

(09 May '16, 11:41) Guy Harris ♦♦
1

So you are seeing data frames now? What happens when you apply this filter in Wireshark:

wlan.fc.type eq 2 and !(wlan.fc.subtype eq 4 or wlan.fc.subtype eq 12)

Do you see any frames?

(09 May '16, 11:42) Amato_C

Amato_C,

I set the router to support B/G only (no n and it does not support ac). I ran wireshark capture, with the display filter wlan.fc.type eq 2 and !(wlan.fc.subtype eq 4 or wlan.fc.subtype eq 12)

The result was a bunch of LLC packets and a few SNA,STP, CLNP. I also received a a few IPv4 packet with warnings ("Bogus IP Header" and "Malformed Packet")

(09 May '16, 11:53) mw-ed

Guy Harris,

Yes you are correct, and I guess the unicast packets are what I am looking for, and thanks for changing the topic line.

(09 May '16, 11:56) mw-ed
1

Looks like monitor mode is supported on the adapter but not promiscuous mode. I don't have that chipset, but several others that behave this way. Broadcast/multicast is usually sent at lower rates/modulation coding schemes so they tend to be easier to get. However, ACKs, RTS, and CTS tend to be sent at lower rates too and we don't see any of those, and they are typically unicast. I rule out modulation then (though you might still have issues collecting at higher rates) and assign root cause to no promiscuous mode support while in monitor mode.

Suggest to change hardware and/or kernel.

(09 May '16, 18:24) Bob Jones

Bob Jones,

Thanks, I went back and tried the TP-LINK TL-WN722N (Atheros ath9k chipset) and I seem to be up and running now.

Thank you for everyone's help.

(10 May '16, 06:40) mw-ed
showing 5 of 15 show 10 more comments

One Answer:

0

The key points for me to capture unicast packets from other systems seem to be:

  • the rtl8192 chipset does not seem to capture unicast packets on ubuntu 14.04 LTS
  • both monitor and pomiscuous mode must be set
  • the wlan card must be set to monitor the appropriate frequency (i.e. iwconfig wlan0 channel 11)

Further, to decode the packets:

  • Edit->Preferences->Protocols->IEEE 802.11->
  • "Enable Decryption" must be set
  • "Decryption Keys" must be set
  • Not sure if Ignore Protection bit needs to be set (I have it set)
  • the EAPOL packets must have been captured for the device connection some time in the wireshark session

answered 10 May '16, 06:49

mw-ed's gravatar image

mw-ed
6235
accept rate: 100%