I have a device communicating with a TCP server running on my machine. My machine is normally connected to the network via ethernet, however I also have a wireless adapter that I can use to connect to my router. The device (TCP client) is connected to my router (WPA2-Personal/ AES encryption/ security key).
I can see the device with Wireshark on my ethernet adapter communicating with my server. I cannot find the device when I look at the wireless adapter (I am looking for the device by IP). I went into Edit > Preferences > Protocols > IEEE 802.11 wireless Lan > Decryption Keys > and then set wpa=pwd "password:ssid" and wep-psk "key that I generated here".
I have never used Wireshark to look at traffic that does not originate from my PC, however it's necessary in this particular instance to troubleshoot a problem. Any help would be greatly appreciated.
(While I think of it, first: the root cause of this have no relationship whatsoever with encryption - otherwise you would see traffic, encrypted for sure, but you would still see "stuff" passing.)
You will only see traffic to/from this device if it's multicast or broadcast.
This is because the way communication occur in Wi-Fi/802.11 between AP (Access Point) and STA (Station). At the 802.11 level, every "unicast"[0] communication between let's say a STA A and a STA B actually do not go directly from STA A to STA B: there is first a 802.11 frame from STA A to the AP, and then the AP will send it to STA B etc.
So if your device send some multicast/broadcast traffic, you will see this - but only this (responses back to multicast/broadcast often being unicast).
Some traffic that you may see originating from this station will be for instance ARP requests - that's broascast, and as such it's the job of the AP to send this to all its STAs. You will see these.
Another very common example of such traffic in a Wi-Fi context is if the STA is a DHCP client. You will then see the DHCP request. In a typical scenario this STA will issue such a DHCP request just after association/authentication to the AP. In such case, from your PC running wireshark (which is another STA from the same AP), you will see the DHCP request, since it's broadcast and the AP will distribute it (I intentionally do not use the term "forward"). But usually not much more, because again in a typical scenario the AP is also the DHCP server, hence the rest of the communication regarding this DHCP process will occur directly between the AP and the said STA. You should also see, though, an ARP request - see above - issued by the said DHCP client STA, to check that the IP that it has just been offered by the DHCP server is indeed free, because that's what the DHCP protocol mandate[1] if correctly implemented.
Another not so common but not so rare either traffic that you may see are the one that are inherently broadcast:
This is a fundamental point to understand and never forget when working with Wi-Fi/802.11 in a AP/STA setup: all communication goes through the AP, never directly between STA[2][3].
If you "have never used Wireshark to look at traffic that does not originate from my PC", you may not be familiar with the concept of promiscuous mode, but be warned that it is not the point and will not help here: promiscuous mode can only help in seeing traffic that arrive to your network interface but would normally be discarded by its driver or your OS stack. But here, the traffic actually never goes to your interface in the first place, because the AP will not send this traffic to it at the basic 802.11 level: a fundamental role of an AP is to act like a bridge ("switch") between STAs, and you are in the same situation as you would be with a wired Ethernet switch, and you would need port mirroring on the switch to see such traffic, because the switch is smart enough to not send this traffic to the port you would be connected to.
In the 802.11 context, aside from the "regular mode" and "promiscuous mode", there's a third mode: "monitor". In monitor mode - if everything goes OK, because that's not always obvious - your packet sniffing PC running wireshark will then not be a STA nor participate in any manner to any Wi-Fi traffic, but you may then "see everything" (encrypted if there's encryption, but wireshark can help).
About the tricky world of Wi-Fi packet sniffing, see:
WLAN (IEEE 802.11) capture setup
(though targeted to wireshark, the technical concepts apply also to other pcap based tools, such as libpcap (of course...) but also tcpdump)
[0] I use the term "unicast" here at its root level, that is to say not in the "IP/layer 3" meaning of it (we're at the 802.11 level, which is PHY (layer 1) + Medium Access Control aka MAC (layer 2) - medium being "the air), but more fundamentally as "unicast = communication from a specific entity A to another specific entity B".
[1]: From RFC 2131, Dynamic Host Configuration Protocol, 3.1 Client-server interaction - allocating a network address, page 16, paragraph 5:
The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address), and notes the duration of the lease specified in the DHCPACK message. At this point, the client is configured. If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server and restarts the configuration process.
[2]: The (quite recent) Wi-Fi direct, which is not exclusive to AP/STA - but this would be another topic- changed the landscape in this regard.
[3]:
...and don't worry, this does not put any load to the AP software (ex this does not even go to the userland AP software such as for example hostapd), this is rather carefully managed by the ho-so-technically-sophisticated Wi-Fi hardware chipset.
EDIT:
Sorry, I've been too busy explaining the "why" of you questions, forgetting the "... now how to?":
...however it's necessary in this particular instance to troubleshoot a problem.
So I've been using 2 approach:
1/ Use monitor mode.
Though, there can be many problems:
wireshark "follow dialog" and
then you see some "(XXX missing bytes)),All in all, in my experience, I reserve monitor mode to low-level Wi-Fi chipset and basic 802.11 stack issues investigation = not for higher level applicative protocols troubleshooting. But please, give it a try, if that works for you that'd be fine.
2/ Run the actual sniffing process on the device you're troubleshooting, and forward it to a dissecting station (a PC running wireshark/tcpdump).
This require quite some control on the device (which is fine for me since since "I build them" so to speak). To put this to use I use an SSH connection to launch a tcpdump on the device - quite some prerequisites, so of course if you have no remote shell capabilities nor pcap/tcpdump executable on the device, that's useless to you... :-/ Yet I'd highly recommend it if do-able.
Here it goes:
ssh foo@device "/usr/sbin/tcpdump -U -s0 -w - -i <wireless interface on the device> 'not port 22'" | wireshark -k -i -
...this launches a tcpdump process on the device (of course the "foo" user must have proper privilege to launch tcpdump in its default promiscuous mode, though maybe its --no-promiscuous-mode option may be OK depending on your problem) sniffing on its own <wireless interface on the device>, filter out SSH itself so that the tool does not mix up with the traffic of interest, and send it back to the PC where it's in turn piped to wireshark. And "Voilà", watch the magic!
Hope this helps.