Sniffing on a raspberry pi update

A comment from Carlos has given an additional pointer that I wanted to highlight. It appears when he ran through the methodology an openssl library wasn’t installed so the compile of aircrack-ng failed. He was so kind as to also leave the apt-get command to get this fixed. In the future go ahead and install the openssl library at the time that you also install subversion. If you’ve already got the lib, apt-get won’t really care so no harm, no foul.

pi@raspberrypi ~ $ sudo apt-get install subversion libssl-dev
pi@raspberrypi ~ $ svn co aircrack-ng
Checked out external at revision 2177.
Checked out revision 2177.
pi@raspberrypi ~ $ cd aircrack-ng

The rest can be found in the previous post here

Sniffing on a raspberry pi

So after a twitter back and forth with Craig Schnarrs (@the_wifi_guy) I felt it would be helpful to show others how I got sniffing working on my raspberry pi with a Tenda W311M usb wireless card. This is going to be a “from scratch” deal since I don’t want to pooch my current install on another card and i’m writing this along with performing the actions so the output copies here accurately. Also note that I scrub a bunch of output from the cli because I don’t want a 50 page post. The input is left in there so you can cut and paste if needed. Here goes..

First I’m grabbing the latest and greatest rasbian wheezy build from the rpi page.

I’m actually doing a wget in to my linux vm to get this started. Personally any time I write to flash cards and use dd I try to do it in a linux vm. That idiot-proofs things for me pretty well so I don’t do something nasty to my main machine. For these purposes I have a cheapo usb to multi-card reader that gets passed through in vmware player.

colin@python-dev:~$ mkdir temp
colin@python-dev:~$ cd temp/
colin@python-dev:~/temp$ wget http://**put your own mirror link here**
colin@python-dev:~/temp$ unzip

Optionally you can wipe your flash drive if you move them around a lot like I do and might have extra garbage on there. I typically like gparted due to laziness and the ability for graphical verification.

Use fdisk and/or dmesg to figure out where my flash is and then dd to the target (this will take some time, 33 min in my case).

colin@python-dev:~/temp$ sudo fdisk -l

Disk /dev/sdc: 7958 MB, 7958691840 bytes
151 heads, 15 sectors/track, 6862 cylinders, total 15544320 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00096c65

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048    15544319     7771136   83  Linux

colin@python-dev:~/temp$ sudo dd if=./2012-07-15-wheezy-raspbian.img of=/dev/sdc bs=512
3788800+0 records in
3788800+0 records out
1939865600 bytes (1.9 GB) copied, 2022.43 s, 959 kB/s

Remove flash card from reader, shutdown vm, stick in rpi and boot. I won’t go over how to do the setup menu so just google if you’re having issues. Once in a shell on the rpi, plug in the wifi nic and lets take a look at what dmesg and lsusb tells us about this Tenda card.

pi@raspberrypi ~ $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 005: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

pi@raspberrypi ~ $ sudo dmesg
[  470.710776] usb 1-1.3: USB disconnect, device number 4
[  745.375862] usb 1-1.2: new high speed USB device number 5 using dwc_otg
[  745.493792] usb 1-1.2: New USB device found, idVendor=148f, idProduct=5370
[  745.493829] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  745.493849] usb 1-1.2: Product: 802.11 n WLAN
[  745.493875] usb 1-1.2: Manufacturer: Ralink
[  745.493891] usb 1-1.2: SerialNumber: 1.0
[  745.592082] cfg80211: Calling CRDA to update world regulatory domain
[  745.815877] usb 1-1.2: reset high speed USB device number 5 using dwc_otg
[  745.994044] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[  745.998921] Registered led device: rt2800usb-phy0::radio
[  745.999536] Registered led device: rt2800usb-phy0::assoc
[  746.000099] Registered led device: rt2800usb-phy0::quality
[  746.002914] usbcore: registered new interface driver rt2800usb

So I cheated a bit when I went to microcenter to stock up for my rpi. I had this and google with me. From that I was able to find the cheapest/smallest card I could, lookup the chipset, then check it against the wiki. Notice the “M” isn’t specifically mentioned in the wiki but I knew the chipset was all good so I proceeded with my purchase. Heck, it was < $10 so I would have found another use if not for this guy.

Now that we’re verified the chipset, let’s get to work installing a few things to make sniffing easier. Monitor mode can work out of the box sometimes but I’ll be damned if I can recall the proper syntax all the time. So, like most things, I’m lazy and I cheat by using tools that already exist. Let’s install iw and tshark (or wireshark if you insist on doing any of this in a gui). The build-essential package is already included but if you’re using some other pre-done image you may need to install it as well.

pi@raspberrypi ~ $ sudo apt-get install iw tshark

After the few minutes that takes, we’ll get to the secret sauce. I really like the airmon-ng tool to cleanly build and tear down monitor instances for me. I also like to use the latest version of the code so we’ll have to install subversion first to check it out.

*** Update ***
Check this post for an update if aircrack fails compiling due to a missing openssl lib.
*** /Update ***

pi@raspberrypi ~ $ sudo apt-get install subversion
pi@raspberrypi ~ $ svn co aircrack-ng
Checked out external at revision 2177.
Checked out revision 2177.
pi@raspberrypi ~ $ cd aircrack-ng

Let’s compile and install (be patient)

pi@raspberrypi ~/aircrack-ng $ make
pi@raspberrypi ~/aircrack-ng $ sudo make install

For good measure I also update the OUI tool in case I need to spoof a MAC later.

pi@raspberrypi ~/aircrack-ng $ sudo airodump-ng-oui-update
[*] Downloading IEEE OUI file...
[*] Parsing OUI file...
[*] Airodump-ng OUI file successfully updated

Ok, we’re almost there. I’ll fire up a monitor interface for tshark (or your sniffer of choice) to use. airmon-ng will probably bitch about dhclient, ifplugd, and/or other things that may automagically do weird stuff to new interfaces. Kill at your own discretion/peril.

pi@raspberrypi ~/aircrack-ng $ sudo airmon-ng start wlan0 6

Found 4 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
PID     Name
1011    ifplugd
1031    ifplugd
1278    dhclient
2603    ifplugd
Process with PID 2603 (ifplugd) is running on interface wlan0

Interface       Chipset         Driver

wlan0           Ralink RT2870/3070      rt2800usb - [phy0]
                                (monitor mode enabled on mon0)

Now let’s do a demo sniff to just grab some probe requests.

pi@raspberrypi ~/aircrack-ng $ sudo tshark -i mon0 subtype probereq

Everything goes smoothly so rather than show output, here’s the same request written to a capture (sudo tshark -i mon0 subtype probereq -w /tmp/rpi-cap.pcap), scp’d over to my windows machine, and opened in wireshark.

Tear down your monitor interface when you’re finished if you’d like.

pi@raspberrypi ~/aircrack-ng $ sudo airmon-ng stop mon0

Interface       Chipset         Driver

wlan0           Ralink RT2870/3070      rt2800usb - [phy0]
mon0            Ralink RT2870/3070      rt2800usb - [phy0] (removed)

Add a few more sub-$10 wifi cards, a powered usb hub, and a battery and you’ve got a pretty small rig to help troubleshoot stuff like roaming issues.


Is the world ready for 802.11ac?

Just a quick post from the road with a screenshot of the state of hotel wireless in the area I’m in currently. It’s a bank of hotels near a mini-mall type area just over the major highway. I find these types of spots to be pretty typical in most towns that are not of a large size and thus a good barometer. Over the last 2 or so years I’ve slowly seen some hotel chains improving their networks due to the high demand (and expectation) from their customers. When I fired up Metageek’s inSSIDer to take a look at my survey AP’s channels I was pleasantly surprised. It would seem that the two hotels within moderate RF range (truth be told there are 2 others along this strip) are primarily using Ruckus and have their channel distribution set properly. After spending a good amount of time on the road in the last 1-1.5 years I can also state that this isn’t usually what I see. It would also appear that the retail chain across the street using Cisco gear not only has their power cranked up pretty high but they’re also not using the nice and clean 1/6/11 scheme. Insert facepalm and red faces here (do note this wasn’t *my* client).

Getting back to my post title, the other major thing of note is that there wasn’t a single 5ghz channel within range. Now I can’t be sure that our wayward Cisco AP didn’t have one due to distance but that would still only reveal one in many. While I’m happy to see channels being utilized properly (even if it’s not with the gear I use) I wonder why we’re still not seeing much 5 GHz. Is this the next step in the slow adoption of the service industry market? Will this piece of the market finally adopt 5ghz after vendors begin pushing 802.11ac? Finally, something I’ve been dwelling on for a while now. Once 802.11ac is out upon the masses will we have to wait several years before people are doing it “right” and be forced to live in the channel stomping reality that has plagued (and continues to plague in many cases) us in 2.4 GHz for so long? I’ll borrow a bit from Stan Lee and begin to say it now “With great bandwidth, comes great responsibility”. Are we ready for all that?

I certainly hope so….

Cisco MSE pains

I (and many others) have bumped in to problems when installing a Cisco MSE 3300 in a customer environment. Being a Linux zealot in my free time I’ve tried to make things easier on myself by tweaking some of the setup process.

Cisco’s setup script (in 7.0 at least) does some things to the network init scripts that are not nice and are not what I’d consider best practices. One problem people have run in to is after reboot the NICs will swap assignment (e.g. eth0 is now eth1). From my understanding the main reason for the instability is that the initial setup script rewrites the network config file and the new version doesn’t contain the MAC anymore. If I understand the udev process correctly, Linux dynamically allocates hardware assignment which is useful for things like plugging in a flash drive. The network hardware also goes through this process so if the network script doesn’t try to remember which NIC is eth0 and which is eth1 it’s basically a race condition for that assignment. I suspect that a lot of people are actually in this state but don’t realize it because they only configure one of the NICs via Cisco’s script. If you leave eth1 alone, it retains the original network script (which still contains the MAC) and basically eth1 always gets the MAC it wants and eth0 gets “the other one”. Things going poorly without anyone knowing….or at least this is what I suspect.

To fix this neat little issue you’ll want to add HWADDR=11:22:33:44:55:66 (subbing out your appropriate MAC) somewhere in the network config file located at /etc/sysconfig/network-scripts/ifcfg-eth0. The same obviously goes for eth1 and it’s corresponding MAC if you’ve set that up as well. I use a bit of CLI parsing to get that in there without using much effort. It’s probably not as pretty as it could be but it was quick and dirty and works.

[root@MSE /]# echo HWADDR=`ifconfig eth0 | grep -o -E '([[:xdigit:]]{1,2}:){5}[[:xdigit:]]{1,2}'` >> /etc/sysconfig/network-scripts/ifcfg-eth0
[root@MSE /]#
[root@MSE /]# echo HWADDR=`ifconfig eth1 | grep -o -E '([[:xdigit:]]{1,2}:){5}[[:xdigit:]]{1,2}'` >> /etc/sysconfig/network-scripts/ifcfg-eth1
[root@MSE /]#

It’s probably worth checking this just to be sure. Even when copying and pasting things you never know when something went wrong.

[root@MSE /]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
[root@MSE /]#

Another neat little thing the setup script does is clobber the gateway parameter. Obviously this will be dynamic based on your environment so sub out your appropriate IP for my example.

[root@MSE /]# echo GATEWAY= >;>; /etc/sysconfig/network-scripts/ifcfg-eth0
[root@MSE /]#
[root@MSE /]# echo GATEWAY= >;>; /etc/sysconfig/network-scripts/ifcfg-eth1
[root@MSE /]#

Let’s check again to make sure things look correct.

[root@CDW-MSE /]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
[root@CDW-MSE /]#

See this link for a description of this behavior:

Another little interesting gotcha for this problem is that the markings on the server casing don’t actually read eth0 and eth1 but could be listed as GE1 or BMC1. I’ve seen a small paper tag listing the MACs affixed to the back of the MSE which makes it much easier to figure out which is which. Finding the current binding in Linux is as easy as the following.

[root@MSE /]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:42:17:D1:B6:14
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::215:17ff:fed0:b444/64 Scope:Link
          RX packets:100 errors:0 dropped:0 overruns:0 frame:0
          TX packets:33 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12386 (12.0 KiB)  TX bytes:2410 (2.3 KiB)
          Base address:0x2000 Memory:e8180000-e81a0000
[root@MSE /]#

After all that is sorted out, I like to restart the network services on the box rather than doing a reboot. This lets me check to see if things are working without possibly putting my NICs back in an unknown state if I messed something up.

[root@MSE /]# network service restart
[root@MSE /]#

If the MSE is unreachable from WCS/NCS make sure the service is running using one or all of these:

[root@MSE /]# /opt/mse/setup/msed status
[root@MSE /]# /opt/mse/setup/msed start
[root@MSE /]# /opt/mse/setup/msed restart

After that you should be good to go.

Some other notes
A lot of the following is found in the Cisco guide, make sure you read that thoroughly. These are just some of the things I see brought up repeatedly and felt worth mentioning.

  • According to Cisco the MSE services are not supported on both interfaces at once. The second interface can be used for heartbeat services but I’m not aware of any other further official use. SSHD should bind to both interfaces so you could use it for remote access.

  • When asked for the hostname during the setup script put in only the hostname and not the FQDN.

  • If you’re starting from scratch and have to download the software from CCO, keep an eye on how you transfer the file over to your MSE. If using an ftp client this should be done in binary mode so avoid ASCII and possibly any sort of auto mode. Binary will copy a stream (bit for bit) so you end up with what you started with. ASCII mode might strip out some characters in the stream for control purposes which will break your file. Description found right here. Alternately consider using something like scp which is typically native in Linux and OSX. I like Winscp for Windows. To decompress and make the file executable:

    gzip -d filename.bin.gz *or* gunzip filename.bin.gz
    chmod 755 filename.bin *or* chmod +x filename.bin