The onboard wireless on this thing is an ipw2100, hence only 802.11b, and I had a PCMCIA 802.11g NIC lying around (actually it came from the Lifebook, liberated from there after I bought it a Mini-PCI 802.11g card on eBay). On Gutsy, I used the hardware kill-switch to disable the onboard adapter to make double-sure that it wouldn’t try and drag the network down to 11Mbps.

This laptop was the last machine I upgraded to Hardy, and I was playing with KDE 4 on it so I was looking forward to seeing what KDE4-ness made it into Hardy. While the upgrade was taking place the wi-fi connection dropped out, but I didn’t think anything of it since Ubuntu upgrades try and restart the new versions of things and I figured NetworkManager had fallen and couldn’t get up. After the reboot, however, KNetworkManager (still the KDE3 version, don’t get me started there) could find no networks — could find no adapters, in fact.

I logged back into KDE3 and poked. Still no wireless (as if the desktop would make a difference, but I had to make *some* start on pruning the fault tree). The Hardware Drivers Manager was reporting that the Atheros driver was active (for the PCMCIA card), and an unplug-plug cycle generated all kinds of good kernel messages.

On a whim, I flicked the hardware kill-switch for the onboard wifi[1]. Almost instantly, KNetworkManager prompted to get my wallet unlocked — it had found my network and wanted the WPA passphrase. I provided it, and got a connection: via the PCMCIA NIC.

“That’s odd”, I thought, and flicked the switch. A few seconds passed, and the link dropped. Flicked the switch on, link came back. Flicked the switch off again: this time a few minutes went past, but again the link failed. Tried it several times again, and the same thing happened. The state of the kill-switch for the onboard NIC was influencing the other NIC too!

It seems that this is altered behaviour in NetworkManager, applying the state of the hardware switch to all wi-fi adapters. If it annoys me significantly I’d like to think I’ll trawl changelogs, or even better lodge something on Launchpad… more likely though I’ll forget all about it having found a kludgy workaround.

I’ve now added ipw2100 to the module blacklist and things work okay (presumably because the state of the onboard switch can’t be reported any more). I’ll also have a think about whether a few dollars for another g-capable Mini-PCI NIC will be throwing good money after bad, as this laptop really is quite long-in-the-tooth.

Oh yes, that’s right… KDE 4. Next time perhaps.

[1] I can’t think why I did this. I knew that I’d disabled 802.11b in my access point, to make triple-sure an 802.11b device wouldn’t slow my network down… The onboard 802.11b NIC would never successfully get a connection.

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…

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…