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.
Mystery solved.
The Windows 7 computer was continuously receiving TCP SYN packets to the 9100 port from another computer in the same LAN, waking up as a result when "Wake on Pattern Match" was activated.
This port is used by network printers. The IP of the Windows 7 computer belonged before to a long-time discarded HP printer.
The computer sending the packets is old, and it is always on as it is used sometimes to run software that only works in Windows XP. This computer still had the old network printer configured, pointing to the local IP address that now belongs to the Windows 7 computer having the problems. There were still documents in the printing queue, so the Windows XP computer was continuously sending TCP SYN packets to the Windows 7 computer, thinking it was the network printer. Removing the old printer from Windows XP and its associated TCP/IP Printer Port solved the problem.
I could not catch this traffic between both computers from mine using Wireshark. I had to install it on the affected computer and run it with promiscuous mode disabled.
Best Answer
For promiscuous mode, which is mainly a wired-network feature (it doesn't work well on Wi-Fi adapters), you won't be "disconnected" in the sense that you will no longer be connected to the network. However, Ethernet doesn't generally work the way it originally did, and promiscuous mode doesn't work as well as it used to. Promiscuous mode is a mode your network adapter works in, in which it hands packets to the host no matter what the destination MAC address, but if the switch won't even send you the packets that aren't broadcast or multicast or addressed to you, there's nothing your adapter can do.
For monitor mode, which is a Wi-Fi feature (it doesn't exist on wired adapters), whether you are "disconnected" in monitor mode, in the sense that you will no longer be connected to the network, depends on your network adapter, OS, and driver. Wi-Fi networks are on a shared medium, unlike switched Ethernet networks, so you'll be able to capture all the packets; however, most Wi-Fi networks are "protected", using WEP or WPA/WPA2, meaning the traffic is encrypted, and you'll need a tool that can decrypt that traffic (such as Wireshark) and the password for the network and, for modern networks using WPA or WPA2, the initial connecting-to-the-network handshake for each device whose traffic you want to decrypt.
Your problem sounds like "can see only broadcast traffic" (such as broadcast DHCP requests), so you're probably on a switched Ethernet, and will have to use one of the techniques mentioned in the Wireshark Wiki's page on Ethernet capturing.
However, you later refer to being associated with the network, which sounds like Wi-Fi. In that case, promiscuous mode won't help; you'll need monitor mode and all the stuff necessary for decrypting traffic.