


Characters courtesy of SP Studio
The value proposition of Software Defined Networks (SDN) begs the question, what is the promise versus what is the reality? Most of the current literature states SDNs value proposition in list format without clear, well-defined use cases as to where it can directly benefit today's complex enterprise networks. To state it another way, SDN may be an panacea, but the path to get there from today's reality is obfuscated.
That leaves us with two main points:On Sunday, November 10, 2013, I ran in the fifth annual RI 6 Hour Ultramarathon. My goal - as in past years, was to do at least as well as I did the previous year.
The official results place me 11/93 with an official total mileage of 40.515 miles in 5:57:28.1.
The table below documents my miles and times (by my watch).
| RI 6 Hour Ultramarathon: November 10, 2013 | ||||||
|---|---|---|---|---|---|---|
| Lap | Mileage | Cumm. Mile. | Lap Split | Cumm. Time | Lap Pace | Avg. Pace |
| 1 | 2.7 | 2.7 | 22:22.32 | 0:22:22.3 | 08:17.2 | 08:17.2 |
| 2 | 2.7 | 5.4 | 22:06.63 | 0:44:29.0 | 08:11.3 | 08:14.2 |
| 3 | 2.7 | 8.1 | 22:09.40 | 1:06:38.3 | 08:12.4 | 08:13.6 |
| 4 | 2.7 | 10.8 | 22:12.88 | 1:28:51.2 | 08:13.7 | 08:13.6 |
| 5 | 2.7 | 13.5 | 22:31.30 | 1:51:22.5 | 08:20.5 | 08:15.0 |
| 6 | 2.7 | 16.2 | 22:34.31 | 2:13:56.8 | 08:21.6 | 08:16.1 |
| 7 | 2.7 | 18.9 | 22:43.45 | 2:36:40.3 | 08:25.0 | 08:17.4 |
| 8 | 2.7 | 21.6 | 22:57.88 | 2:59:38.2 | 08:30.3 | 08:19.0 |
| 9 | 2.7 | 24.3 | 23:43.08 | 3:23:12.2 | 08:47.1 | 08:22.1 |
| Marathon | 26.2 | -- | 3:40:20.0 | -- | 08:24.6 | |
| 10 | 2.7 | 27 | 23:53.53 | 3:47:14.8 | 08:50.9 | 08:25.0 |
| 11 | 2.7 | 29.7 | 24:47.51 | 4:12:02.3 | 09:10.9 | 08:29.2 |
| 50K | 31.25 | -- | 4:24:51.0 | -- | 08:28.5 | |
| 12 | 2.7 | 32.4 | 26:07.19 | 4:38:09.5 | 09:40.4 | 08:35.1 |
| 13 | 2.7 | 35.1 | 26:56.68 | 5:05:06.2 | 09:58.8 | 08:41.5 |
| 14 | 2.7 | 37.8 | 28:08.92 | 5:33:15.1 | 10:25.5 | 08:49.0 |
| 15 | 2.7 | 40.5 | 24:12.76 | 5:57:27.8 | 08:58.1 | 08:49.6 |
| Totals: | 40.515 | 5:57:28.1 | 08:49.6 | |||
I didn't get a new Nexus 5, nor do I have Android KitKat 4.4 on my Samsung Galaxy S3. However, others have managed to get the APK's for some new Google apps off the Nexus 5. I didn't venture to load the Google Experience Launcher - I use Nova Launcher Prime in favor of standard Samsung TouchWiz. But I did have to test drive the new Hangouts app - now with integrated SMS.
At this point, the Play store did not have the updated Hangouts v2 (only version 1.2 which I had loaded). I grabbed the APK, did the standard side-load procedure through ES File Explorer and tested it out.
At first startup, it notified me that it can handle SMS and asked if I wanted to enable it. Hell yes! And 'BAM', there it was - all my existing SMS threads showing up (including MMS messages) in the Hangouts interface. I tested with some texting to/from the phone and received messages in both the Hangouts app and the default messaging app - as I expected (they're pulling data from the same store).
I did not get the standard messaging app notifications when texts arrived - only the Hangouts notification in the notification bar - excellent! So no double notifications, but message counts is the only thing missing. As I mentioned, I use Nova Launcher - more specifically, TeslaUnread - to put the unread count overlay on things like GMail and messaging. It never worked for MMS messages, and now it doesn't work for SMS either. No unread count overlaying the Hangouts icon in my dock. Not to worry, with the notification bar working, I'm sure I won't miss any texts.
So even though no KitKat (bars or software) were received for Halloween, I still did get a treat! Now just waiting on Google Voice VoIP calling so I don't have to use Talkatone.
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!
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:
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.
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!