Howdy!

Just a quick update to keep the masses apprised of some developments.  Not that they’re particularly interesting to the masses, and not like there are really any masses to speak of…. but whatever…

So for a Long Time(tm) I’ve been running Wireless-B at home.  Yes, laughable.  Truthfully I never really had a compelling need to opt for the higher throughput of Wireless-G and above.  That, and my Cisco Aironet access point offered some nice SNMP stats that may not have been available in consumer-level AP’s.  Being able to glance at graphs of client associations and wireless throughput turned out to be a great way of making sure that the network was being utilized as intended.

However… I was never comfortable with the fact that wireless isn’t as inherently secure as a wired network.  Best practices dictate that you should segment your wired and wireless networks.  There have been advances in wireless security – WPA, WPA2 – which make this less of a requirement relative to WEP, but the fact is that I didn’t have any WPA-capable hardware and I didn’t have a good way of segmenting my LAN to adequately isolate wireless clients.

Sooo… a couple of things happened.  One, is that I’m now running a Cisco router with DMZ capability.  Two, is that I’ve now got a Cisco Wireless-G router with WPA2 support.  Great – the Wireless-G AP was dropped in in place of the Wireless-B AP and now I’m sporting higher speeds and, more importantly, the latest in wireless security.

Unfortunately I’ve got some older devices that only support Wireless-B and WEP.  Mostly PDAs that are serving as music streaming clients on the Whole Home Audio system.  Those devices would have to run on a different wireless network, as I didn’t want B clients degrading the speed of my G network nor did I want to run a broken security technology on my main network.

And finally, given that WEP can be cracked, I surely didn’t want to bridge the Wireless-B network off of my main LAN, thereby exposing my entire network to a determined hacker – or lucky script kiddie.

So the old Wireless-B AP is hanging off the DMZ port on the router, and a very limited number of ports are allowed to come in from that DMZ.  Perfect – a firewall seperating my trusted wired/wireless-G network from my less-trusted Wireless-B network.  I can also use the Wireless-B network for guest devices, like work laptops, since I’ve granted Internet access to that network.  There’s still MAC authorization and the WEP key to enter, so it’s not a wide-open free-for-all.  And if there was some amount of unusual activity on that network it would be easy enough to spot since – as I said above – I can graph client associations and wireless throughput.

So that’s that.

In actual fact I’ve got three network technologies running: wired, wireless and powerline.  The powerline stuff was put in to support my multifunction printer, which I wanted to be able to put upstairs somewhere where it would be most useful.

Well, powerline worked great for a while, but the past two months or so it’s been unusable.  Why?  Dunno – I don’t recall plugging in any new applianaces that may have introduced noise on my little power grid.  Perhaps the neighbours did, perhaps one of the powerline bridges melted a resistor, no clue.  But it was no longer a viable solution.

So, I recently acquired a Linksys wireless bridge to full in for the powerline adapter’s intended role.  Cool – another Wireless-G client with WPA2.  It works, although it’s running at 2.0Mbps… I’ll play with antenna orientation and what-not at some later date.

So what else now… oh yes, something else that has been misbehaving of late is the Whole Home Audio system itself.  Specifically, it’s Girder’s HTTP server that decides to go off in la-la land for seconds or minutes at a time.  This may not be such an issue if it weren’t for 1) linked lists, and (2) near-realtime zone info in the frontend.

Right – linked lists need working communication from the player (WinAMP) to the main HTTP RPC instance on the home server, to the RPC calls off the home audio HTTP instance, then back to the HTTP server off Girder.  This is the case because, in essence, the player tells the system that it’s done playing a track and the system tells the player to play the next track – which is in contrast to loading a list into the player and telling it to play the whole thing (ie, the list is not linked to the system).

When the Girder HTTP server fails, we have no way of telling Girder to have the player load/play the next track.  So playback stops.  And because this is all HTTP based, the requests eventually time out and playback never resumes.

Now, I spent some time and coded some ways to recover from this situation gracefully (ie, handling the timeout and reporting a problem to the user or logging to a file), but restarting playback requires human intervention – for a number of practical and technical reasons that I won’t go into right now.  I even got to ditch an ActiveX object I was using to do HTTP requests and replaced it instead with Microsoft’s own XMLHttpRequest object.  It seems more robust, so that’s a plus.

But ultimately the problem is with Girder.  If an HTTP server fails, it’s a problem, plain and simple.

I entertained upgrading to Girder 5 (from Girder 4), going so far as to download the trial and run it to be sure my LUA code and Girder events would still work – and they seem to – but in the midst of being uncomfortable with spending money to get nothing more than stability I happened to stumble across the fact that my version of Girder was 4.0.1 while the last release in the version 4 train was 4.0.15.  So I grabbed that, cleaned up some LUA that didn’t want to work anymore due to semantics (could that have been a contributing factor to the problems I was experiencing?!?) and put 4.0.15 to work.

So far it’s been rock solid, knock on wood (yes, I just knocked on my desk).

Of note is that I accidentally left my work computer connected to the home network last night, sitting on a zone page – meaning it was querying Girder from closing yesterday to opening today.  Normally that would send Girder’s HTTP server into crazy land, but it’s still functioning normally today.

So I’ll keep my virtual fingers crossed.  Another plus in all this is that my Win32 service is now running grunt.exe vs. girder.exe – grunt being the Girder RUNTime that Promixis included in the distribution sometime after 4.0.1, which does all the cool Girder stuff without launching a UI.  Perfect, since a Win32 service doesn’t really need (or want) a UI.

So that’s it for this update.  Next time I’ll talk about a cool “app” I’m running on my phone to track my quality of sleep.