Home ........ Blog ........ Travels ........ Software ........ Web 3D ........ LinkedIn

Monday, October 14, 2013

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!

Wednesday, October 09, 2013

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 / 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


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.

Monday, October 07, 2013

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

The above DNSMasq config shows my primary LAN (lan = and the new guest LAN (br1 = 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!


Copyright © VinsWorld. All Rights Reserved.