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
6●2●3●5
accept rate: 100%
edited 09 May '16, 11:42
Guy Harris ♦♦
17.4k●3●35●196
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?
I have seen some broadcast packets, but no "Type and subtype" field of "Data" or "QoS Data" packets
Just to be sure, does the above mean that you cannot see any 802.11 frames whose
wlan.dafield would differ fromff: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.
Can you share a trace of what you are seeing? Otherwise we are just guessing at what you might or might not observe.
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.
So what is the value of the "Type and subtype" field in the "LLC" frames?
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:
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.
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.
"Type and subtype" field in the "LLC" frames?
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.
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?
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")
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.
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.
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.