Pidgin spellcheck

Mercilessly ripped from http://www.techfurs.net/1/post/2012/02/how-to-manually-install-spell-check-into-pidgin-windows.html and all props to darkfur93.

1. Create pidgin\spellcheck\share\enchant\myspell\ if it’s not there already
2. Download American English Dictionary from https://s3.amazonaws.com/TechFurs1/english.zip
3. Extract contents (en_US.aff and en_US.dic) to myspell folder
4. Restart Pidgin and test

Drive recovery, disk upgrade, and firmware update

So after a very weird situation the other day where my ddwrt router factor reset itself (for no apparent reason) I got the following message.

“Well shoot, that’s not good” I thought to myself (and other various curse words). So yesterday after work a trip down to microcenter to collect some replacement drives happened. I have been debating upgrading storage space anyway so this seemed like a good excuse to bring my DNS323 NAS up to 2TB of mirrored storage. Today I’ve un-boxed one of the drives and pulled the working “left” drive from the NAS. I’m using two usb SATA bridges (one is a case and one is a quickie bridge that’s meant for “instant backup” or something similar) on an older Lenovo laptop.


The laptop is being boot with gparted live via a 4 GB usb flash drive which was created very simply using UUI (Universal USB Installer). While this is a painfully slow processes, I’m using the ever trustworthy dd utility to copy the old drive bit for bit to the new 2 TB Seagate. Once that’s copied over, I’ll use gparted to re-size my partition to use the extra space that the 2TB drive provides. After that I’ll test the new drive in the NAS to make sure all my files are still there and in good working order, upgrade the firmware on the DNS323, then stick in the second 2TB drive to build the new RAID array.

Here’s the current status with a fairly slow moving dd. I probably should have changed the bs value when I started it but I’m not in a specific hurry so it can just run as is. dv didn’t come standard with gparted live so I had to un-comment the apt-get sources, apt-get update, and apt-get install pv. Using pv is nice to get some sort of info back on what’s happening rather than dd just staring blankly at you until it’s done. You’ll also notice I took a few notes regarding my drives as to not accidentally write over something important. Figuring out your drives can be done with fdisk -l, dmesg, and/or gparted itself.

I’ll try to update again after I’ve re-sized, upgraded firmware, and built new array. Fingers crossed…

Keepalive

My recent move means I’m relying on my 4G hotspot for internet at the moment. The range of this guy’s wifi isn’t that great so I’ve used another laptop to bridge the connection from the hotspot to it’s NIC and then plugged in a dd-wrt router in to that. It’s ugly but it was quick and it works (nothing that will freak over a double NAT right now). To keep it from puking or sleeping I decided that I want to send a bit of traffic every once in a while just in case. Rather than a continuous ping, I’ve got a batch that’ll do a normal 4 packet ping every 3 min. Probably of use to nobody but myself, it’s being archived for prosperity.

set INPUT1=1
set INPUT2=1

:Loopme

ping 8.8.8.8
timeout 180

IF NOT INPUT1 == INPUT2 GOTO Loopme

:EndLoopme

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 http://trac.aircrack-ng.org/svn/trunk 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 2012-07-15-wheezy-raspbian.zip

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 http://trac.aircrack-ng.org/svn/trunk 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!
-e
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.

Enjoy!

Config parsing

A quick post so I can reference later. I’m starting to play with RANCID after a suggestion from a coworker. While I’m not necessarily doing config diffs it does provide a platform to quickly connect to a variety of Cisco devices and spit out desired output. In the last week I’ve used this to enumerate some devices and find autonomous access points. I’ll write up a proper post on how I did that sometime in the future (hopefully) but for now let’s just look at what I did tonight to get an IP listing for RANCID.

Starting from about 10-15 backed up switch config files, I wanted to get a quick management IP address listing to use with my RANCID stuff. I did not configure these switches myself and the network is not well known to me at all so this was a gem lurking in my configs that I couldn’t just pluck from my brain. Knowing that my management vlan is 150 I figured I could just grep out the IP set on that SVI from each file. From the directory with all my switch configs (in a Linux VM) I ran the following to parse out my VLAN 150 line and the line after that containing the IP address. (In retrospect I should make this first command a bit more intelligent. I got lucky in the fact that there weren’t switches with description or some other command right after the interface.)

ubuntu-vm:~$ grep -A1 Vlan150 * > step1

Output looks like this:

--
switch-poe2960-confg:interface Vlan150
switch-poe2960-confg- ip address 192.168.150.53 255.255.255.0
--

Then I use grep again with some regex to strip out stuff that looks like IP addresses and place it on it’s own line.

ubuntu-vm:~$ grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' step1 > step2

Output looks like this:

192.168.150.53
255.255.255.0
192.168.150.54
255.255.255.0
192.168.150.51
255.255.255.0

One more grep to get rid of the subnet masks that I don’t care about. Initially I matched on a specific /24 but I realized maybe someone could fat finger or there could be other masks. I settled on this command which was quick enough to do the job.

ubuntu-vm:~$ grep -v 255.* step2 > step3

Output looks like this:

192.168.150.53
192.168.150.54
192.168.150.51

Finally for good measure sort and remove any dupes

ubuntu-vm:~$ sort step3 | uniq > final

Output looks like this:

192.168.150.51
192.168.150.53
192.168.150.54

What I have in the end is a listing of the IP addresses of the SVIs for vlan 150. This is then used as input for a script that does a few for loops with rancid. One file for IPs and one for commands letting RANCID do the harder login work and providing me with a single file as an output. In this case I was doing a show cdp neighbor to look for my APs.

This was a pretty quick operation while watching a movie so I know it’s not as tight as it could be. It relies on regex pretty heavily so if you aren’t familiar it could be confusing. Google it and take some time to learn, it’s a very useful method of parsing data. I could probably string it all together in one massively long piped command but it’s not something I’ll hopefully be repeating often so it’s not needed. I also like to do things in steps like this so I can verify my output along the way. Typically I’ll run the command and watch what it spits out and if it looks good I’ll run again using the output modifier to write to a file. If I pushed it all together in one string from the get go, It’d be quite difficult to figure out what the heck went wrong when something unexpected shows up. This also gives me some checks and balances along the way if steps 1 to X look good but X+1 is funky. I don’t have to throw away everything I did previously, just look at what happened at X+1.

This is pretty basic stuff but hopefully someone else finds this useful. If not at least I can come back to grab and reuse the regex and grep flags :)

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
DEVICE=eth0
BOOTPROTO=none
BROADCAST=172.16.30.255
IPADDR=172.16.30.5
NETMASK=255.255.255.0
NETWORK=172.16.30.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
HWADDR=00:42:17:D1:B6:14
[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=172.16.30.1 >;>; /etc/sysconfig/network-scripts/ifcfg-eth0
[root@MSE /]#
[root@MSE /]# echo GATEWAY=172.16.50.1 >;>; /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
DEVICE=eth0
BOOTPROTO=none
BROADCAST=172.16.30.255
IPADDR=172.16.30.5
NETMASK=255.255.255.0
NETWORK=172.16.30.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
HWADDR=00:42:17:D1:B6:14
GATEWAY=172.16.30.1
[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:172.16.30.5  Bcast:172.16.30.255  Mask:255.255.255.0
          inet6 addr: fe80::215:17ff:fed0:b444/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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

First!!!!!!!!!111!1one111!!!

First post to yet another attempt at some sort of blogging.

Lately I’ve found myself figuring out little snippets of code and tips and tricks for various stuff I’ve been working on both professionally and personally.  I’m the type of person that *might* bookmark a site but probably doesn’t actually go back to look at it again.  Typically 6 months later I can’t recall how I did something specifically so I’m at a loss.  This will hopefully serve as a platform to fix such problems.  I’ll also be putting up items regarding wireless stuff I do for work in an effort to give back to the great community that exists.  I don’t anticipate anything groundbreaking here but I hope my take on something might help someone else or lead them down a path of their own.  I’m also by no means perfect so I welcome any constructive help (especially if you see me doing something just totally wrong).

Enjoy!

-C