Flashing Nokia E66 from VirtualBox

For last couple of years I don’t have Windows as main operating system. There are many reasons behind this decision, one for all would be it’s reliability. While using different operating system as the main one, I still keep couple of Windows virtual machines, I need them for testing of our software as well as for running applications, that can’t run anywhere else. Such as Nokia PC Suite.

I bought my Nokia E66 as one of the first people here in Prague. I had to wait for branded T-Mobile version because it was part of RMA transaction of my old E65. From the time I got my new E66 I was waiting for first firmware update. There were few annoying bugs, bugs that old E65 didn’t have. But as this was a branded version, update took quite a long time to appear in Nokia’s firmware update service. But it happened this week.

Having used PC Suite for backups in virtual machine I though firmware update would be piece of cake; it wasn’t. If you have ever used VirtualBox you probably know that there a device filter has to be added in order to “see” USB device inside virtual machine. Normally this is done on the fly – you connect a device, go to configuration, add it to filters, disconnect, connect and voilà…

In order to flash E66 successfully, two devices have to be added before flashing starts. In theory you could add them on the fly, but I’d have to be quick in order to keep flashing process running. I did this risky stuff for you so you can now flash safely having added these two devices to your Windows machine’s USB filter:


0421:0106
0421:0105

One of them is serial device of some kind, the other identifies itself as loader. Have fun!

WiFi is not always the easiest way…

We recently moved into new offices. One of the problems we had was internet connectivity – we rely pretty much on stable and fast connection and our good old provider (UPC) was able to connect us on new location. Fortunately there is a fiber optics in a building nearby (480m / 1440ft). Logical solution to this kind of problem is WiFi technology, right? We wanted to have something stable so we went for 802.11a (aka 5Ghz).

Next important step was to choose the devices, having read almost every resource available and being recommended it we’ve decided to try Chinese OEM devices made by Wistron NeWeb Corporation (WNC) – namely model called RDAA-81 which is, for some unknown reason, called AirCA8-PRO in Europe. They are quite cheap, the price is around $100 per one (including VAT).

One day it took us to mount antennae to both ends, it was quite easy on the “fibre optics” building – it’s just behind the window while it took some time on our office bulding, we had to use long cable from the antenna to device, drill several holes etc.

Next day I came with the devices preconfigured for wds bridge, which is basically a combination that should behave in a transparent way like normal ethernet cable. We connected everything and it started to run. It ran for half an hour and then it suddenly dropped and didn’t come up again. I connected to the other end through the internet, reseted it and it started to work. For twenty minutes.

At this point I’d like to point at another bad aspect of those devices – they’re booting 3.5 minutes. WNC developers must’ve been joking! Next time even web administration of the device was dead. It was during Saturday and I didn’t have the keys to the room where the device was.

I searched the internet and found some people having same problem with wds mode hangups, so I’ve decided to reconfigure devices to standard accesspoint – client setup. I had to wait till Sunday until someone was able to reset it by pulling it out from the wall. For this setup I had to flash another firmware because the original one is accesspoint/wds only. I also had to login first through telnet interface and issue something like z_debug signature disable, the firware recommended by reseller is apparently meant to run in another hardware 😉

New setup was somehow better – now the link seemed to be more stable but when I tried to ping router behind the LAN interface it only worked for some time and then there was each time same delay of 40 seconds when I was not working. I also tried to ping internal IP on WiFi interface and that worked. To make long story short – this client firmware works fine until it receives ARP who-has from device with another MAC. When this happens it stops working until ARP with MAC of gateway (or what you’re communicating with) comes or delay of 40 seconds ends.

In client mode I was also able to see signal strength (this is not available in wds mode, there is no way how to check if the devices are associated to each other!), scanning for all accesspoints took around 3 minutes, however.

At this point I was ready to rma the devices and buy something more expensive but working.

But I’ve decided to give it a last chance – with OpenWRT firmware. Standard OpenWRT doesn’t support those devices but I found a fork just for them – Atheros OpenWRT managed by coincidence by someone from Prague (binaries are at http://openwrt.dlabac.net/snapshots/atheros/).

Again the same problem with getting into locked room at the other side but on Wednesday both devices were flashed and connected together in simple, not encrypted, link. It took us some time to talk to developers and configure it propertly- apparently it’s newer version of OpenWRT which is not documented on the web – all the configuration files are different etc.).

We had a link running but no encryption, which is simply unacceptable for “business” use. If there was nearly no documentation for “standard” features there certainly was zero documentation for WPA.

Fortunately I wasn’t linux newbee and moreover I was experienced in wireless extensions and specifically hostapd (I helped to build wireless network in our neighbourhood, it was/is still running mostly on 802.11b, majority of accesspoints are linux machines with hostapd running:) ).

So even without any documentation (and support in configuration files) I managed in three hours to get WPA running. Unfortunately things like that can not be just configured, one has to write his own starting scripts for hostapd on accesspoint side, wpa_supplicant on client side and static routes (if needed).

Pros:

  1. OpenWRT boots faster (30 seconds compared to 3.5 minutes)
  2. fully configurable – it’s standard linux (2.4) with ssh
  3. it’s stable compared to the original firmwares

Cons:

  1. way too much time spent on the project