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

Dongle supporting WiFi promiscuous mode


Hello, I need to trace between two WiFi devices, connected to the same A.P. I do't need to trace at radio level, but I just need (want!) to see from Ethernet level, so I guess I simply need a WiFi card/adapter/dongle able to accept "promiscuous" mode.

Yes, I red carefully (I hope) "WLAN (IEEE 802.11) capture setup" paragrph, but I am confused: I don't need to capture radio-level, I don't need to capture all SSID's but I need to see packets not directed to me. Can you confirm promiscuous mode is NOT what I need?

I tried: Intel Link 5100 AGN Linksys Wireless-G Qualcomm Atheros AR928X

With all of them, I don't see all packets and it looks they fail to enter promiscuous mode: once I see the very first ARP-RQ, I don't see anything else between the two devices. I see some other random messages from other devices.

Curiously, with ifconfig wlp3s0, I see the board is NOT in promiscuous mode once Wireshark is started. I close Wireshark, i force the board in promiscuous mode, I restart Wireshark but I still see only broadcast.

Any suggestions for USB WiFi dongles with divers implementing promiscuous mode (Linux)?


asked 24 Mar '17, 03:24

resca's gravatar image

accept rate: 0%

One Answer:


I think you will need monitor AND promiscuous mode on the wifi adapter. Promiscuous mode is great if the actual ethernet frames you are looking for (i.e. from the other devices under review) are available at the network interface - they would be passed up for analysis. However, just like in a wired switch environment, if they are not at the interface promiscuous mode won't help.

Imagine the WiFi adapter will filter out unicast frames not destined for your host, much as an ethernet bridge/switch will do. You might find some exceptions, but all of the adapters I have used have this filter on by default. To remove this filter, you want to put the adapter in monitor mode. I realize you don't want everything, but with a wifi adapter in monitor + promiscuous mode, I think you will get everything and then it becomes a filter exercise to isolate what you want. Luckily, Wireshark does a fantastic job with display filters.

Another option is two APs with a wired link in between. Have a wireless client on one AP, and a wireless client on the second AP. You could sniff the wire connecting the APs with a mirror port/tap/whatever, and get the data between the devices that way. This has the option of not needing to decrypt traffic, assuming you are using WPA2 on your wireless links. The downside is having to configure/manage two APs.

answered 24 Mar '17, 03:36

Bob%20Jones's gravatar image

Bob Jones
accept rate: 21%

Thanks, Bob!

From your words, I learned something I didn't even imagined: the adapter itself works as a "switch" and, of course, in that case Promiscuous is useless. Just for my culture, if you like to answer: once 2 WiFi devices "know" themselves, do the packets between them travel "directly" or are them received and re-sent from the A.P.? In the first case I wonder how two devices too far away (but each one close enough to the A.P.) talk...!

I managed to enable monitor mode, and it works fine and with Wireshark I see [I guess] all the packets on "my" channel. This is very fine. I am quite familiar with MAC level but I don't know anything about 802.11...

I noticed in 802.11 preferences, I can set "Enable decryption". At that point, I imagined I could see decoded MAC, but it seems not the case. Am I correct to think Wireshark is happy to decode MAC once data is decrypted?

My problem is just one WiFi device (ESP386) that fails even ARP with any device connected in WiFi but works fine with devices connected to the Access Point on a wired port (i.e. PC -> LAN -> Access Point -> ESP). Of course, the two cabled A.P.'s trick was my first try and it works fine, but also the devices work, so was useless to investigate on my problem.

(24 Mar '17, 07:49) resca

I think you need both monitor and promiscuous mode. Monitor mode to capture everything, and then the wifi device has to pass up all it sees, and not filter anything. See, for example, the discussion here:

In typical, infrastructure-based, 802.11 wifi, frames do not travel from client to client. They traverse through the AP, and their is a field in the 802.11 header which can indicate the direction:

ToDS means frame from a client to an AP FromDS means frame from an AP to one or more clients

Ad hoc networks would allow communication between devices. In the infrastructure case, for example, if you ping from one wifi client to another, you would see each frame twice: once from client1 to AP, then AP to client2.

Decryption is often possible if setup the right way. If you need decryption, see

There will be special things you need to do so that you can decrypt, but it is possible. If you are investigating arp and specific application behavior, you may need to decrypt. However, to prove you only have one-way communication you might be able to make that call without decryption. For instance, if you know you are sending arp requests, and you see data from to the client on wifi, you can probably guess at least some of them are you arp requests. If you get NOTHING in return, i.e. no data frames from client, then you can be pretty sure the arp is not getting an answer. The difficulty comes in when there are some data frames from the client, and you need to see if any of them are arp responses or not.

(25 Mar '17, 08:19) Bob Jones

Ok, I just reached my goal! Great tool! Basically, I was just missing a note to set "Assume Packets have FCS" in 802.11 preferences and I had simply undecoded raw data. Once done that, I see IP, TCP and all the stuff I need. Fantastic. Thanks again for your suggestions.

(25 Mar '17, 09:07) resca

Anyway, I have a "regular" home network with one Ap.> and several devices: laptop, phones, ESP, etc. (infrastructure? For sure NOT and AdHoc) and with Wireshark I see no duplicate packets, i.e. for a Ping I see one ECHO-REQUEST with source and destination of the two devices (no access point address anywhere) and one ECHO-REPLY between the two devices. At the beginning I was tracing "inside" the A.P. with a software sniffing tool and I could't see any packets between the two units, save for the very first handshake. So, I am still quite confused on WiFi behavior. By the way, the A.P. is internal in a fantastic MikroTik router.

(25 Mar '17, 09:15) resca