Posts Tagged voip

Upgrading from Cisco

In case you weren’t aware, I am a VoIP nutcase.  I have an Asterisk phone system at home, and all the phones in the house are VoIP of some description (either real VoIP devices or analogue handsets through an ATA).  While I haven’t converted to VoIP as a replacement for PSTN, I have some connectivity to VoIP providers both here and overseas (and soon to be more, to help the phone-home situation while I’m overseas).

I’ve been a user of Cisco IP phones, buying 7960s and a couple of 7970s through a well-known internet site (maybe it starts with an “e”, not sure).  The phones have been excellent, and I’ve even written a few XML apps to supplement their use here.  The 7960s are getting a bit dated now, however, and I found myself contemplating buying 7971s (or even something newer, like the 7965 or 7975).  Before I committed myself further into the relationship with Cisco, though, I thought about what I was really getting out of using Cisco phones.

Like many users of second-hand Cisco gear, I only purchased the hardware.  I do occasionally succumb to a nagging feeling of being an “outlaw” (at least in the eyes of Cisco), but admittedly that feeling usually only comes when I find out that Cisco has released another new version of SIP software that I can’t get because I haven’t paid for SmartNet.  The last time I had this thought though, I had a realisation: even if I did pay for SmartNet, the only thing I’d get would be the firmware: Cisco will only support their phone software when connected to their CallManager server (yes, even the SIP firmware).  Anyone running Cisco phones against anything other than CUCM gets no support from Cisco in the event something doesn’t work–and based on the information floating around, the problems are many.

So basically I would be paying Cisco to allow me to run one of the worst SIP implementations in embedded existence, with no opportunity to report problems with it in my environment.  Hmm, let me think about that for a minute…

At around the same time, I happened across the NerdVittles site, and in particular the post where NerdUno nominated the Aastra 57i as the “World’s Best Asterisk Phone“.  I started to do some research into it, and was astounded at the level of support the manufacturer (a Canadian company which a few years ago acquired the telephony business of a little mob called Nortel) and the community provide for this phone and Asterisk.  Looking through the phone manual, I found functions that only work with Asterisk! I found a full set of integration scripts that provide XML applications, right through to automatic provisioning tools.  Possibly the best thing was that on the product page for their phones — right there on the page that descibes the product — are links to current versions of firmware, documentation, XML application development guides, even a Linux-based application to encrypt the phone configuration files.  Not hidden in some obscure hard-to-find portal, or behind a registration-only support site.

I started to think of the possibilities…  I’d be able to freely modify the phone configuration (even via a HTTP interface if I so chose), without having to make trial-and-error changes to a cryptic and totally undocumented configuration file.  I’d be able to write XML apps without having to do laborious debugging to cater for why the parser was choking on XML that was perfectly okay according to the documentation but apparently tripped over an undocumented field length restriction or character encoding limitation.  I could get access to things like Visual Voicemail, BLF, integration with Asterisk functions like day/night mode and call parking.  I could keep the phones up-to-date for new functions and bug fixes.  With a click of a mouse I could get proper Australian tones!

So, I decided to give one a try.  Finding nothing on that “e” site I went looking for a vendor locally, and found several places that would sell one to me (legitimate e-tailers, no less!  Zounds!  A VoIP phone with a warranty?  You jest!).  It took a while for my chosen vendor to source it for me, but I’ve had it now for a couple of weeks.  It’s probably going to take a while for it to live up to it’s full potential in my installation, but since that potential is so much greater than what I have been able to do with the Ciscos I think I’m already ahead.

More in the coming weeks as the Aastra settles in.

Tags: , , , , ,

Nokia SIP client: WTF?

I was having a browse around the excellent Nerd Vittles site tonight, and stumbled onto a disturbing conversation about the removal of the Nokia SIP client from S60 Third Edition Feature Pack 2 (as used on recent phones like the N78 and N96).

Nerd Vittles linked to this blog, which alludes to the possibility of mobile carriers putting pressure on Nokia to remove “free” calling capability (i.e. VoIP) from their phones.  Within the comments on that blog post comes a link to a post on Nokia Conversations (I’ve never seen that site before, but it seems to simply be a bit of a PR site…).

“Charlie” from Nokia Conversations tries to spin the changes to Nokia’s SIP support.  Firstly, in what seems to be almost believable at first he says “no, the SIP stack is still there, in fact it is actually better in FP2 than previous versions”.  Apparently, the improvements meant that the integrated VoIP client had to be dropped because it wasn’t ready.  This explanation loses credibility, however, when you see that Charlie’s blog post was made on 27 August 2008: nearly one year ago! And folks are still commenting on that thread, saying “where’s my VoIP client?”.  I cannot believe that it would take Nokia a full year to update the VoIP client and package a firmware update for these phones–especially given that two other S60 3rd-ed FP2 phones released after the N78 and N96, namely the N79 and N85, apparently do have the VoIP client!

On 8 December 2008, Charlie posts a follow-up on Nokia Conversations.  In it he says “well we made some folks unhappy, but we’ve made a fix”.  He points to something called the “SIP VoIP Settings” application that was supposed to bring back what people were asking for.  Problem is, it’s not a VoIP client at all: it’s simply a configuration tool allowing more detailed control over the configuration of a SIP profile.

In the final insult it appears that the new N97, Nokia’s current flagship also has no VoIP client.  The N97 is based on S60 5th edition and not 3rd edition, but 5th is supposedly just 3rd updated for touch-screen anyway (not a significant change in technology).

Looking more closely at the specifications pages for these N-series phones, the tiny-tiny text that says “VoIP” is missing.  It’s probably arguable therefore that Nokia never advertised the phones as having VoIP capability[1], so anyone who bought one without checking has created their own situation.  However, Nokia, why is the “upgrade” to the N95 missing one of that phone’s most popular features?

At one point Nokia’s story changes… it seems that VoIP is a function that doesn’t fit the product direction of N-series and belongs in the E-series phones (indeed both the E75 and the soon-to-be-released E72, reportedly S60 3rd-ed FP2 phones, list VoIP capability).  Why, then, do other S60 3rd-ed FP2 phones like the N79 and N85 have VoIP?

This whole “affair” seems to have been handled really poorly by Nokia.  Firstly, claim a technical limitation.  When that fails (because you discover that your users actually know something about tech), claim that your third-party providers have developed a solution.  When it turns out that the third-party products are steamers that don’t even use the infrastructure your OS provides (something you didn’t know before either), claim that the product has been “realigned” and doesn’t service that market any more–while simultaneously marketing a product in the same series with the same technology that still has the disputed feature.

I must admit to being a lot less angry about this after researching this post than when I started it.  I’m more angry about the survey I completed earlier today when I visited the Nokia website–I was very complimentary about .  My shopping-slash-wish list just lost an item–not that I was seriously contemplating buying the N97, but it’s nice to have a technical reason not to buy it rather than the boring can’t-really-justify-it line. 🙂

[1] Of course it’s easy to make this statement based on what the product pages look like now

Tags: , , ,

FreePBX device-and-user mode, part two

In part one, I described how I reconsidered device-and-user mode in FreePBX, and did the initial changeover.  Read on to find out how I overcame a major issue with the configuration!

I have an ISDN phone line coming into my Asterisk system.  One of the indials is for our home number, the other is one I use for work.  Before I found FreePBX, I had manually worked the Asterisk dialplan to have calls made from my work phone(s) appear from the work phone number–useful not just for Caller-ID, but also required for the long-distance provider I use to bill calls for work.  With FreePBX I was able to use a custom context to pre-select a route that dialled the provider override prefix to send the calls through the other provider, but it was a bit of a hack using hand-written dialplan code and a bit of luck.

Before I changed to device-and-user, I naively assumed that FreePBX would allow a user to be associated with a context in the same way a device/extension can be.  This is not the case, and the context of the device is still used for routing.  This meant that I could not use a device for either work or personal calls without having to log onto FreePBX and change the device context (logging on as the work user was not enough).  I was back to square one…

I did a little research.  Firstly, I rediscovered how I was making the existing routing work.  The ISDN interface I use (driven by chan_capi in Asterisk) simply uses the outgoing caller-id of the call to select from available MSNs[1].  So I had one route that had the “normal” MSN set as the outbound caller-id, another route with the “work” MSN (plus the rewrites to add the long-distance override code at the front), and a custom context for the work devices that made only the route with the work MSN available.

Looking more closely at the user definition page, I saw that there is an “Outgoing Caller-ID” field.  By using this field, I was able to do away with the separate route and the custom context and set the work MSN there instead.  This gives me just what I need: a way to control my outbound MSN on a per-user basis!  This got me half-way there, as I still needed a way to set the long-distance override codes for work calls.  A bit more research turned up a predialling macro hook that the FreePBX folks made available.  With a bit of code to test the caller-id and the number dialled (the long distance company doesn’t handle free calls, for instance) I get just what I need.

Here’s the macro hook (this is added to extensions_custom.conf):

exten => s,1,NoOp(Trunk is ${OUT_${DIAL_TRUNK}}, CallerID ${CALLERID(num)} calling ${OUTNUM} )
exten => s,n,GotoIf($["${CALLERID(num)}" != "xxxxxxxxx"]?endit)
exten => s,n,GotoIf($["${OUT_${DIAL_TRUNK}:4:11}" != "CAPI/contr1"]?endit)
exten => s,n,GotoIf($["${OUTNUM}:0:4}" = "1800"]?endit)
exten => s,n,Set(OUTNUM=1xxx${OUTNUM})
exten => s,n(endit),MacroExit()

So I’m now a happy device-and-user user!

[1] Actually I don’t know if that’s chan_capi doing it for me or whether it’s just the way the ISDN network works.

Tags: , , , ,

Revisiting device-and-user mode in FreePBX

Buoyed by the success of a colleague I introduced to Asterisk and FreePBX a little while ago, I decided to have another look at the extension configuration mode I use on our system.

Check this post for a recap of the FreePBX configuration modes and my first thoughts.

Last time I looked at this I thought there were some problems with the way it was implemented that meant it didn’t work for my installation, so I ended up hacking together a mess of fake extensions, ring groups and queues that more-or-less reimplemented the good parts of device-and-user mode and still letting me use things from extensions mode.  Doing this however meant that FreePBX always complained about what it called “invalid destinations”, and I had to use some custom logic for doing something simple like a common voicemail access number.

What won me over to device-and-user mode again though was the ability to log a device on and off from a number.  I have a couple of Nokia handsets that have SIP clients now, and it’s handy to just have one device that all my work calls (for example) arrive on.  After-hours though, I didn’t want that device to still be tied up to the work line; it made more sense to be able to use that device for home calls.  To do that with extensions mode and my ring-group hack would mean reprogramming the ring-group (and one other change, which I’ll talk about later) when I wanted to switch over.  Presumably I could write some script or AGI logic that I could tie to a feature code in FreePBX, but I’d simply be making more custom modifications for little real gain.

In the end, I realised that the main thing keeping me in extensions mode–the ability to call a device by it’s “extension” number regardless of who’s logged on to it–wasn’t something I used often enough to warrant all the work I’d have to do to make extensions mode do what I needed.  With that in mind, I edited amportal.conf and made the all-important change:


I had to reload the FreePBX admin page a couple of times, but eventually the “Extensions” tab changed into two tabs, “Devices” and “Users”.  True to the description of extension and device-and-user modes given in the FreePBX doco, the Devices and Users tabs had the same number of entries.  All I needed to do was delete the users that were no longer required (i.e. almost all of them) and the devices that belonged to the voicemail extensions from my original setup.  I then ran through each of the device definitions and correctly assigned them as either “Fixed” (statically allocated to a user) or “Ad-Hoc” (able to be logged on to a user).

This was the point at which I worked out a solution to my original dial-a-device-directly problem.  I realised that the majority of times I need that functionality is when testing.  So, for those devices that I use for testing, I left the user definition in place and made it the “default” user for that device.  This means that when I log out of the real user from that device it is reachable by the default user number, and I can dial it directly for testing.  The other use for direct-connection to a device, the intercom, requires a separate SIP endpoint anyway (due to the Cisco phones not adhering to the SIP command for remote off-hook) so I need to keep those as separate users too.

I’m quite happy with how it’s turned out–at least, I was once I’d overcome the showstopper I found!  Read about that in part two.

Tags: , , , , ,

Cisco XML apps: things made of fail

Since I have a few Cisco phones around here, I’ve played with XML apps. I have written a timezone calculator, an LDAP phone directory lookup utility (which hooks into the “external directory” function of the phones), an app that uses Qantas’ WAP interface to get flight arrival/departure information, and the obligatory RSS reader. They work, in some cases very well, but the inconsistency of the XML interface between different levels of the Cisco firmware makes it a trying exercise.

My latest exercise was an update to the RSS reader I’ve used for ages. I found RSS2Cisco ages ago and have used it quite successfully, but I’ve never really been satisfied with its way of displaying the whole feed in one text page. It works well for news feeds, where all you get is a headline and a teaser, but for things like blogs it’s not suitable (you’re lucky to get through one posting before hitting the limit of a Cisco XML text page). I wanted an interface like a “normal” RSS reader, where it lists the items in the feed in a menu and you then choose an item to be displayed.

Sounded simple, and wasn’t too hard to hack rss2cisco around to make it do my bidding (it’s not optimal yet as every time you read an item it pulls down the entire feed again). The problem I faced was in making the thing work consistently between the 7960 phones and the 7970s.

All my phones are running fairly recent SIP code, but for some reason the 7960 has an ancient XML parser. By ancient, I mean that the level of the XML SDK it supports is tied back to Call Manager 3.0. The 7970s, on the other hand, have support for a much more recent SDK and support some of the fancy operations that you can’t do on a 7960 unless you’re running SCCP firmware. At first I thought that there might have been a hardware limitation and that Cisco couldn’t fit the extra smarts of a client for later SDKs, but the SCCP code can’t be that much simpler than SIP that they’d have more room to fit a better XML browser and all the other features the SCCP code has over SIP…

So the SIP firmware for 7960 has a junk XML browser. You’d think, then, that the 7970 was easier to work with than the 7960… Wrong! Valid XML that worked quite happily on the 7960 would fail with a cryptic “XML Error[4]: Parse Error” message. It took quite a bit of time and quite a bit of trial-and-error to work out some of the dependencies (32 seems to be a magic number, folks…).

Call Manager XML (CMXML) is supposed to be really simple, but I can only imagine how complex it might get to deliver an app with a consistent interface if you had a number of different phone models to support — I have only two, and I’m looking at two different versions of my app!

In their defence, Cisco have provided a way for the phone to identify itself and its SDK level when it makes a request. A set of HTTP headers identify the device, and one specifically states the SDK version supported by the phone client. Reading these headers would allow a developer to adjust the output of their app to cater for the various phones — one app, but multiple output capabilities.

It strikes me though as a heck of a lot of work for limited return. These are phones intended for corporate installations, so it’s almost a given that there will be a full-function computer at the same desk. Why would a company invest that much effort developing and supporting an internal application for a single platform that’s tied to desks, when they could write it as a web app and deliver it practically anywhere? I’m starting to see why the Internet is not exactly awash with sites selling CMXML apps…

Having said that though, I love my timezone calculator. With three button presses I can find out the time in any of my six favourite timezones, and I can find any timezone in the world with only a few more presses. An application somewhere on the web couldn’t be anywhere near that speedy for me, and a desktop app would have to be some kind of widget already running and configured (or be the KDE Clock applet, all it takes is a mouseover… shame I’m stuck with GNOME for my work desktop).

So I’m not too keen to apply much development effort to my XML apps. I will stick them on my development site some time soon, but I don’t think it’s worth the effort to keep them functional. The Qantas one, for instance, is totally dependent on the URL and query format of the Qantas WAP application, which is obviously subject to change at any time. I wonder sometimes if a WAP-XML gateway would be useful, but then I think about the effort of writing a system to translate pages delivered over a dying protocol to an interface that never got off the ground…

In case you’re curious what the RSS reader looks like:

and something a bit more voluminous from my blog:

Yes, I am a bit proud of it, even though it’s rubbish… 😉

Tags: , , ,

PoE again: this time, success!

I had pretty much forgotten about improving on the Power over Ethernet progress I mentioned previously. A couple of weeks ago I bought another 7970 that I successfully converted to SIP to run in the study, and I was considering buying a few 7961s or Linksys PoE-capable phones to use in other places. However, I got an e-mail from a reader whose success at using a hacked cable with his 7960G prompted me to have another go.

While I did a heap of research about PoE and IEEE 802.3af, the hints I got about using a hacked cable with a standard 802.3af switch to power a Cisco phone came almost exclusively from the wiki. Everything I’d seen about this trick relied on the use of a crossover cable to fix the problem where the phone using the Cisco pre-standard expects the power in the opposite polarity to that delivered by 802.3af.

When I’d had a go previously, the info I had told me that I had to get power onto the spare pairs in the Ethernet cable, because the Cisco pre-standard used the spare pairs for power and not the data pairs. This was a problem as my switch provided Type A PoE, which is power-over-data-pairs. In the end I figured that I’d have to come up with some kind of electronics to get the power off the data pairs and onto the spare pairs.

My friendly reader informed me, however, that Cisco pre-standard phones take power from the data pairs as well as the spare pairs! Nothing I’d seen indicated that this was a possibility. So I pulled out the hacked-up cable I’d used previously and gave it another try… but it didn’t work.

I tried a bunch of alternatives that I probably tried before as well. I tried putting the sense resistor across the spare pairs instead of the data pairs, I tried switching the spare pairs around. But, since others had only ever reported success with a crossover cable, it had never occurred to me to try a straight cable instead. A bit of resoldering later, another try, and it worked!

Tried it with all my 7960s and it worked fine. So it looks like some 802.3af switches put power on the pairs in the opposite polarity to others (which is not a problem usually, as 802.3af devices have a bridge rectifier that allows them to handle either polarity).

Thanks to my friendly reader, I now have a way to power all my Cisco phones via PoE! Yay! The only caveat (one that I’ve only seen briefly mentioned anywhere) is the extra load placed on the cable by the 25kohm sense resistor — doubt it’s significant, but over a few phones it might add up.

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: , , , , ,

FreePBX modes

When I first set up FreePBX, I was frustrated by the inability to create a voicemail user independently of an extension.  It looked to me like an office system, where each handset was associated with an individual and had its own voicemail.  In the end I created a few extensions that were not associated with handsets and used them as the voicemail boxes (I disabled voicemail on all other extensions) and wrote a custom dialplan entry to work out which voicemail box was associated with the “usual” user of each handset.  Works fine, even if I have to check each upgrade of FreePBX doesn’t knock out my custom dialplan stuff.

Recently though, I found that FreePBX does indeed have an alternate programming method that matches up with my original intended use.  The default method is called “Extensions” mode, while the different method is called “Device-and-User”.  The extensions mode, in effect, creates a user for every device defined, and calls it an extension.  The device-and-user mode however allows you to configure each separately.  Your device configurations are simply end-points for your handsets (SIP definitions for example) and users are the entities you actually want to reach (i.e. people).

A device can be either “Fixed”, where it is always associated with a particular user, or it can be “Ad-hoc”.  An ad-hoc device allows a user to log on to the device and receive their calls at that device.  A user can be logged on to multiple devices at once, or even a mixture of fixed and ad-hoc devices.

I was really excited by this, as it seemed that I could replace everything I had set up with my extra extensions and associated Ring Groups by just switching to device-and-user.  There is a little snag though — even though devices still have to have a numeric name that looks just like an extension, it is not available to the dialplan in its own right.  If I have configured my ATA-attached cordless phone as device 852, I cannot dial 852 and make it ring.  I can only dial whatever user number the device is associated with, which in turn means that if no-one is logged-in to an ad-hoc device there is no way to make it ring.  Also, a device can only be associated with one user at a time.

I have auto-answer SIP presences on all the handsets that support it, which I use as a two-way intercom system.  This supplements FreePBX’s Paging facility which I use for broadcast, one-way announcements to all (such as “dinner is on the table!).  I couldn’t switch to device-and-user mode completely, as I would lose the ability to selectively dial devices such as the intercom lines that would not be associated with a user (or would need to be associated with more than one user to support both paging and intercom).

So for now I’m sticking with what I’ve got.  I like device-and-user, but by not making the device’s number addressable in the dialplan they’re eliminating a lot of flexibility and possible functionality.  When we moved into our current home I ripped out much of the builder’s phone wiring and replaced it because I didn’t want all my phones in parallel… that’s what device-and-user feels like right now: everything in parallel.  I’ll keep an eye on it though…

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: , , ,