Tour 2011, part 3: Traffic Congestion on the Internet Highway

This week has been predicted as the week the IPv4 address space gets used up.  Or, at least, completely allocated.  But, that’s just one problem with the increased usage on the Internet.  With network address translation (common in home networks, wireless networks, and small businesses), millions of computers are hidden in private LAN address blocks, so the address space problem isn’t as dire as you might think.

But, as we travel across the country, we have had increasing issues with wireless interference.  There are so many access points in so many places, the chances of channel collisions are quite high.  In two of the cities we have stayed so far, the wireless access points in two physically adjacent businesses have ended up on the same channels, resulting in enough interference to prevent Internet access.  Our computer gets an address assigned, from the selected ESSID, but getting a DHCP address through broadcast is very different than getting communications through on the channel, so the effect is no data transfer.

The solution we use at Chaos Central, where we, of course, control the wireless access point, is to select a different channel.  However, the staff at coffee shops and motels are  neither trained nor authorized to perform this simple action, so they just shrug and mumble something about asking the manager to call the phone company or guessing that it is just normal traffic congestion on their network and telling customers to just wait it out.

The phone company has similar issues.  Even if your internet service provider has a Class B network, only 65,000 clients can be served concurrently.  Like the airlines and hotels overbooking, they can certainly sell more accounts than they have addresses for, with the likelihood that not all the account holders will have their computers on at the same time.  The tricky part is how to deal with the possibility that the address space (or local DHCP scope) gets completely used up.

In high-usage areas across the country, we have noticed that wireless connections get dropped frequently, either after a specific time period, say 30 to 45 minutes, or after a period of inactivity, typically 3 to 5 minutes.  This also seems to be happening on the DSL networks, as the IP address at Chaos Central shifts from time to time, even though the modem is always on.

Now, such arbitrary disconnections often go unnoticed, if all you are doing is browsing web pages or reading email, but trying to run a VPN connection, encrypted tunnel, or large file upload or download is a trying experience with loss of connections.  A few weeks ago, this was happening at Chaos Central at an alarming rate: calls to the DSL provider’s tech support claims that “it must be your modem,” even though a DHCP client will normally ask for the same address if the connection drops.  However, the reconnect rate improved after the call, even before we replaced the modem (which was an old model anyway).  After a few weeks, the new modem changes address now and then, indicating to the Unix Curmudgeon that the problem is not so much with bad phone lines and cheap modems, but with traffic congestion on the network.

When a connection drops, whether because of deliberate disconnection due to timeouts or duration policies, if the modem gets a new address it is because the old one was issued to someone else in that brief time required to re-establish the connection.  Which, of course, means that there are more active accounts than available addresses, either in the network or in the DHCP zone for that circuit.

Obviously, in stressed economic times, things are going to get worse before they get better.  But, change is coming soon.  Like the splitting of states and metropolitan areas into multiple area codes to accommodate the explosion of “one person, one phone number” caused by Centrex dialing for businesses and personal cell phones, access to the Internet will undergo a revolution.  First, to implement IPv6, in which the hardware address of the network card in your computer is added to the IP address to expand the address space without network address translation, and second, to expand the wireless networking protocols to incorporate more channels and intelligent adaptive interference avoidance.

Meanwhile, we’re back to the early days of limited wireless access, seeking out connections where we can.  And, we deal with the mutable addresses at Chaos Central by having programs running that post the current address to a secure file location on our public web servers, so we can always login remotely.  Change is sometimes progress, and sometimes just an adventure.

Tour 2011, part 2: We Don’t Serve Their Kind Here

We’ve completed the first leg of Tour 2011, arriving in the City of Angels mid-day.  Our GPS took us to the Nice Person’s sister’s house, no problem.  The problem started when we needed to get connected to the Internet.

Sis and her hubby travel a lot, so they have cellular Internet access.  OK, we say, we’ll just plug the dongle into our computer and surf away.  But, no joy.  The USB device mounts as a disk drive, no problem.  But, the System Requirements (and provided drivers) are for Windows 7, Vista, XP, and 2000.  Period.  Guess what?  We’re the Unix Curmudgeon.  We run Linux!

Now, why does Verizon think that Linux users don’t need to use the Internet? Or, more precisely, why does Verizon think they can survive without the business of Linux users everywhere? 

OK, there are Linux packages that interface with the cellular modems, but they are not provided by the service vendors, nor do they support use of the device on Linux systems.  And, they are relatively hard to find.  Essentially, the cellular modem is just that — a modem, so setting it up as a PPP device and adding the configuration and chat scripts is all that is necessary to use them.  But, it has been a long time since most long-time Linux users (like the Unix Curmudgeon) had to configure modem scripts by hand, and most new Linux users are blissfully unaware of such arcania.

The aggravation here is not being able to use a device out of the box.  Using the cellular modem requires getting files from somewhere else (on the Internet) before you can get on the Internet.  Humph.  There is always the coffee shop down the street, but not being able to get Internet access almost anywhere is a major impediment to keep up with work on the road.

Tour 2011, part 1: Solid Transport, Shaky Wireless

The road trip season started early this year…  The Unix Curmudgeon and the Nice Person loaded up the newly-acquired Green Hornet with quilts, computers, and layered clothing and headed south through the ever-present Pacific Northwest rain, down the I-5 corridor, on a quest that will take us to I-10, then across to I-25, and a meandering diagonal back to Chaos Central by the first week in February.

Of course, crucial to all this planning, besides getting new wheels for the first time in 17 years, is staying connected to the Internet, from whence money flows in and out to fuel trips like this and keep the home fires burning.  As mentioned in an earlier post, “rover,” our trusty Ubuntu Linux development machine, had, during our last extended road trip in November/December, developed an aversion to wireless connectivity.  The little NetworkManager icon on the panel simply refused to appear after we got home.  This didn’t matter at Chaos Central, because we’re usually wired, but became an issue when preparing to unplug.

After much poking and prodding, reconfiguring, reinstalling drivers and packages, and so forth, the missing icon still refused to appear.  the iwlist scan command showed the wireless driver was loaded and working–we could see all the networks, but couldn’t connect.  The Network Connections menu under System -> Administration mysteriously “grayed out” when it was time to enter the encryption key for our home network.  With only a couple of days to fix it and a backlog of work that had to be finished before leaving, desperation set in.

Finally, the brain cells clicked on the fact that, if everything seems to be working, but you can’t communicate, it’s a permissions problem.  Sure enough, I had, in some fit of sysadmin tidiness, installed the Firestarter firewall.  Aha.  Getting rid of that seemed to help, somewhat.  I’m old-school enough to hand-edit iptables, so firewall GUI apps that don’t let you fine-tune your configuration are just out.  I also removed Oracle’s VirtualBox, which I had installed about the time the wireless started misbehaving, since VirtualBox also adds a few kernel modules that might conflict with the wireless driver module.

But, still no wireless icon.  Next, I removed all of the wireless assistant applications that had accumulated during this fiasco and reinstalled wifi-radar, a venerable tool that predates the NetworkManager by several releases.  Now, I haven’t had a lot of luck with wifi-radar in the past, probably due to multiple conflicting management tools, but this time, it seemed to work.  Not as smoothly as the newer NetworkManager used to work, but, since we can’t get the NetworkManager to work, it will do.

If you have been reading along for a while, you probably have deduced that we’re pretty firmly committed to Linux as the operating platform of choice, and have been using Ubuntu on the laptop for several years, plus Fedora, Red Hat, CentOS, and SuSE on various platforms, having started with Slackware in the mid-90s.  But, the subject of wireless networking remains, in my opinion, the last big obstacle to total World Domination by the “One True Operating System.”  One reason might be that, until recently, not many of us used laptops as our primary Linux machines, so there just hasn’t been enough collective brainpower behind this problem.  Also, there has been the age-old issue of open hardware bus standards–conceived by IBM when the personal computer was developed–versus proprietary peripheral hardware.  There is no universal device interface standard (like SCSI) for network cards, so manufacturers consider the device driver software to be proprietary.  As such, they can’t be bundled in with open-source Linux distributions.  There are some common chip-set versions from various manufacturers that talented Linux systems programmers have gotten to work, but the hard-core proprietary systems have been tough to crack.  Broadcom now does provide Linux drivers for their cards, which appear in many popular laptop models, but installation and configuration is still an exercise for the user.

But, since Ubuntu 9.10, the whole wireless experience has gotten easier.  There is “some assembly required” to get the 3rd-party restricted drivers installed, but after that, wireless networking is almost as painless as on a Mac or Windows machine.  Unless, like the Unix Curmudgeon, you are systems administrator or developer who tweaks on the machine, at which time it gets a bit precarious.  If you install the Broadcom driver from the Broadcom download site, you have to rebuild it every time the kernel gets updated to a new revision.  If you install it from the Ubuntu repository, it will automatically get updated, but might end up with compatibility issues with the wireless security module.  As a matter of course, I try not to update the kernel when on road trips unless I have access to a wired network so I can fix the networking if everything goes south.  So it goes.  Road trips are truly adventures, both on and off the road.  The saga continues.

General Purpose Vehicle #2

Here at Chaos Central, the Unix Curmudgeon and the Nice Person are getting ready for the first road trip of 2011, with the usual chaos ensuing.  The Nice Person (being nice) has promised a number of quilts to be finished, to be delivered as part of our trip, so she is frantically racing the big Gammill machine over quilt tops at a dizzying pace, lubricated with quantities of acetaminophen.  The Unix Curmudgeon recently answered a call for volunteers at a local non-profit and is frantically converting their web site from a hodge-podge of HTML2.0 and HTML4.01 generated by various word processors over the years into a streamlined PHP and CSS-driven integrated site that is not only consistent, but reasonable to maintain and follows an overall theme.

Amid this level of chaos, along with trying to get a more permanent solution to the monsoon-fueled pool at the entrance to the basement-level garage other than the sump-pump-in-a-bucket in a hole in the driveway, the wireless networking on our primary development Linux laptop and road machine has decided to be stubborn, defying all attempts to get it to work properly.  The driver, always a crap shoot in the world of Linux and proprietary hardware drivers, appears to be working–we can see the networks with the wireless tools, but the connections just aren’t connecting.  It appears to be some sort of permissions problem, compounded by the fact that, in this wild frontier of Linux hacking at its best, there are several ways to do it, none of which work, and some of which may be counteracting others.  This saga continues.  We do have one Linux netbook that does appear to still have a functioning wireless capability, so we are good to go as far as being able to read email and login to do system administration on the road.

But, which brings us to the subject, we realized the folly of attempting yet another marathon 7500Km road trip in a 17-year-old Jeep with 300,000Km on the odometer.  We’ve been putting off looking at replacement (or supplemental) vehicles because, in the midst of the real-estate crash and recession, we are encumbered with more houses than we can reasonably occupy at once.  But, the inevitable is upon us.  The venerable old machine, which never got a name other than “Jeep,” has carried us and our 25-year-old tandem bicycle on many adventures over the last 17 years, but it was time to retire it.

We went to the local Jeep dealer this weekend, with the idea of kicking the tires and looking at the newer models (i.e., anything built in the 21st century) up close and personal, but without any pretense of being able to budget a new or even late-model used vehicle.  There were other issues, too: we have a large cargo trailer we used to move our heavy equipment from Montana, which has been in storage for a year, with brief excursions by the kids to move their household last fall.  We found a suitable replacement vehicle, but, of course, with no tow package and no drip rails for our aged tandem rack.  The tandem we can deal with, as we are thinking of replacing the tandem as well by the time we need to be in Michigan for a bike tour this fall.  The trailer is another problem–without a way to tow it, delivering it to a potential buyer is out of the picture.  Well, it was beginning to look like a fanciful diversion for a rainy Saturday, when the salesman, Steve, who used to be an RV dealer, mentioned that we might be able to trade in both Jeep and the trailer in one deal.

Jeep and trailer
Jeep with the Haulmark trailer, just before nearly crashing on I-15, Blackfoot, Idaho, March 2009.

This, of course, was the closer, as they say.  After a bit of dickering to maximize trade-in value to us and resale value to the dealership, we took a break while they checked our credit, stopping at home to unload 17 years of accumulated glovebox debris and remove the tandem rack, pretty much corroded in place after 17 years, then swing by the storage yard and pick up the other half of our trade-in package, the 7×16-foot covered trailer.

The downpour continued throughout the day, but we managed to switch vehicles on paper without too much further ado.  The rainy day turned to stormy night while we signed papers, so we dispensed with the usual walk-around checkout, and drove our newly-acquired debt home to RTFM (Read the Fine Manual).

Jeep2 "Green Hornet"

So, now we’re almost ready for our trip.  We need to get the Green Hornet into the shop for the add-ons, there’s still a quilt on the quilting machine, the wireless is still iffy, and the new PHP-based web site needs some last-minute revisions before being reassigned as the default on the client’s web site.  Chaos reigns supreme.

A TAXing Chore

2010 marked the first W2-free year for the residents of Chaos Central in more than 45 years.  No, we didn’t get laid off from $JOB like so many Americans: after dabbling for years in part-time consulting, we’ve taken the plunge and are now completely self-employed.  While we still have to wait until the end of January 2011 for the 1099 forms to trickle in, we do need to start estimating our taxes early, to make sure our quarterly payments track with the IRS’ estimate of what we should owe.  So, off to the wholesale club to pick up this year’s copy of Intuit’s Turbo Tax, which we’ve been using for the past ten years or so.

Chaos Central is a Unix shop (this is the Unix Curmudgeon’s blog, after all), and the development projects haven’t justified adding an Apple with OS/X to the stable of machines, so TurboTax and other Intuit products do present some problems for us.  For several years, we’ve maintained a Microsoft Windows system for the sole purpose of running TurboTax. Since the demise of our aging Windows installation (see our November post, “5640 Reasons to Not Use Windows” for the whole story), we’ve relied on Oracle’s VirtualBox virtualization application to run Quicken 2010 under a Windows XP license that came with a machine that has long since died.  We also have clone of the XP system that succumbed to a ClamWinAV bug, running under Citrix XenServer.

The system running under XenServer–thank goodness we ran the clone process as part of our evaluation of XenServer–was the one under which we’ve been running TurboTax, so it was a logical choice for this year’s version. Alas, the remote desktop capabilities of XenServer just weren’t up to the video calls that TurboTax uses (what the Unix Curmudgeon refers to as “stupid Microsoft tricks”), so we copied last year’s TurboTax files from that system to the system running under VirtualBox, and TurboTax installed just fine, and loaded our profiles from last year. In fact, it installed remotely, as the VirtualBox server is in the Realizations Fabric Arts studio, and the XenServer system is in the Information Engineering Services office, one floor up at Chaos Central.

Being too lazy to trot the TurboTax CD downstairs, the Unix Curmudgeon simply looked up the block device that the CD was mounted from (sr0), then ran ‘dd if=/dev/sr0’ piped to an SSH session that launched ‘dd of=Turbotax.iso’ on the VirtualBox server. Both XenServer and VirtualBox allow you to use ISO images as virtual CD/DVD drives, so there is really no reason to burn CD or DVDs from downloads to install virtual machines.

This is still a bit of a pain, as running Windows programs in this way requires you to actually run Windows itself. Worse, Windows is an unruly virtual machine, as it tends to gobble up as much CPU and memory resources as you assign to it.  Windows is also an unruly remote desktop server, as it doesn’t respond well to the remote mouse movements, resulting in much frustration, though the presentation on the VirtualBox server console itself is adequate. The virtualized XP installation on the XenServer is there now for the sole purpose of providing the XenCenter console. Citrix apparently intended XenServer to be used for virtualizing Windows Server instances, so the XenCenter, naturally, only runs on Windows.

Our preference, if we must run applications that are only available for Microsoft Windows, would be to run them under Wine, the WINdows Emulator, an Open Source tool that runs under Linux, that translates Windows system calls into Linux system calls.  Unfortunately, many applications rely on Microsoft intrinsic shared libraries (DLLs) or use so-called “undocumented” tricks to perform well under Windows, so they can’t readily be run under Wine, which is a feat of reverse engineering that dozens of Linux programmers who can’t give up their favorite Windows-based games or killer applications (like Adobe Photoshop) have devoted much time to getting to run under Wine, by trial and error.  TurboTax is one of those applications that, since it incorporates some direct memory accesses as part of the protection mechanism (an example of an Undocumented Stupid Microsoft Trick), just can’t be run in emulation easily.  But, since virtualization emulates the Windows hard drive, these tricks can be safely executed in the Unix environment without harm to the host or the client application realizing the disk sector it was writing to was simply a block of bytes in a file on a larger system.  The other trick is to successfully map Windows video tricks onto a virtual video card and then translate it into an image that can be displayed on an X Window system terminal.  Some applications that make extensive use of the Active-X protocol, of which Microsoft is so proud, render “active” regions in such emulations as blacked-out areas on the display.

So, you say, “Why don’t you Unix Curmudgeons just use Windows, as $DEITY intended?”  Because, dear reader, whereas the Microsoft Vision is “One user, One computer,” for us, in the words of the vision of the late, great Sun Microsystems (now part of Oracle), “The Network Is the Computer.”  The Windows user experience is limited by system settings for “desktop” or “server” priorities, while Unix systems can be fine-tuned to meet almost any unique computational environment, and the fundamental philosophy of Unix promotes equitable sharing of resources among hundreds of processes, which may be owned by many different users, with complete security.  On my screen at the moment are complete graphical desktop presentations from a half-dozen different computers running different versions of Linux, and individual applications running on those and other computers, from which I can cut and paste text as if they were all running locally.  This is a concept of which most Windows users cannot even conceive, even though the web browser, that universal window into the broader network, offers some of this capability. We grudgingly use Windows only for applications for which workable equivalents are not available in Unix, and will stop using it when they do become available for our preferred systems.