Yun as WiFi monitor?

I'd like to use a Yun as a WiFi monitor, but I can't quite get it working.

The idea is to associate to an access point as a client, and then capture the communications between the access point and another client. This is a private network consisting of just the access point, the Yun, and the target client. I'm trying to debug a connectivity issue between the access point and the client, both of which are embedded systems with very limited debug facilities. (This is part of a development project of mine: neither of those nodes are Arduino nor Yun based.)

This thread showed promise: Arduino Yun Forum: how to listen the packets coming out from the yun but it covers capturing the data to/from the host Yun. That works well, but I want to capture the other traffic on the network, and there I'm having trouble. I can capture broadcasts from the other nodes, presumably because the Yun is receiving them in case it needs to do something with the broadcast. But it doesn't receive any of the traffic specifically addressed between the other two nodes. When I start tcpdump, the messages indicate that the net interface is entering promiscuous mode, which I thought would enable me to see all traffic on the network, including that which is not specifically addressed to the Yun that is collecting the data. But that doesn't appear to be the case.

My basic steps:

opkg update
opkg install tcpdump

tcpdump -i wlan0 -s 65535 -w /mnt/sda1/data.cap

I then move the uSD card to my laptop and examine the data using wireshark.

The tmanpage for cpdump shows a potentially interesting option (-I or --monitor-mode) but if I add that option, it responds with "tcpdump: wlan0: That device doesn't support monitor mode"

I tried doing this with WireShark on my regular computer, and got similar results, presumably because from what I'm told Windows does not allow the WiFi adapter to enter promiscuous mode. I'm told that Mac and Linux don't have this restriction, but I don't have access to either of those systems types. The closest I have is my Yun, and while I think I'm getting close with it, I'm not there yet.

What am I doing wrong? Am I missing something obvious? Is this even possible with a Yun?

Any pointers would be greatly appreciated!

Install software:

opkg update
opkg install aircrack-ng

Test current wifi mode:

iw wlan0 info
Interface wlan0
        ifindex 5
        wdev 0x2
        addr 90:a2:da:f0:06:76
        type managed
        wiphy 0
        channel 8 (2447 MHz), width: 20 MHz, center1: 2447 MHz

Start monitor mode:

airmon-ng start wlan0  1

wlan0           Atheros         ath9k - [phy0]
                                (monitor mode enabled on mon0)

Confirm it under monitor mode:

iwconfig

mon0      IEEE 802.11bgn  Mode:Monitor  Tx-Power=17 dBm
          RTS thr:off   Fragment thr:off
          Power Management:off
iw mon0 info

Interface mon0
        ifindex 6
        wdev 0x3
        addr 90:a2:da:f0:06:76
        type monitor
        wiphy 0

Get BSSID and Channel:

airodump-ng mon0 


BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

40:70:09:E4:87:90    0       12        0    0   6  54e. WPA2 CCMP   PSK  TG167
F4:6D:04:5D:1B:BC    0       37        0    0   8  54e. WPA2 TKIP   PSK  dd-wr
D8:50:E6:D7:EA:1E    0       43      161   29   8  54e  WPA2 CCMP   PSK  ASUS

Start Capture:

airodump-ng -c 8 --bssid D8:50:E6:D7:EA:1E -w capture mon0

Stop monitor mode:

airmon-ng stop mon0

Thank you, sir!

A couple glitches along the way, but I think this is just what I was looking for! I've sent the capture off to my tech support guy to see if this is what he's looking for, but it looks very promising to me.

Strangely, when I issue either the "airodump-ng mon0" or the "airodump-ng -c 8 --bssid D8:50:E6:D7:EA:1E -w capture mon0" commands, all I get is a blank screen. (Actually, a continuous stream of escape sequences to clear the screen and move the cursor to 1,1.) But I get no information printed out. I will have to look into why that is...

But fortunately, my code for the AP does show me the BSSID and channel number, so I didn't need airodump-ng to give that to me. Also, while the actual capture process shows nothing on the screen, it does appear to be capturing and saving useful data.

One pointer I discovered, which is obvious in retrospect: even though you are giving the BSSID and channel number in the dump command, wlan0 must still be associated to that same AP, even though it's a different interface. My test network has no Internet connectivity, so I had the Yun associated to a different network that does, so I could do the installation with opkg. After doing that, I never associated it to the test network, and therefore while the dump operation did collect some data, it was not the data I wanted. Once I associated the Yun to the test network, I was able to collect lots of good data.

Thanks for your help sonnyyu, you are truly an asset to the community!

My elation might have been a bit premature…

The project I’m working on uses a third party WiFi module in two modes: as an access point, and as a client to an access point. My software controls what mode it uses.

For my initial test, it was set up as an access point. I associated the Yun to that access point, and used the suggested commands, changing them to use the channel number and BSSID of the module that was acting as an access point. While monitoring the link with the Yun, I associated to the module with my iPhone, loaded several web pages, and made a few additional GET and POST requests to the module. The collected data looked great - it contained the wireless packets covering association and link management, as well as the HTTP calls for all of the web page access and GET and POST requests. Just what I was looking for.

I then put the module into client mode, and associated it with a MiFi hotspot. I then associated the Yun with the MiFi, and started collecting data using the MiFi’s channel and BSSID. I then had my software make some outgoing HTTP requests to perform cloud server updates. This time, it looks like I get the same kind of wireless association/management packets, but I’m not seeing any of the HTTP data in the capture file. Unfortunately, this is only half of the data I need, I have to also see the HTTP data to be able to fully debug the issues I’m having.

I then repeated the scenario, but associating my module and the Yun to my iPhone acting as a personal hotspot (and using the BSSID and channel number of the iPhone.) Same results - I’m capturing the WiFi management packets, but not the HTTP traffic I also need.

Why am I getting all of the data when the module under test is acting as an access point, but only half of the data when the module is a client connecting to another access point? In both cases, the Yun is associated to the corresponding access point and monitoring that access point’s BSSID and channel.

Because I’m trying so many different BSSID and channel combinations, I tried automating the process using a script: (as an aside, I’m an ash shell neophyte, any scripting tips or comments are welcome)

#!/bin/ash

# mon0 may have already been started from a previous run. 
# Make sure to stop it first, otherwise starting the monitor
# will create new devices mon1, mon2, etc.
airmon-ng stop mon0

# Get the channel number of the currently associated access point
CHAN=$(iw wlan0 info | grep channel | awk '{print $2}')
if [ -z $CHAN ]
then
echo Unable to determine channel number.
return 0
fi

# get the BSSID of the currently associated access point
BSSID=$(iwconfig wlan0 | grep "Access Point:" | awk '{print $6}')
if [ -z $BSSID ]
then
echo Unable to determine BSSID.
return 0
fi

# Build a filename based on the date and time.
# ex: /mnt/sda1/capture/YYYY-MM-DD_HH-MM-SS
FILE=$(date +"/mnt/sda1/capture/%Y-%m-%d_%H-%M-%S")

# Show what we're about to do
echo Capture from channel $CHAN on $BSSID to file $FILE

# Start a monitor device using the previously determined channel
airmon-ng start wlan0 $CHAN

# Start capturing wireless packets on the determined channel and BSSID
# saving data to the desired filename
airodump-ng -c $CHAN --bssid $BSSID -w $FILE mon0
# Need to terminate airdump-ng using Ctrl-C

I get the same results using the script or by manually typing in the commands. The script just simplifies getting the channel number and BSSID of the access point to which the Yun is associated, and generates a unique filename.

To summarize: Why am I getting such different capture results? In both cases, the Yun acting as the packet collection node is associated to the access point being used:- When the third-party module under test is acting as the access point, airodump-ng is able to capture all of the IEEE 802.11 packets, as well as additional protocol packets: DNS, UDP, ARP, MDNS, TCP, HTTP, etc.

  • When the third-party module is acting as a client to another access point, airodump-ng only capture IEEE 802-11 packets, and none of the other protocols

I’ve been banging my head for a couple days over this. Anybody have any ideas to point me in the right direction to figure this out?

Note: I’m not asking for help with that module or the software driving it, only help with using the Yun to capture the data to/from that module while it runs in different modes.

ShapeShifter: To summarize: Why am I getting such different capture results? In both cases, the Yun acting as the packet collection node is associated to the access point being used:

  • When the third-party module under test is acting as the access point, airodump-ng is able to capture all of the IEEE 802.11 packets, as well as additional protocol packets: DNS, UDP, ARP, MDNS, TCP, HTTP, etc.
  • When the third-party module is acting as a client to another access point, airodump-ng only capture IEEE 802-11 packets, and none of the other protocols

Well, I think I'm making some progress, and in retrospect the issue appears to be rather obvious. I wasn't considering a key piece of information: when acting as the access point, it is an open network with no encryption. But when acting as a client, both of the two access points I was connecting to had passwords -- the data is encrypted, so the the Yun didn't capture the other protocols because it couldn't decrypt the packets. Or at least I guess that makes sense?

Even when the Yun is associated to the same encrypted access point while it is monitoring traffic, it still doesn't get the packets for the other protocols. Does this make sense given the way the WiFi security operates? It probably does.

This is turning into a frustrating experience. I was hoping that I could use the Yun as a tool to help debug the communications issues of my project, but I keep hitting brick walls.

Maybe I'm looking at it from the wrong point of view. My problem is that I'm using an intelligent WiFi module, and it is having several connection issues that the vendor of the module is not able to duplicate. He wants me to collect WiFi packet data that includes both the 802.11 management packets, plus the HTTP communications packets, so that he can analyze it in WireShark to try and figure out why it is failing. I'm unable to collect the data that he really needs. Perhaps neither tcpdump nor airodump-ng can do this? I know Windows certainly can't. Can anything do it?

Any suggestions are greatly appreciated...

ShapeShifter: Even when the Yun is associated to the same encrypted access point while it is monitoring traffic, it still doesn't get the packets for the other protocols. Does this make sense given the way the WiFi security operates? It probably does.

The more I think of it, the more this seems to make sense:

  • wlan0 is associated to the access point, and could probably see the encrypted data, but that's not the device doing the monitoring
  • mon0 is doing the monitoring, but that device isn't associated to the access point, so it can't see the encrypted data

Hmmm... a conundrum...

Sorry to keep on talking to myself, but maybe someone in the future will be able to benefit from this.

I think it's working. Even though the data is encrypted, and mon0 is not associated to the access point, it looks like airodump-ng is indeed capturing and saving the data. I was so hung up on figuring out how to get airodump-ng to decrypt the data, that I overlooked the obvious: when opening the capture file using WireShark, one is able to enter the WPA credentials into WireShark and it will decrypt the collected data: http://wiki.wireshark.org/HowToDecrypt802.11

I don't know exactly what packets my module's tech support guy is looking for, but I think it's all there in the capture file. I just have to send him the WPA credentials along with the captured data so that he can configure the proper decryption settings. (I have no problem doing this since it's really a simple development network with no access to critical data.)

This just might be the breakthrough I've been looking for. 8)

Hmmm… still talking to myself. But I figure I should document solutions to various issues I brought up. Maybe it’ll help someone else

ShapeShifter:
Strangely, when I issue either the “airodump-ng mon0” or the “airodump-ng -c 8 --bssid D8:50:E6:D7:EA:1E -w capture mon0” commands, all I get is a blank screen. (Actually, a continuous stream of escape sequences to clear the screen and move the cursor to 1,1.) But I get no information printed out. I will have to look into why that is…

Initially, I was using PuTTY with the USB interface and the sample YunSerialTerminal sketch to access the command line. Basically because the wireless was busy with the monitoring task and I didn’t want to interfere with it, so the USB seemed like the most expedient data path. Well, doing that, I got nothing but a blank screen.

Today, I plugged in a wired Ethernet cable so that I could SCP the files I was collecting without needing to constantly shuffle SD cards. Since I had the connection, I used PuTTY to SSH directly to the Yun. When I do that, the dynamic output from airomon-ng shows up exactly as expected!

There must be something in the CLI to tty to 32u4 to USB chain that is preventing the dynamic data from coming through. The clear screen and position cursor to 1,1 escape sequences come through, but not the actual content. Curious. At least there is a workaround - forget the kludged connection and SSH in directly!

Once again, my sincere thanks to sonnyyu: I’ve been struggling with this WiFi module for a few months, and have been unable to get my tech support guy the data he needs to analyze the problem. I have finally sent him detailed information (including .cap files!) showing three of the biggest problems I’ve been having. Hopefully he can figure out what’s going wrong. Without sonnyyu’s help, I’d still be spinning my wheels!