4

I have encountered problems trying to catch packets in promiscuous mode from a wireless interface. I have used various adapters on different platforms, but i can only catch packets destined or originating from my machine, nothing from other computers in the connection.

Is this even doable with commercial adapters and drivers?

  • 1
    This does not make much sense, unless you are in ad-hoc/meshpoint mode. In infrastructure/ESS mode, the AP act as a switch (you can't contact another STA associated to the same AP directly), so the behavior should be the same as if it was an Ethernet interface connected to a switch: enabling promiscuous mode will not allow you to receive packets from other stations. – BatchyX Oct 29 '13 at 14:06
  • Use monitor mode – Mike Pennington Oct 29 '13 at 16:33
  • What OS are you using, by the way ? – BatchyX Oct 29 '13 at 17:18
  • Most of the time i have tried on Ubuntu 12.04. Are you sure the AP behaves as a switch. In that case monitor mode shouldn't work either. – manix Oct 29 '13 at 18:02
9

In Infrastructure/ESS mode, it doesn't make much sense to capture packets going to other stations in promiscuous mode, for several reasons :

  • The 802.11 ESS operation assumes that, in a BSS, all non-AP stations must send all their packets to the AP, regardless of the destination address.

This is implemented as follows: if a station wants to communicate with another station, it must send a packet to the AP with the transceiver and source address set to its MAC address, the receiver address set to the AP's MAC address (known as the BSSID) and the destination address set to the intended station's MAC. The AP will then retransmit (or not) the packet to the destination station, changing only the transceiver and receiver address.

This means the AP essentially acts as a wireless switch. All stations only have a channel to the switch, and nothing else. This has many implications on how the protocol (including security) works. This means that a station can only reliably receive frames that are for him. The only exception being broadcast/multicast frames, which, guess what, are unreliable.

  • The 802.11 standard is made to be compatible with 802.3 networks.

The implication is that, on most OS, a 802.11 station is presented as an Ethernet interface, which carries Ethernet frames. You can already guess what you would see when capturing in promiscuous mode on a 802.11 managed interface: you get Ethernet frames that bear little resemblance with the actual 802.11 frames that got transmitted/received.

This means that this "promiscuous" flag is only enabled on an Ethernet-like network interface. On an switched Ethernet network, turning on promiscuous mode will not allow you to receive Ethernet frames that are not for you (it will merely enable you to see multicast frames that you are not interested in), so the 802.11-as-ethernet interface should do just the same thing.

More importantly: Even if promiscuous mode on that interface is meant to enable receiving frames for other stations, these frames can not be presented as Ethernet frames: A 802.11 frame has 3 or 4 addresses, can have their payload encrypted and has many other fields that Ethernet does not have. And 802.11 has support for AP that both allow encryption and clear text, so you cannot even enable that feature when connected to a open access point. And remember that receiving frames for other stations is unreliable, because the AP will retransmit these frames until the other station received it correctly, not until you receive it correctly.


What you actually need is an interface that can fetch true 802.11 frames. Depending on the OS, this is either presented as a different API or as a true 802.11 network interface.

On modern Linux system and cfg80211-based drivers, the 802.11 network card is presented as a "wiphy", which is not a network interface nor allow you to capture frames. This wiphy is in fact a container of virtual network interfaces, known as "vif"s. These vifs are the part that actually assumes wifi modes (managed station, AP, IBSS station, mesh point). There is usually one vif per wiphy, but additional vifs may be created if supported by the driver and card.

One type of vif is the monitor vif. This is a 802.11-with-radiotap network interface that receives as much 802.11 frames as the wifi card can provide to the kernel/driver. Generally, these interface allow to receive frames for other stations associated to the same AP, but also frames that belong to other BSSes (depending on the monitor options).

Most Linux drivers support monitor mode vifs. When the driver doesn't, it generally because the card is a fullMAC wifi interface that does not provide the functionality.

Now what you ask is a way to both act as a station AND receive frames from other stations. For that you need two vifs: a managed station vif and a monitor vif. This multi-vif configuration is supported by all mac80211 based softMAC drivers, but there is still the possibility that it is not supported by some fullMAC devices, even if they support a single monitor vif.

When this combination is supported, the monitor vif will automatically be slaved to whatever channel the managed vif is using, so you don't even have to configure the monitor channel or anything, and even if you try, it will most likely fail.


On a practical note: use iw phy to list your wiphys, iw dev to list the vif associated with the wiphys, use iw phy phyX interface add mon0 type monitor to create a mon0 monitor vif associated with the phyX wiphy. iw dev wlanX interface add mon0 type monitor can also be used if you want to specify a vif of the wiphy instead of the wiphy itself. Once that is done, you may turn that monitor interface up (ip link set mon0 up) and start capturing packets with tcpdump or whatever capture program of your choice that can understand 802.11-with-radiotap while the other is connected to your AP.

Of course, if your AP use encryption, you will capture encrypted frames. But note that on a RSN/WPA2 network with a single PSK, anyone knowing the PSK can decrypt all frames of the BSS if it has captured the 4 way handshake and SAE is not used. The airdecap-ng tool from aircrack-ng implement that functionality.

  • How can you know that much on wireless? How many "wireless years" you have until now? Amazing answer! – laf Oct 31 '13 at 10:22
  • @laf: 2 years ... of development on the wireless subsystem of the Linux kernel. – BatchyX Oct 31 '13 at 19:18
  • I don't completely understand. I have two laptops, one which is connecting to a website and another which is running Wireshark with the card in promiscuous mode. If these computers are next to each other, shouldn't I be able to see the first machine's traffic? The AP may be acting as a wireless switch, but because the packets are transmitted wirelessly, my NIC should be able to pickup those packets. – gsingh2011 Dec 25 '13 at 3:45
  • @gsingh2011: Your other machine can pick up those packet (unreliably) if it is configured correctly. That mean using monitor mode, NOT promiscuous mode. Trying to use promiscuous mode is like saying "I have a FM radio transmitter next to a FM radio receiver that is connected to a packet radio decoder. If I toggle the 'receive all packets' knob, I should be able to hear my voice, right ?" – BatchyX Dec 25 '13 at 8:02
  • @BatchyX: Ok, then what's the point of promiscuous mode at all? It doesn't seem like it gives you any more packets then regular managed mode, even though Wikipedia says it "passes all traffic it receives to the central processing unit (CPU) rather than passing only the frames that the controller is intended to receive". – gsingh2011 Dec 25 '13 at 17:11
1

Two issues. Some cards will not support the mode or the drivers do not. For capturing packets on Linux the Onoco Gold (wavelan from lucent is what I have) would work. And Bulki's remark: after you capture packets you have to decrypt them.

  • I have done tests on open networks and have bought 3 different adapters without success. Are you sure you can see packets from other computers in promiscuous mode (not monitor mode) on your setup? – manix Oct 29 '13 at 13:06
  • it is possible to capture them but idd, you have to decrypt them. In linux there are tools to capture this, thinking of airmon-ng. But again: illegal if you do this if it's not your network. – Bulki Oct 29 '13 at 14:04
  • @manix You need monitor mode, not promiscous mode. You will be able to capture 802.11 frames (which would be encrypted) of other stations. You'd have to reassemble and decrypt the 802.11 frames to get the ethernet frames – nos Oct 30 '13 at 14:42
0

I think the problem is the encryption used for wireless connected devices. This is probably possible, when not using any encryption. (not recommended, and be sure you only test this on your own network, otherwise, in most countries, this is considered illegal.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.