Spring Cleaning

Spring always seems to take forever to reach New England.  This is nothing new; I’m in agreement with a traditional mode of thinking here that there really isn’t a “Spring”, there is Winter and Summer, and in between “Mud Season”.

But there are cobwebs to be cleared, always.  Like those in the computer.

While I’m not speaking literally, consider the degradation of the state of our computers, or “bit rot”.  It represents a real phenomenon; the concept of entropy turns out to apply to ordered data in our storage systems and to our own organizational structures.

I’ve always followed the advice that I give to others: upgrade your software early and often.  I’m usually first out of the block for new OSs for my client machines (not servers – but that’s another story).  That’s rather extreme – I don’t suggest this for most people – but falling a few versions behind is a significant problem.

I get surprised at unintended consequences, though, as with how upgrading software feels like spring cleaning, but it’s not.  In fact, software upgrades generally leave as much as possible from the previous state as possible.  That’s prudent – you make fewer decisions about deleting things, you decrease risk.  But just because you moved in new furniture doesn’t mean you don’t have cobwebs that pop up.

You’re thinking that there’s a practical story here, and you’re right: whenever I take a machine and “clean it”, it ends up running faster.  Yes, more speedy.  Why?

It’s about ordering of data: if you back a computer up and then restore the backup – especially if you back up and reinstall the OS and the Applications from the original media, followed by only using your backup to restore your data – you’re moving everything back onto the computer into a state where you’ve gotten rid of all the old stuff that you never use anymore, and you’re writing from the beginning of your disk, one block right after another.  Which means that when you go to read the data, it’s all effectively faster to access because it’s been reorganized.

This used to be called “defragmentation”.  Most OSs do this automatically now, or don’t actually need what the defrag applications did, but what they do need is a external process (you) to make decisions about what is no longer needed, and have the computer clean off the disk and rebuild.  There’s nothing like doing the living room by moving all the stuff in there out and cleaning everything before moving the stuff back in – you’ll probably find stuff you don’t want to move anymore, but the real value is just getting to the bare floor and going from there.

I used to think that the slowing of computers primarily related to new software functionality, new web applications, and more intensive use.  I still believe that these are factors.  However, I’m constantly surprised about how much of an impact a full cleaning cycle has on my supposedly well-maintained machines, and take stock at how it’s good to simplify the environment from time to time.

Speaking of the (physical) living room…

Asterisk, Firewall, and Hearing Voices

From the “While I’m thinking about it” department, with help from the “maybe this will be useful for someone else” division.

I’d added a Analog Telephone Adaptor (ATA) to my home Asterisk system a while ago, but hadn’t really gotten a chance to work on it.  About six months ago, I realized that it was misconfigured: when I received calls (which was 95% of the use, as it turned out) audio was fine, but I couldn’t initiate calls with it and get audio.

I realized this because I hadn’t been using Asterisk as my sole voice service, and so cursory testing of the ATA didn’t expose the problem – calls to it on my own network worked fine, so I assumed initiating calls would, too.

I thought about all the Fun with NAT that we always have to deal with, and assumed that was the issue.  As is so often the case, ran off in that direction with no solution.  Looked at the configurations, and everything there looked okay.  Turned directmedia off, so that Asterisk would remain in the media stream, but still no audio.  On the other hand, this ruled out NAT issues, didn’t it?  And I’d never had NAT issues with Asterisk, even though I never actually modified the firewall on that host to open ports for RTP.

My Polycom IP550 (always) worked.  Great.  And the ATA didn’t.  Looking at the network traffic, I saw that call setup looked pretty similar between the two devices… but then I noticed something interesting, that the ATA would get “destination unreachable/host administratively prohibited” replies from Asterisk with RTP.

I dug deeper, and noticed that the first RTP packets when using the IP550 were from the Asterisk server to the IP550, while with the ATA the audio started with the ATA – but there were those unreachable rejects, and no audio at all the other direction.

Stop reading here if this starts to make sense to you – once I put this all together, I started to come up with the answer.

I never had to open the RTP ports on the Asterisk server, because it turns out the IP550 was configured with progressinband=yes.  (There was a note in my config that this was suggested by Polycom).  Because I hadn’t really looked into it (and it was only suggested by Polycom), I never thought too much about it.  But it’s the key, when running Asterisk on a host with a firewall: rather than having to adjust the firewall to manually open ports for RTP, progressinband has Asterisk generate audio to indicate call progress back to the terminal, which means that the Asterisk server “talks first” (starts sending from the negotiated port using RTP).  This means that Asterisk effectively opens the port for RTP bidirectional traffic, and thus obviates the need for the firewall to do so.

It had nothing to do with NAT, but was still a firewall issue.  I run firewalls on internal hosts – I think it’s just good practice.  And I have to be honest: I figured all this out because when I did open ports for RTP, the ATA started working.  That was what I needed to know to figure out the rest of it.

I haven’t yet figured out the drawbacks, if any, to progressinband, but in this case I’m happy to be through this particular issue.  This is one of those occasions where a lot of work – many blind alleys – led, eventually to a fix that’s brilliantly obvious once you know it.  That’s how life is in technology, though.

Happy IPv6 Launch Day!

World IPv6 Launch Banner

IPv6 Launch Day – 06Jun12 00:00 UTC

My background may or not be all that unusual: I’ve picked up lots of things that I didn’t set out to learn; responding to topical areas that my employers wanted me to learn or following what I thought was interesting and what I was attracted to – that’s created somewhat of a patchwork of areas of knowledge.

One thing that’s been difficult, sometimes, is forcing my attention away from whatever is on fire today and learning new stuff.  As I’ve mentioned recently, I have had some great opportunities to get taken in different directions.

Here’s one: about two years ago, at a BBLISA talk, I finally got to learn about this amorphous thing off in the distance, IPv6.  Like a lot of technology, getting your arms around a new concept is trying partly because most education seems to be oriented towards those who are learning something wholly new for the very first time, as in how TCP/IP works.

This is what BBLISA is really great for: I know lots about the “current” IP already (“IPv4”); assume that I understand the protocol stack and how lots of services are implemented on it, please, and explain to me what is different and new.  That was an excellent session.

So, I put together IPv6 connectivity on and out of my home network, to the IPv6 Internet.  Last year, as World IPv6 Day approached, I decided that I wanted my externally-hosted personal site available on IPv6, too, so I set up a mirror with a new provider… this year, the whole site has been moved, including my mailhost (Dovecot/Postfix).  All that’s left is Amazon Web Services – (going to be making any announcements soon, AWS?) – which hosts some content (like images and large file downloads such as from my BBLISA presentation).

As of now, 06Jun12 00:00 UTC – it’s Launch day.  Today, the sites listed in the Launch site are supposed to be fully IPv6-enabled, and as they say “This time it is for real”.  I’m happy to be part of this.

iPad Time

What do you know, I’m actually on the vanguard for once.

I skipped the first generation of the iPad because “circumstances” were not propitious for the investment in an unknown technology.  Or, to put it another way, I simply didn’t have a way to justify the cost… with uncertain “benefit” to counter $500-$800 in outlay.

(Compare and contrast with my my lack of an iPhone – mostly a result of my strong dislike of at&t and its predecessors – although not of course helped by the costs for the device and the required data plans.)

But having passed up the iPhone, I did decide that the second-gen iPad was a worthwhile investment.  Made a bit easier by paying with our 21st century equivalent of S&H Green Stamps, credit card points.

So, I admit to scheduling a trip down to the Back Bay on 11 March, the day of the unveiling, and I don’t have to describe for anyone the sheepish “late to the party” feeling of seeing the lines down Boylston Street block, the a block of Fairfield, and then a significant remaining queue down Newbury.  Okay, yes, I didn’t get there for almost a full hour since the lines opened, but still…

As my friend Linda might have put it, “dontcha want it just a bit too much?”.  She would, of course, be correct.  But I had to do something

Here’s the question I asked (ignorant, of course, as to how constrained the supply would be, even weeks later): how long am I willing to stand in line for this?  Seriously, though I thought at the time the choice was only between waiting a few more days, if I wanted one more quickly was I willing to wait?  And if so, what would be the best strategy?

Here is what I decided: I would be willing to experience the delight of cooling my heels for 90 minutes, but no more.  After all, I’d never been at an Apple launch before… but given what I saw that Friday, I suspected that any Saturday line would be seriously longer than that hour and a half.

The optimization I arrived at was that I would spend that 90 minutes waiting for the store to open Saturday morning.  I would get there at 0830 for the 1000 opening; if the line then seemed to me to be more than minimal I would just forego the thrill.  (I did make one adjustment: normally I would never drive downtown, but I realized that with a 20 minute investment in an easy drive I could cut my losses if there turned out to be a raving horde.)

There was no horde.  I got there a bit earlier than planned (because of the drive vs. the T), and found myself #15 in line.

It turned out to be exactly two hours to wait and then complete the transaction, getting just in under the parking meter.  Good strategy – and pretty happy customer.  I’m not usually the guy with the newest, shiniest kit, but for once it’s nice to be there.