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?
In Infrastructure/ESS mode, it doesn't make much sense to capture packets going to other stations in promiscuous mode, for several reasons :
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 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.
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 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.)
