I've Been Busy ... Box

I recently had a client where I did some wireless scanning and aside from the heavy PC tools, I used Wifi Analyzer on my Android phone. It's a nifty little tool, but didn't always show the detailed information I wanted. So I also installed Network Info II to get the detailed network information.

What I thought would be really helpful would be a terminal to access the Unix command line and I found that with Android Terminal Emulator. While a stellar app that provides a direct command line interface, it relies on the system installed commands - so we have some file manipulation tools (e.g., ls, cd, cat). It does not provide text manipulation tools (e.g., awk, cut, grep) and handy networking tools (e.g., nc, telnet, ssh). For that, you need to install busybox.

A lot of searching indicated most busybox installations for Android required root and I did not root my phone. This seemed odd since once installed, most command line utilities don't need root to run (except things like 'ping' which only required suid). I finally found some instructions to install a "non-root" busybox and tried it. I'm not linking to it because it only partially worked - the network tools couldn't perform name resolution; a partial success.

The solution I used was BusyBox Non-Root. This little application installs busybox, creates the necessary symlinks and provides a shortcut to copy/paste the install directory into a Unix $PATH statement. You can paste that into the "Initial command" under "Preferences" in the Android Terminal Emulation app. Now, from a command line I have access to working versions of 'nslookup', 'telnet', 'ssh' and many other text manipulation tools.

The only puzzling thing I found was netcat (nc) wasn't available. Running buxybox from the command line showed that 'nc' was available in the package, so a quick 'ln -s ./busybox ./nc' solved that problem. Of course I tested it and 'nc' works too!

A Window into porting BGPDump

After reading about injecting BGP prefixes into a GNS3 simulation, I was eager to test it. I went looking for BGPDump and found it was only available for Linux. The source files made no mention of building on Win32.

I've ported Linux "only" - that is, source that provides no Win32-specific directives, code and / or headers - to Windows by editing the source. Network applications - those that use the Linux network headers and the Winsock headers in Windows - are much more difficult. I wasn't going to try this one. I figured I could compile under Cygwin and just have the cygwin1.dll dependency.

I don't normally run Cygwin; instead, I use the Win32 native ports found at GnuWin32. I have them all in my C:\usr\bin directory - the first in my PATH - and also a copy of the cygwin1.dll in that directory for the few programs that need it (namely iperf.exe - again built under Cygwin due to the complex network headers and porting issues).

So I used my Windows Virtual PC that has Cygwin installed, downloaded the latest copy of BGPDump (version 1.4.99.13 / 21-Oct-2010 11:30 / 82K) and set to compiling it. The './configure' step went well. The 'make' not so much. I was missing some libraries, but the error messages were pretty obvious which ones were needed so I quickly re-ran the Cygwin setup - which also functions as a package manager - and installed the missing development libraries. Namely:

• libzip-devel
• libbz2-devel

I re-ran the build process and was done! I copied my C:\cygwin\bin\cygwin1.dll to the build directory and ran bgpdump.exe and it failed! Because it linked with those compression libraries, I also needed those DLL's as well as the libc DLL for Cygwin (cyggcc_s-1.dll). This was going to require an extra step. I needed to statically link the compression and libc libraries so the only dynamic dependency would be cygwin1.dll.

Looking at the 'make' output, I simply needed to modify the last build instruction from:

gcc -fPIC -g -O3 -Wall -Wsystem-headers -Wno-format-y2k -Wno-sign-compare -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wswitch -Wshadow  -o bgpdump bgpdump.c libbgpdump.a -lbz2 -lz

to:

gcc -fPIC -g -O3 -Wall -Wsystem-headers -Wno-format-y2k -Wno-sign-compare -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wswitch -Wshadow  -o bgpdump bgpdump.c libbgpdump.a -Wl,-Bstatic -lbz2 -lz -static-libgcc

I added the "-Wl,-Bstatic" option before the compression libraries and the "-static-libgcc" option to statically link libc. I ran that command and now bgpdump.exe works with only the cygwin1.dll dependency.

Wireless Worries Washed Away

For the amount of times we have people over the house that want to use my WIFI, giving out my super-secret hidden SSID and complex security passcode isn't a hassle. But I am giving out my super-secret hidden SSID and complex security passcode! Which means these people could at any time park inconspicuously outside my house on our dead-end cul-de-sac road and steal WIFI access siphoning off precious bandwidth and accessing nefarious web sites.

Of course, I'm not really worried about that, but with DD-WRT running, I can easily set up a second visible guest network ... so why not?

There are plenty of guides out there - some better than others. I won't create my own here. I did find the DD-WRT Wiki the most useful of all the links I visited.

I used the GUI to set it up. I created the second visible guest SSID. I used the same security - this time with an easy password. I created the bridge and assigned the bridge group. I created the secondary DHCP service. I tested and all was working well.

I was a bit confused about the DHCP setup, so I'll detail that here. I followed the step to create a secondary DHCP service for the guest network under "Setup" -> "Networking" tabs in the GUI. However, they mention DNSMasq and I knew I was running the primary DHCP service (found on "Setup" -> "Basic Setup") without DNSMasq enabled.

Ultimately, I enabled DNSMasq by going to "Setup" -> "Basic Setup" and clicking the check box for "Use DNSMasq for DHCP" and then enabling DNSMasq on the "Setup" -> "Services" tab by clicking the "Enable" radio button next to "DNSMasq". I did not enter the additional DNSMaq configuration into the text box like the Wiki shows. I didn't need to. A verification from the command line proved this:

root@DD-WRT:/tmp# more dnsmasq.conf
interface=br0,br1
resolv-file=/tmp/resolv.dnsmasq
domain=domain.net.
dhcp-leasefile=/tmp/dnsmasq.leases
dhcp-lease-max=20
dhcp-option=lan,3,192.168.10.1
dhcp-option=br1,3,192.168.2.1
dhcp-option=6,8.8.8.8,8.8.4.4
dhcp-range=lan,192.168.10.100,192.168.10.109,255.255.255.0,1440m
dhcp-range=br1,192.168.2.100,192.168.2.110,255.255.255.0,60m

The above DNSMasq config shows my primary LAN (lan = 192.168.10.0/24) and the new guest LAN (br1 = 192.168.2.0/24) set up to hand out addresses, default gateways and DNS servers.

I didn't bother with any additional iptables rules. Tests revealed I could not connect from the guest LAN to the primary LAN and vice-versa - which is what I want.

Now we just need to invite some more Internet-savvy guests over!

Android Update Brings IPv6

I was disappointed with AT&T not providing the Android 4.1.2 update when other US-based carriers made it available, especially since we got the 4.1.1 update pretty early. Even more disappointing was when this was finally available - around the beginning of August - my device never upgraded. A Google search the other night showed it was available and when I manually checked for updates - sure enough, it was.

I will say I'm pleased with the update. Multiwindow is pretty cool even if not standard. It doesn't support all apps - and even some common ones I use that would be nice to use in multiwindow mode - like Google Keep.

The best part is that IPv6 now seems to work! At least over WIFI. I have IPv6 running at home and was (again) disappointed when my wife's iPad and iPhone could get to IPv6 sites and my Android couldn't. But after the update, I tried What Is My IPv6 Address from my Android and got an IPv6 address back (you'll see your IPv4 address if IPv6 isn't working)! I confirmed with my favorite IPv6-only site Loops of Zen.

Reach the Beach Relay - 2013

This year was a bit different. We only had 6 people, but only 2 of those 6 (Ashley and I) were willing to do the ultra. So we opted for a "half-team" option where RTB matched us with 6 people in a similar situation. As always, it was an adventure. We started counting and recording "pieces of flair" (i.e., "road kills") - number of people passed while running.

Massakruliks - Half Team

197/474 - 5/8

			Vert
	Distance	Difficulty	Gain	Loss	Net	Flair	Time	Pace
Leg 8	6.61	Moderate	101	125	-24	+9	43:30	6:35
Leg 20	6.83	Hard	725	826	-101	+23	45:20	6:38
Leg 32	6.69	Moderate	324	413	-89	+15	45:55	6:52
	20.13					+47	2:14:45	6:42

IPv6 to IPv4 Server Load Balancing Testing in GNS3

My last post talked about testing IPv4 / IPv6 web and proxy services using Qemu in GNS3. My next challenge was to understand the "easy" way to IPv6-enable an IPv4-only web site - configure your load balancer to do it.

The simple explanation for Server Load Balancing IPv6 to IPv4 (SLB64) is that it performs traditional server load balancing functions but additionally does address family translation from the requested IPv6 address to the real IPv4 address of the internal servers in the server farm.

I don't have a big name load balancer at my disposal nor does my laptop have the power needed to download a virtual image and spin up VMware connected to my GNS3 simulation. So I went looking for a linux software based alternative and found HAProxy. The site indicates IPv6 support came along in version 1.1 and of course there is a Tiny Core linux package available. That meant following the Qemu "installation" procedure I described in a previous post and doing the proper 'filetool' backup.

My lab looks like the following, including an Apache web server running on Qemu in GNS3 as described in the last post:

IPV6 = 2001:db8

 192.168.100.254    192.168.100.1      10.100.100.17
IPV6:192:168::254  IPV6:192:168::1
     HOST      ------    R1    ------   Web Server
                    10.200.200.1          (Qemu)
                   IPv6:AC8:C800::1
                          |
                          |
                    10.200.200.17
                  IPV6:AC8:C800::254
                       HAProxy
                       (Qemu)

The HAProxy package didn't come with a configuration or startup script, so I had to create them. First, the configuration file was pretty simple to create in /usr/local/etc/haproxy.conf:

global
  user tc
  group staff
  daemon
defaults
  mode tcp
  retries 3
  timeout connect 5000
  timeout client 50000
  timeout server 50000
listen ipv6proxy80 :::80
  server ipv4server80 10.100.100.17:80

A little translation: the 'global' and 'default' headings just set some standard parameters for HAProxy operation. The 'listen' heading is where I tell HAProxy to listen for all incoming IPv6 traffic to TCP port 80 (TCP comes from the 'mode tcp' command in the 'defaults' section). HAProxy should then distribute matched traffic to the listed servers - in this case only 10.100.100.17 on port 80. Listening on IPv6 and distributing to an IPv4 server causes HAProxy to do the address family translation from IPv6 to IPv4. Note that you can make this configuration much more secure and/or selective, but this is perfect for my little test.

Next, the startup script in /etc/init.d/services/loadbal:

#!/bin/sh
case "${1}" in
  start)
    /usr/local/sbin/haproxy -f /usr/local/etc/haproxy.conf -p /var/run/haproxy.pid -D
    ;;
  stop)
    pkill haproxy
    ;;
  status)
    pidof haproxy
    ;;
  *)
    exit 1
    ;;
esac

HAProxy is now started with "sudo /etc/init.d/services/loadbal start".

To test we need to remember that HAProxy is our load balancer and thus is advertising the "outside" (read: Internet) address of the web server. So on the HOST, I open a browser and point it to:

http://[2001:db8:AC8:C800::254]:80

SUCCESS! I get the home page from the Apache web server complete with the link to the CGI script to print my environment variables as described in my last post. That certainly comes in handy to see where the web server thinks the connection is coming from as does a 'netstat -an' on the HAProxy Qemu linux console.

IPv4 / IPv6 Web and Proxy Server Testing in GNS3

In a previous post, I described how I got some additional packages installed on Tiny Core linux to use with Qemu in my GNS3 simulations. While that post describes how I got a DHCPv6 client loaded on my Tiny Core image, at the time I also loaded Apache. This gave me an IPv4 / IPv6 web server to test with. Additionally, Apache can be run as a proxy server, so I could test IPv4 / IPv6 proxy services with the single Apache install.

The first step was to create a configuration file for both web server and proxy. The default is installed in /usr/local/apache2/conf/httpd.conf and is suitable for the web server configuration. I copied that file to /usr/local/apache2/conf/proxy.conf and edited it. I kept only the "LoadModule" commands and then added:

ServerRoot "/usr/local/apache2"
listen 8080
User tc
Group staff
ProxyRequests On

You can get fancier, but that's all you really need for testing in a closed GNS3 lab environment.

Next, a nice home page on the web server that automatically displays some information would be nice. Printing environment variables like client IP address and server IP address will come in handy when testing through a proxy server to see what address (IPv4 or IPv6, client or proxy server) the "world" will see. Thankfully, the default install has this file. Unfortunately, it didn't work for me.

I had a permission issue and since the CGI script was really a link to the file, I couldn't change the permissions. Easy solution was to simply copy the file to the CGI bin directory and make the appropriate edits.

So first I need an index.html in /usr/local/apache2/htdocs. That looks like this:

<html>
<head>
<title>Title</title>
</head>
<body>
<h1>It works!</h1>
<a href = "cgi-bin/test-cgi-new">Environment</a>
</body>

Next, the actual /usr/local/apache2/cgi-bin/test-cgi-new script is create with:

cd /usr/local/apache2/cgi-bin
cp ./test-cgi ./test-cgi-new
chown tc test-cgi-new
chgrp staff test-cgi-new
chmod 755 test-cgi-new

Finally, a startup script for both web server and proxy server in /etc/init.d/services:

--httpd--

#!/bin/sh
case "${1}" in
  start)
    /usr/local/apache2/bin/httpd
    ;;
  stop)
    pkill httpd
    ;;
  status)
    pidof httpd
    ;;
  *)
    exit 1
    ;;
esac

--proxy--

#!/bin/sh
case "${1}" in
  start)
    /usr/local/apache2/bin/httpd -f /usr/local/apache2/conf/proxy.conf
    ;;
  stop)
    pkill httpd
    ;;
  status)
    pidof httpd
    ;;
  *)
    exit 1
    ;;
esac

Now I can start them with "sudo /etc/init.d/services/httpd start" and "sudo /etc/init.d/services/proxy start".

Of course, make sure you do this on Qemu outside of GNS3 and save your configurations by editing the appropriate "/opt/.filetool.lst" file and running "filetool" to backup as described in the previous post.

Then, I created a simple GNS3 lab with a router in the middle. I made one connection bridged to my host machine (loopback interface) and added some routes on the host to point towards the simulation networks. I made another router connection to one instance of Qemu where I run the proxy service. The final router connection goes to another instance of Qemu where I run the web server. Now I can test from my host browser on IPv4 and IPv6 to the test web server and I can also configure the simulation proxy server on my host to test out IPv4 / IPv6 proxy services to the web server in the simulation.

Next, I'll describe how I setup and tested Server Load Balancing 6 to 4 (SLB64) with HAProxy.