When I send packets to another computer (both computers have wi-fi) is the AP required to communicate or can the other machine receive the information directly from my computer without the AP?
Wireless – Does a wireless access point has a role between two wireless devices
wireless
Related Solutions
Since you've clarified (comments above) that IP net/mask/gw are the same for wired/wireless clients, then your AP is bridging (as opposed to routing or NAT'ing the wireless clients.)
Verify the wireless systems are getting DNS servers via DHCP. If "cannot access Internet" means "web sites do not load", this may be all that is wrong.
Verify your Internet edge router, (and/or firewall,) isn't blocking the traffic. You might have everything configured correctly from the network and IP point of view, and then not realize that the edge router has special rules to only permit certain of your internal LAN IP addresses out. (For example, your DHCP server could be configured to give specific IPs to certain DHCP clients (the boss's desktop), while servicing the rest of the clients (eg, printers) from a pool of numbers which aren't generally permitted out to the Internet.
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.
Best Answer
Since you mention two computers and an AP, I assume you are not talking about ad-hoc or direct connect, rather are referring to infrastructure mode operations.
In this case, all communication is between each station and the AP. This is because the station associates to the AP, establishing a relationship between the two devices, but there is no relationship between the stations.
This has a number of implications, but I will limit myself to two of the larger considerations in wireless.
First, just because a station can transmit to/from the AP, does not mean that any two stations associated to the same AP will be able to transmit to/from each other. To simplify, if you picture the AP's coverage zone as a clock (analog with hands) with the AP in the middle, a station at "12 o'clock" that is talking to the AP may not be able to hear a station at "6 o'clock" on the circle.
Second, the encryption key for security (whether based on personal/PSK or enterprise) is negotiated between the station and the AP. Even if a station can hear a second station, it won't be able to understand any of the encrypted data in the frame. (Note: in some cases you can intentionally decrypt this data, even if not the station and AP involved, however this is not normal operation.)