There are various way to use Wireshark to trace anything from local traffic to Wi-Fi packets and even Bluetooth. Recently, I’ve added yet another variant to my bag of tricks: Tracing on a Wi-Fi Access point with forwarding of all captured data to my PC for online debugging. When everything is put together I can start tracing with a single command. Here’s how it works:
The access point is a Raspberry Pi with VPN backhaul that I’ve recently put together. The VPN backhaul isn’t needed for the tracing part at all but the solution presented below lets me trace on the local Wi-Fi interface, on the backhaul interface (Wi-Fi or Ethernet) and the VPN tunnel interface itself. On the local PC netcat (nc) and Wireshark have to be installed. To start remote tracing, the data sink on the local PC and the forwarding of all data it receives to Wireshark has to be started as follows:
sudo nc -l 9999 | wireshark -k -S -i -
This command starts netcat (nc), asks it to wait for an incoming connection on port 9999 and to forward the standard ports to Wireshark. On the access point, tracing is started with the following command via an SSH shell:
sudo tcpdump -n -i wlan0 -s 65535 -w - not port 9999 | nc 192.168.55.9 9999
Wlan0 is the interface to trace (use ifconfig to check which other interfaces are available as well) and ‘not port 9999’ excludes all forwarded traffic to the local PC to be included in the trace. All output of tcpdump is forwarded to netcat which in turn forwards all traffic to the local PC with IP address 192.168.55.9 via port 9999. And that’s it!
And here’s how to combine these two commands into a single command that is issued on the local PC:
ssh pi@192.168.55.1 'sudo tcpdump -n -i tun0 -s 65535 -w - not port 22' | wireshark -k -S -i -
This chain of commands establishes an ssh connection from the local PC to the access point (192.168.55.1) and launches tcpdump on the access point. Instead of netcat, the ssh connection is used to tunnel the data back to the local PC. This is why port 22 must not be recorded by tcpdump instead of port 9999 in the example above. When the data arrives on the local PC it is piped to Wireshark in the same way as shown above. Two things may need to be in place for this to work: As I’m tired of typing in passwords I’m using client certificates for the ssh connection as described here. And the second thing to put in place is that on the Wi-Fi Access Point Pi, sudo doesn’t ask for a password either. On Raspbian that’s the default but on other devices that might not be the case. Should that be a problem, passwords can be disabled in the ‘sudoers’ file for specific commands.