Posts Tagged linksys

When Upgrades Go Wrong

I’m running Debian on a Linksys NSLU2 storage device, and it works really well in general. So well in fact that a lot of the time I forget the thing is even there! It’s sitting in the garage minding its own business, serving out video and music files, and storing backups of the other systems in the house. Just occasionally, however, the thought pops into my head to run a system update over it — a habit I’ve gotten into for the Gentoo systems in the house, but “the Slug” usually misses out. About a fortnight ago however I decided to do the “apt-get shuffle”. Timing, as they say in sport and comedy, is everything.

I’ve become fairly complacent about system updates. All the distros I use now have got excellent tools for keeping everything up-to-date, and for making sure that things don’t go wrong in the process. It’s all just software, however, and it’s all too easy for something to get missed or for a bug to creep in. One such bug that did exactly that is this one. Unreported at the time I did my update, it rendered my Slug unbootable after the update I gave it.

It took me a day to realise that the Slug was off the network. The failure of the nightly backups was my first clue. Next was the inability to stream any of the media files stored on it. For the next week, on-and-off, I tried a dozen things in an attempt to get it working again. I finally arrived at a process that used the Debian Installer firmware image as a way to get a running system onto the device, allowing me to then access the hard disk and try and reflash earlier kernel and initrd images to it.

I started trying to work on the boot disk, but I couldn’t see it for some reason. Then I discovered that the power supply of the USB2 disk enclosure that holds it was playing up! Now, I had two problems–was one related to the other? Was my boot problem just a hard disk problem all along? Turns out that the power supply failure was a coincidence–replacing the power supply got the disk working again but made no improvement in the bootup scenario.

The NSLU2 boots differently to a PC. On a PC, the BIOS locates some boot code on a storage device and executes that, which usually is a program like LILO or GRUB that has more intelligence and (in the case of GRUB) a way to interact with it. These boot loader programs then load in the kernel and start executing it. With the NSLU2, however, the kernel and the “initial root device” are written into the flash memory of the device–they more-or-less are the BIOS.

On a PC, if there’s a problem with the kernel or initrd you can generally select another one from a list. Worst-case would have you installing the hard-disk in a different PC and fixing the problem from there. On a NSLU2, however, any problem with the kernel or initrd can’t be fixed by changing the hard disk because the kernel and initrd aren’t read from the hard disk but from the flash memory instead. There’s also no option for selecting another kernel, since the NSLU2 is a “headless” device with no console (besides, there’d be no room in the flash memory for two copies of kernel and initrd).

Once I’d been able to get my Slug booting (by writing out a previous version of a kernel and initrd) I was going to leave it alone… but curiosity got the better of me. I’d suspected a bad update to the utility that generates the initrd, and sure enough an “apt-get update && apt-get upgrade” revealed a pending update to the initramfs-tools package. Google led me then to the above bug report. With fingers crossed I did the update, reflashed, and rebooted… successfully!

The Slug is now back in its usual place, quietly going about its business of entertaining us and keeping critical data safe. I might at least think twice before doing a kernel update on the poor beast in future though!

Tags: , , , ,

WIP330 progress: it’s a… phone

A while back I posted about my grief with the Linksys WIP330 WiFi SIP phone (it doesn’t happen often, but it’s a surprise when the ONLY hit you get on Google about a problem is your own blog post discussing it).  The unit is still a bitter disappointment, but thanks to a firmware update it seems like it’s finally at least usable on my network.

My previous post talked about problems I was having with the network connection dropping out after an hour on a WPA-PSK network.  When last I checked, the most recent firmware was no improvement in that regard.  However, I checked again last week and a couple of new updates to firmware have been released.  You need to go to Linksys’ US site to download the recent firmware though (Australia only has the 1.02.12S version that is a problem for me, while 1.03.18S is on the US site).

I also had problems using the phone menus to do the upgrade.  The WIP330 has a menu selection that lets you enter a URL for the phone to download its own firmware update, but this didn’t work for me.  I suspect it’s because the Linksys site that the firmware is hosted on is using an expired SSL certificate…  Downloading the file to my desktop and uploading the firmware through the phone’s web page worked fine as an alternative method.

The phone has been on my WPA network all day continuously now, and it makes and receives calls without drama.  I’ve never had the problem that some folks report where the phone ignores incoming calls.  So, as a phone, it’s functional and I’ll be including it in my ring groups and queues now.  As a Wi-Fi device, though, it’s still short.  For something that’s supposedly built on Windows CE, there’s precious little PDA or network function in it.

The two things I thought I could do with the unit (other than just use it as a phone) have both come up busted.  First was to use the “web cam” function to grab rain radar images from the Bureau of Meteorology — but the function only seems to work with actual web cams that generate a Windows Media stream, and not just an image that refreshes at intervals.  Next, when I found that you can use the web interface to upload and download data such as the phonebook, I thought I could write something that dumped my LDAP contact database into the right format to upload to it.  I still could, if I could hack the crappy VB/.NET encrypted file format they use on it.  Bah, humbug.

There’s talk on the ‘Net about folks who load CE device drivers and play with it from Windows, so maybe if I was a Windows user there would be more I could do with it.

One thing I will do with it is try it on public Wi-Fi.  That’s the only differentiator I can see between it and a normal cordless phone attached to an ATA — you certainly shouldn’t buy one of these just to use at home.  If it’s fairly easy to strap up to public Wi-Fi then it becomes much more useful (but then I have to wonder how often I’m near public Wi-Fi and needing to make a call I couldn’t make on a normal mobile… it might have been useful when I was stuck in Melbourne airport for three hours the other week though).

Now that it stays on the network I can use it as a phone.  Fine.  I still regret not knowing in advance about the iPod touch, because I would rather have put that money toward the touch…

Tags: , , , , ,

Linksys WIP330 – another tale of hardware woe

I was on eBay not long ago and happened across a listing for the WIP330 (big brother to the WIP300) for much less than local retail.  I decided to take advantage of: a) the good price, b) the current strong position of the A$ versus the US$, and c) it was within 1 hour of closing and the vendor was giving 10% off…  and bought it.  I honestly should not have bothered: this is a terrible piece of equipment, and now sits beside my bricked Cisco 7970 as the worst online auction purchase I’ve made.  But first, a little history…

Some time ago I saw some reports of Linksys releasing a couple of Wi-Fi VoIP handsets.  Reviews looked moderately promising, but as one of the devices (the “prestige” version) was based on Windows CE I was disappointed in the lost potential of the device.  But then I saw that eBay listing, and I jumped immediately into Gadget Acquisition Syndrome justification mode.  “Sure, it’s based on Windows CE, but haven’t you always told people that you believe in horses-for-courses?” said my inner gadget-junkie.

So about a fortnight later the thing arrived.  I charged it for a decent amount of time, then configured it for my wireless.

“Failed to connect”.

Google then revealed a litany of people being driven crazy by this device’s inability to connect to a WPA-PSK network.  At this point I began to feel very much like Stuart Langridge of LugRadio fame, who only discovered after buying a new laptop that his research had failed him and he had indeed bought a laptop of “military-grade proprietariness” (as I seem to recall one of his fellow LugRadio presenters described it).  Had I known that in 2007 a manufacturer of networking equipment (backed by probably the biggest name in corporate and Internet networking today) could release a device that would not connect to a secure network created by THEIR OWN BRAND OF ACCESS POINT (a Linksys WRT54GS[1]), I might have researched that issue further.

Some hope was provided in the form of a firmware update.  Unfortunately, like most pieces of networking kit, firmware updates are delivered over the network…  In this case, the thing couldn’t connect to the network!  I had to shut off encryption on my network for the length of time it took to perform the update — which was doubled by the fact that the firmware on my unit required an interim upgrade to a staging release before the final update (to wip330_v1_02_12S) could be applied.

So with firmware upgraded and encryption re-enabled on my wireless, I tried again…

Same error.

At this point I was very keen to follow this advice and eject the rotten device from my life, but on that page I found the hint that got things working: my access point had AES as well as TKIP enabled, and the WIP330 seems to choke on AES.  Disabling AES on the access point finally got the WIP330 on the network.  At this point my son wanted to watch something via XBMC, and I found that the client Wi-Fi device through which his XBox attaches still had AES defined so could not connect to the network…  Turn AES back on, get the other device attached again, disable AES in it, disable AES in the access point again, and I was set.

Or so I thought.  Later in the day, the WIP330 was off the network again.  Trying to re-connect to my network brought failure, but power-cycling the device got it online again.  Sure enough though, an hour later it was off the network.

One hour.  3600 seconds.  The (default) rekeying interval of a WPA-PSK network.  The chuffing thing fails to complete rekeying and drops the wireless connection.  This time Google has been no help — I guess not enough people persisted through the AES problem to have the thing on the network long enough to hit the rekeying failure.

So right now the thing is useless to me.  I’m even contemplating dragging out my old 802.11b access point for the phone (and another couple of old WPA-incapable devices) to run on, but I think the last thing my neighbourhood needs is another 2.4GHz wireless network.

To try and balance this, I will mention a couple of things I like about it.  While it was on the network, it was easy to connect to Asterisk and get talking.  The device is light (bordering on too light) and the screen is just brilliant.  Sound quality was a bit dodgy, but then I haven’t had a chance to use it for long enough to know for sure (and then I was only talking to myself via the Asterisk echo test application).  One other thing that’s nice is that Windows CE is largely hidden.  There is a browser on the device, which uses the Windows flag as its progress spinner, but other than that it’s out of the way and not screaming “look at me, i’m CE”.

Like I said, however, the fact that in 2007 Linksys can release a device that has such problems just getting connected to a network is a great disappointment.  At this stage I think the best that can come of this device is that enough bad press is spread that they don’t sell at their RRP, forcing the price down and making it affordable enough for some crafty Linux hackers who could put an Open firmware on it.  Or, hope against hope, perhaps Linksys will see their channel back-up with units that won’t move, and switch to a Linux firmware themselves to get them going.

In the meantime, I’ll keep Googling for “wip300 wpa-psk piece of junk”…

[1] To be fair, my WRT54GS is running OpenWRT and not the stock Linksys firmware.  But the binary that provides WPA-PSK in OpenWRT does come straight from Linksys’ firmware…

Tags: , , ,