Technical Bulletins

BlackBerry Torch 9800 UMA (Unifon) on the Orange Network (Orange.PL)

2010-10-21T09:36:00.008+02:00

UMA stands for Unlicensed Mobile Access. It is also sometimes called GAN (Generic Access Network). In short - UMA - enabled phones can use WiFi as base stations. Home / office WiFi or public WiFi. It is a very nice feature. It offloads the mobile network - MNOs like that. It lowers your bill when roaming (UMA / WiFi calls are not considered roaming calls) - subscribers like that. And sometimes it is the only way to connect (as in my case). I live in a deep remote valley outside the city and I do not have coverage. UMA solves that problem, as at home my phone uses my WiFi.

UMA does not require doing anything special -launching an application or setting up call forwards. Once configured, it can even hand a live call over from GSM/3G to WiFi and vice versa.

The downside of UMA is it requires special support on a handset (terminal). And only a small number of handsets are UMA - compliant. But the good thing is UMA is supported by almost all BlackBerries. I have been using UMA for almost two years now, on a BlackBerry Curve 8900 on the Orange.PL network. But my 8900 have up the ghost a week ago (it probably had enough of me dropping it on a concrete floor). Looking for a new phone I decided to go for the new Torch 9800. Called Orange, but they did not even know such model existed. So I bought it SIM-free. Unfortunately when it arrived it knew nothing about UMA. So I had to hack it. I mean properly configure. So here is the story. The method described below is a generic method, but certain settings refer to Orange.PL settings, for other networks you will need different URLs and certificates.

First I had to enable the Blackberry Engineering Setup. To do that you need to invoke the engineering menu by pressing Alt+Shift+H, and entering a special passcode. The passcode calculator is here: http://www.zibri.org/2009/08/hidden-things-are-usually-best.html. To get your passcode enter your device PIN, the APP version (as you see on your screen, including the space and parenthesis, like "6.0.0.246 (695)", the uptime and select how long you wish the passcode to be valid. Then simply type the generated passcode. Nothing happens as you type but when you finish, the Engineering Menu opens.

Choose the [Mobile Network Engineering Screens] and scroll down to the bottom where is the [GAN Control...]. There are basically two things I had to set up. The SEGW and GANC addresses.

SEGW: uma.orange.pl
GANC: hbsc.centertel.pl

The rest I left unchanged.

The second step is to [Utilities] and [Session Manager]. Pressing the menu key there is the [UMA Options] item to select. It will either show an existing list item (like "Factory Defaulted") or use the [New] option to create one. You will be prompted for Display and Operator name (I entered Orange, but anything should work). Then uncheck the [Use default UNC address] and enter:

Provisioning UNC address: hbsc.centertel.pl
Provisioning UNC port: 14001

Again uncheck the [Use default SEGW address] and enter:

Provisioning SEGW address: uma.orange.pl

For the UMA protocol version select the [UMA v. 1.0.3] from the dropdown menu.

The last thing (and the most important one) is picking up the certificate. It is used by the handset to authenticate itself when setting up a secured communications tunnel via the public Internet to the MNO's network. The dropdown offers all certificates from the BlackBerry certificate vault. In my case they got there in the first place during the migration phase. Before I started playing with UMA, I used the Blackberry Desktop Manager to "Switch device" from my old Curve 8900 to the new Torch 9800.

The certificate I found works with UMA at Orange.PL is the [Equifax Secure Certificate Authority]. I don't know if it is factory preloaded on new phones, or I copied it from the previous UMA-enabled phone.

Anyway setting things like above, and enabling WiFi network, allowed my phone to switch from 3G over to UMA. It works rock solid. The call quality is better than it used to be with the Curve 8900 (more horsepower?). So that is about it. Looking forward to some comments if people find this article of a value. There has been a word Android is going to support UMA, which is great news, as it would broaden the base of available UMA - enabled phones (after all not everyone is a fan of BlackBerries).

Nokia Booklet 3G FDE SSD Upgrade

2010-05-14T20:06:00.010+02:00

A week ago, blinded by its beauty (and long battery life), I purchased the Nokia Booklet 3G netbook. Actually the purchase was not 100% impulsive, as I had done some research beforehand.

For almost a year I have been using the Lenovo X200s laptop, equipped with a solid state drive (SSD). The Lenovo SSD I chose still seems to be the only one on the market, supporting FDE functionality. FDE means the drive strong encrypts everything it stores and securely manages encryption keys. FDE technology does not require any supporting software, which is nice. The only thing it needs is a hard disk password enabled in BIOS. In standard disks, the hard disk password just enables the drive. In FDE disks the password is used to release an encryption key from a TPM chip on the drive. Actually the Lenovo 256GB FDE SSD drive is manufactured by Toshiba, and the part number is THNS256GG8BAAA. I had it in my X200s Thinkpad, in a 2.5 inch bay. While the drive itself is 1.8 inch.

Analyzing the Nokia Booklet 3G I found it was built around another 1.8 inch Toshiba drive, the MK1235GSL 120GB unit. There are two major differences between the two (setting capacity aside). The original 120GB one is mechanical, with 4200rpm speed, which makes the computer very slow. And I mean very. Almost unbearable. The only way to make it usable (but still far from demonic speed) is to swap the spindle drive with a SSD one. I was lucky to have a 1.8 inch SSD in my Lenovo. So decided to make a try.

It is a little challenging to disassemble the Booklet 3G. The chassis is an aluminum monocoque, a single block of metal forming both the upper and lower side of the case, plus sides. Zero screws and bolts. Actually to get to the motherboard you have to take the keyboard off. I did this by inserting a credit card between the keyboard and the display hinge. And then popping the keyboard up from its latches. Once the keyboard is taken away, there is a steel shield you have to unscrew using a Torx driver. The drive is in the middle, not fastened by any additional screws. Just pull it up gently and disconnect the micro-SATA ribbon. The original drive is wrapped in a rubber jacket, I took this jacket off and put it on the new drive. Then plugged the new one to the micro-SATA connector and everything started to work as intended.

After I reassembled the machine back to the factory state (with the new drive in), it showed the SSD drive on the boot screen. After this it was only the matter to install Windows 7 from an external DVD drive. It all went smoothly.

There have been two immediate effects noticeable after the upgrade. The first, obviously, has been the overall speed of the system. I do not have precise benchmarks, but the hard disk score now is 5.9, a remarkable number for such low end Atom - based system. It is a night - and - day difference when compared to the original setup. The computer boots fast, applications launch fast. The memory consumption is lighter, as many spindle - drive associated mechanisms available in Windows 7 arsenal (superfetch, readyboost, application prefetch) are no longer needed.

The second effect of the SSD upgrade is shorter battery life. This may be a surprise for some, but contrary to the general belief, today's SSD drives consume more power than the mechanical ones. In the Nokia Booklet 3G case, the original drive is rated 700mA at 3.3V, while the SSD I have used is 1600mA at 3.3V. So the difference is 3 Watts, what over ten hours means 30 Watt-Hours, or half the available battery capacity. Of course this power rating is peak, not continuous, and SSD drive completes the high power operations in shorter time. All in all in my case I have experienced battery life drop from 12.5 hours down to about 8.5 hours, which still is a significant 30%, but I can bear with that, having a system that does not crawl like a snail. Later I plan to test a different SSD drive (sans FDE encryption), so I hope to report the results here.

In my opinion the SSD upgrade is a must for anyone seriously thinking of making the Nokia Booklet 3G their main / primary machines. I am very happy with the upgrade. I have a really tiny laptop, with big and fast 256GB storage. I also equipped my desk with the iiyama ProLite E2210HDS 22-inch FullHD display I connect to the Nokia via a nice and small HDMI cable that carries both digital video signal and sound. Such screen coupled with a comfortable Lenovo DiNovo Bluetooth keyboard and the original Microsoft Bluetooth mouse makes my home station setup very comfortable. Of course the Nokia is the heart of it and I do love having exactly the very same setup (albeit with a smaller screen and keyboard) on the road.

Update: as an exercise I decided to try another brand of SSD. I was able to borrow the Samsung MMDPE56GTDXP-MVBD1 micro-SATA (uSATA) MLC Thin 256GB drive. Actually calling it a drive is a bit of an exaggeration , as you can see on the photo above, the Samsung SSD drive resembles more a memory module than a drive.

To speed things up, I decided to use the Acronis Clone Drive, plugging the Samsung to the USB port. I used a standard USB-to-SATA adapter (taken from a USB drive enclosure) and a SATA-to-micro-SATA (SATA-to-uSATA) converter.

On the first run the cloning operation failed. The reason behind the failure is quite interesting. Windows 7 introduced a special command, called TRIM, that helps in handling SSD drives (there is a good, detailed explanation here). Some newer SSD drives support TRIM, some older do not. Windows queries drive capabilities and adjusts its command set accordingly. Unfortunately the US15W SATA interface chipset in the Nokia does not support TRIM. So what happens, Windows queries the drive, the drive reports it is TRIM capable, Windows tries to execute the TRIM command, the chipset blocks it and the process hangs. The only workaround is to disable TRIM in Windows before cloning. You do this by opening a command prompt as an administrator and executing [fsutil behavior set disabledeletenotify 1]. This disables the use of TRIM at the system level, and you can then use any SSD (with some performance consequences on write operations).

On the second attempt, after dealing with the TRIM issue, Acronis handled the cloning operation without a glitch and when completed, I was able to swap the drives. To my surprise the battery life did not improve at all, comparing to the Toshiba - based system, even that the Toshiba drive was rated at 1.7A and the Samsung at 0.8A. It looks like those ratings do not reflect the real power consumption. After a couple of days it even seemed to me the Samsung drive was drawing more power, as I was never able to exceed 8 hours on a charge. Not seeing any benefits from the Samsung drive, I cloned the system back to the Toshiba FDE.

Setting Up The Sheeva Plug

2009-12-22T10:53:00.003+01:00

The previous post on the initial Sheeva setup assumed readers had spent some time playing with the installer and with the Sheeva Plugcomputer itself. I received a number of requests to clarify things a bit more for beginners. So here is the more detailed description.

First, the plugcomputer itself. It is an integrated platform, based on SoC (System-on-Chip) offered by Marvell and named Kirkwood. Kirkwood contains so called ARM core, so all applications executing on this platform have to be compiled for ARM. The Sheeva has 512MB system RAM and 512MB system flash memory (so - called NAND memory). It also has four ports:

1GB RJ-45 Ethernet port - to attach to a network
USB host port - can be used to plug a variety of USB devices - USB hubs, pen flash drives, protocol converters (like a 1-wire converter or a USB-to-RS-232 converter), USB cameras, keyboards, and even graphic monitors (using DisplayLink technology - more on this in later posts)
MMC/SD card port - to plug a SD card. This is important, as I recommend playing with the Sheeva equipped with SD storage. Due to process of wearing, flash memory has limited number of write cycles. If an SD card wears out, you can just plug a new one. If your internal NAND flash wears out, the entire unit will have to be replaced.
USB client port - this is used to initially setup the computer, before it can execute anything on its own.

The initial setup process is organized as follows:

The so-called installer is a set of binaries and scripts. You have to download it from the plugcomputer.org site and unpack to either Windows or Linux host machine. As I never succeded setting up the Sheeva from a Windows host, I will focus on the Linux variant here.
The installer has two parts. The first one is a set of binaries you have to copy to a pen flash drive. Then the populated pen drive has to be plugged to the USB port on the Sheeva. The second part are scripts, that are copied over USB link (a USB cable connected between Sheeva's client USB port and the host machine). The scripts are then executed on the Sheeva - their job is to move and unpack the binaries from the USB pen drive and place them either on the internal NAND flash memory or on the plugged SD card.
The Linux installer is basically a PHP script, so it requires a PHP client to run, as I wrote previously. The entire install procedure is well described in the installer's readme file. In short - there are two basic variants - one installs the system on the internal NAND (executed by [sudo php runme.php nand]), the other installs them on the SD (executed by [sudo php runme.php mmc]).

Before setting up the target operating system (in case of the current version it is the Ubuntu 9.04), the installer sets up the so - called boot environment. The boot environment is executed first when the Sheeva is powered up. It initializes the basic hardware components and then loads the OS. As there are some cases when you need to access the boot environment, the only way to do this is via serial terminal console. The serial link runs over a USB cable between Sheeva's client USB port and the host machine. My host runs Gnome, so my natural pick has been the GTKTERM application. If you run Windows, you may use PUTTY set up for a serial link (a COM port, 115200 baud, no parity, one stop bit).

As mentioned before - on my development Sheeva system I happen to refresh the OS quite frequently. With access to the boot environment it is a snap. Just plug in the previously populated flash pen drive with OS binaries, boot the Sheeva with serial console attached, and at the boot environment prompt just type [run recover1]. This partitions and formats the destination filesystem (NAND or SD card) and installs a fresh instance of the Ubuntu from the pen drive.

After the Ubuntu is set up, the serial console is no longer necessary, the USB cable can be unplugged. When Ubuntu loads, it may be accessed remotely from a host machine using SSH connection (terminal window in Linux or Putty in Windows). The default user is root and the default password is nosoup4u. Of course it is a good practice to change it after the first logon - by executing [passwd] command.

The other steps I run after the new clean install are:

update the distribution sources:
apt-get update
upgrade the system components to the current versions:
apt-get upgrade
install the NANO - an easy and simple character based text editor to work on various configuration files:
apt-get install nano
clean the updater cache and remove potential orphaned modules:
apt-get clean
apt-get autoremove
synchronize the system clock:
ntpdate pool.ntp.org
burn it to the hardware clock:
hwclock --systohc
and configure the time zone data:
dpkg-reconfigure tzdata

After these steps the Ubuntu on Sheeva is ready for experiments.

Sheeva Plug Dev Station

2009-12-20T22:45:00.004+01:00

I mentioned the Sheeva Plug computer several times on the headworx blog. Today I start a series of posts that will continue here on the tech.slupik.com, devoted to Sheeva development, and to plug computers and other embedded systems in general. But let me post the inaugural story in both places.

At the moment I run two Sheeva servers in my little data center. I have the third one set up as a development / staging environment. There are many ideas continuously coming to my mind. Most of them require testing various scenarios and it would simply be inconvenient to mess with the production machines. That is why I purchased the third one. hey, at $99 it is not a life changing decision.

When the third Plug arrived, I thought to myself it would be nice to have a permanent environment in place to play with it. Environment here means a host machine, needed to prepare the Sheeva to run and then a simple I/O for screen and keyboard and a web browser. The hardware requirements for such a machine are pretty minimal. As usual I wanted to have a decent screen resolution (1280 by 1024) and a good mouse / keyboard. I had a Samsung Syncmaster LCD display collecting dust underneath my desk. There was also a Logitech DiNovo keyboard and a Microsoft Mouse. The Samsung had simple VGA input and both keyboard and mouse were "Bluetooth". So all I needed was a kind of a low - end CPU with OS, storage and network interface. A Linux netbook seemed like a good idea. I called a friend of mine who purchased a number of HP-2133 mini-note netbooks some time ago. He had one for sale at a reasonable price. It arrived with Suse Linux on board. I played with it for a day, but did not like the Suse and tried a number of alternatives, finally selecting the Mandriva 2010 edition. The Mandriva was selected only because it installed almost flawlessly, detecting all the peripherals on board the netbook. I had some issues forcing it to support the native 1280 times 1024 resolution of the external monitor, but ultimately after upgrading the BIOS, I was clear to declare the victory. The system was fully up and running. Good screen, excellent keyboard and mouse, wired and wireless network and USB to connect serial console to the Sheeva.

Apart from the host Linux machine, I also needed an Ethernet switch. The Netgear GS105 is really nice. It is relatively heavy, so does not get pulled by the Ethernet cables. It is very small too, not taking too much space on the desk. I also found a very nice USB hub by Asmax (this is a Polish brand, but the product itself is probably available worldwide, just with a different name. It is white (matching the Sheeva) and has very thin and short cable with angled plug - perfect companion for the Sheeva - see the attached photos.

Now a few hints I put down.

To set up the Sheeva, I successfully use the SheevaPlug Installer. I never made it run on Windows, so won't help you here. But if you use the Linux version, here are a couple of things to consider (with respect to the Linux host machine):

Install the PHP client (sudo apt-get install php5-cli)
Install the missing LIBFTDI1 (sudo apt-get install libftdi1)
Set a proper MAC address to be burned to Sheeva by the Installer. The procedure is detailed in the installer's readme.
I strongly recommend setting up the Sheeva with a SD card. Personally I use 4GB Sandisk Extreme III 30 MB/s edition. It probably is faster than the internal NAND and most importantly - can be replaced once it wears out. On the other hand when you wear out the internal NAND, you will have to replace the entire Sheeva. To setup the system on a SD card, you invoke the installer as follows: [sudo php runme.php mmc].

Before you start installing system on the Sheeva, it is good to prepare a serial console on the host machine. This way you can watch the installer doing its job. To setup the console I had to do the following steps on the host machine:

Ensure proper serial interface is connected:
rmmod ftdi_sio
modprobe ftdi_sio vendor=0x9e88 product=0x9e8f
chown uucp /dev/ttyUSB0 (or .../ttyUSB1 - depending on your setup)
Start serial terminal application
gtkterm

After setting things up as described above and launching the installer the entire setup process takes about 10 minutes. It ends up with the Sheeva loaded with Ubuntu 9.04 (the rootfs is on the SD card) and its IP assigned by a DHCP server. You can ssh to root@. The initial password is [nosoup4u]. Before we start setting it up further, there is one issue, that has to be fixed in the boot loader. To get there keep the serial terminal open and reboot the Sheeva (do not disconnect from the mains, just use a paper clip to press the reset switch via the small hole by the SD card). Once it starts booting, hit Enter to stop the boot process. You will find yourself in the boot environment, that works on a set of string variables.

Display the environment by typing [printenv]. There are two variables we need to fix. Both are identical, one is called bootcmd, the other one is realbootcmd.

Type

setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); mmcinit; mmcinit; ext2load mmc 0:1 0x800000 /uImage; bootm 0x00800000'

and then

setenv real_bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root); mmcinit; mmcinit; ext2load mmc 0:1 0x800000 /uImage; bootm 0x00800000'

and finally

saveenv

to make changes permanent.

The reason we do this is the double mmcinit command. There is a bug in the boot environment. After power up, it does not initialize the SD card properly. So without the above modifications, your Sheeva would not boot after power loss. Calling the mmcinit twice is a good enough workaround.

And we do this twice for a reason. Usually the bootcmd is used. But there will be time when you will have a need to reinstall the system from scratch. Having access to the boot environment, all that has to be done is to

run recover1

at boot time. The system will be refreshed. And so will be the bootcmd (it is copied from the real_bootcmd). Applying the fix in both places (bootcmd and real_bootcmd) lets you run the fresh installation process anytime without any need for additional fixes.

So the system is up and running now. The story will continue here :)

Ubuntu and Canon IP5200R WiFi Printer

2009-09-18T16:27:00.003+02:00

I have been experimenting with Ubuntu recently. Must say the 9.04 package is far beyond expectations, especially when it comes to support for various hardware components. I installed the entire system in fully automatic mode and it discovered all connected hardware. It did not discover my Canon IP5200R printer, as it is not connected directly to any physical machine - being available on my home network over Ethernet instead.

Canon does not provide any Linux drivers for the IP5200R, so I was rather skeptical about being able to run it... But the other day I tried.

First I connected the printer using the USB interface. Surprisingly Ubuntu discovered it and offered a list of potential drivers. The IP5200R was on that list, so I picked it. Then it offered to print a test page and it proved everything was working fine.

I knew the printer was assigned an IP address of 192.168.0.10 so now the task was to try to connect it without the USB cable. And the solution proved to be much simpler that expected... In the printer settings dialog in Ubuntu there is a Device URI field. It was pointing to one of the USB ports. I changed it to [socket://192.168.0.10] and... it worked. Printed a test page with USB cable unplugged and kept on printing everything else over the network...

Unix has this great charm of simplicity... Thinking of this later I realized this printer must have a simple LAN to serial converter, meaning the actual protocol of commands and data transmitted to it never changes... regardless of the physical interface (LAN / Wireless / USB). So it is logical, to enable printing via LAN, it should be enough to change just the port settings.

Squeezebox Bose Duet

2008-11-18T13:35:00.013+01:00

The Bose Acoustic Wave System (AWS) has been one of my favorite outdoor music systems for a long time. Mostly used for summertime garden parties it has remained a top sound engine, while lacking some of the latest music source capabilities. Actually the original Bose AWS has just two options: a CD player (no MP3...) and an FM-tuner. Ah and there is - as with all Bose systems - an AUX port, so I used to connect my iPod to it. iPod is fine, but it has one drawback - the music is static, you will never hear or discover new music, as iPod can play only what you store on it.

Pandora (my favorite music discovery service) is different. It keeps on playing exactly the music you like, but most of it you do not know, hearing it for the first time. The primary device to play Pandora on is a computer, but that is not as easy as turning on radio. And to be honest I hate computers (in their usual form, with screens and keyboards). That is why I have a house full of various products from SlimDevices, especially loving the Duets, as they decouple the music receiver (essentially a black box) from the control remote, with its rich experience and easiness.

Since the first Duet arrived at my home, I have been thinking of embedding one inside the Bose AWS, as they seemed to be the perfect match. I just have not been sure the Duet receiver would fit inside the AWE, but willing to try I've been prepared to sacrifice the built-in CD Player.

What was my surprise, after opening the AWS, there seemed to be a special place reserved just for the Duet receiver - see the photos.

As the project ended with full success, here is the small step - by step how-to, should you have the desire to repeat what I did :).

Opening the AWE. There are two steps to it. First is removing the top part with the twitters, CD drive and touch buttons. The second is to play with the power supply accessible from the bottom, but let us leave that for later.
So start unscrewing the five screws on the left / right / back side of the AWS. The fifth holds the antenna, take it out and remove the antenna. Then detach the top part from the AWS.
Remove the board with five micro switches on it. Then using wire cutters or similar tool, cut the plastic frame below it to allow comfortable placement of the Duet board.
The Duet board needs one of the corners to be trimmed. See the attached pictures. Do it carefully, and after the cut clean the edge with a file. Otherwise you may short circuit the board with the remains of copper on both sides.
I placed a small piece of rubber between the Duet board and the micro switch Bose board, so they keep nicely together. Ah and you may use one of the micro switches to double as the Duet micro switch - solder two pieces of wire between the two, I decided to sacrifice the "CD Mode" switch.
Connect the Duet audio output terminals to the aux in terminals of the AWS. Make sure the shield is connected only on one side (I soldered it to the AWS terminal). Otherwise you will get some extra unwanted hissing sound effects.
Now the power supply. The AWS power supply delivers somewhere between 12 and 15 volts. The Duet board requires 9 volts. I used an L7809 regulator to take care of that. First I was not sure if I wanted the Duet part to be permanently ON, but it proved to be the right decision. You can always turn it off using the remote. The wiring and the placement of the L7809 are shown on the pictures. The left terminal (input) is connected by the red wire to the (+) terminal of the AWS power supply. The middle terminal is the ground, and so is the radiator, so I did not bother there, connecting the middle and the right terminals to the angled power plug, plugged into the Duet board.

The end result is something I think Bose should look into. They have phenomenal audio, but they really lack the latest digital connectivity options. Sure there is the new Logitech Boom, but it is more suited towards indoor, small room operation. The Bose AWS excels on the sound scale, has perfect outdoor accessories (integrated carry bag and battery compartment) plus it can do karaoke too. I am very happy with the modification and I think some of my fellow readers will try to follow :). Recommended!

Making Powerline Ethernet HomePlugAV interoperable

2008-11-06T14:26:00.003+01:00

A few weeks ago I posted an overview on the ZyXEL NBG-318S Powerline Ethernet switch / router with WiFi. After several weeks using the ZyXEL as my main entertainment room hub (both the PlayStation 3 and my set-top satellite box are connected to it, and it also serves as an access point), I can say the only thing I can give it a thumb down is the name. NBG-318S... who invents things like that? Nevermind... I can live with the name as long as the product shines.

So... the NBG-318S is a HomePlug AV device. That means, at least in theory it should work in tandem with any other HomePlug AV device. That includes for instance the PLE200 from Linksys. But that is the theory. In practice when I did a simple test plugging both the ZyXEL and the Linksys to the wall, they did not see each other. Digging here and there I found the PLE200 with factory installed firmware was not fully HomePlug AV compliant. Upgrading it to the latest firmware ultimately did the trick. The upgrade process was not as straightforward as it should be. First, there are different versions of PLE200 firmware on different Linksys.COM servers. I succeeded using the one from the US site. Here is the link. Version 3.3, with release date May 23rd, 2008. The upgrade process is done via the PLE200 client utility, but it has problems with Windows Vista, so I had to find a Windows XP machine, and disable the firewall on it (the Windows firewall prevented the upgrade too). And that is all the PLE200 utility can be used for, as I did not succeed linking to the ZyXEL using it.

On the other hand the ZyXEL web-based management interface allowed me to add the upgraded PLE200 to the Powerline Ethernet network. You do that simply by entering a MAC address and a device password, both printed on the back of the PLE200. Once the Linksys adapters were upgraded to the 3.3 firmware, the HomePlug AV network runs without any glitch. The average link speed exceeds 100mbps (see the side picture) and I have already watched a ton of movies streamed from my NAS server to the DLNA - enabled Sony PlayStation via the power line.

Digital Home

2007-11-18T21:17:00.000+01:00

I blogged here and there before describing various components of my digital home. The WiFi network, the IP Camera, the Squeezeboxes, the Slimserver... Now after several years of putting together several ad-hoc components the time has come to redesign the entire systems from scratch, based on the experinence with various products, vendors and technologies.

I will be updating this post, so come down here in a few weeks to see what has changed. Today just a short list of bullet points of what I intend to cover.

First of all I have two homes (one small wooden cottage I love to spend summer and weekends in) and a second one in the city, with a hot tub for harsh winter :). The ultimate goal is to connect both homes together and have a unified user experience in as many aspects as possible - starting from music playlists that should be up to date and synchronized among my iPod and both places, to the IP subnets addressing to be able to connect to any device from anywhere.

So here is the entire idea in a nutshell:

There will be a VPN tunnel set up between both homes. The one in the country has a fixed IP DSL line (1Mb only, unfortunately...). The one in the city has a 2Mb line with dynamic IP. I intend to use a Dlink DFL-800 VPN Router / Firewall there. The DFL-800 will server as a remote VPN server (I want to be able to connect to the home network whenever I am on the road) and also as a VPN endpoint of a tunnel between the homes. On the other side of the tunnel I plan to use a Dlink DFL-200 (have to check if it can "redial" the other end when DSL IP address is recycled by the service provider or whenever the link is just dropped. If the DFL-200 does not handle the tunnel good enough, I will probably opt for a second DFL-800.
Behind the firewalls I plan to use the Infrant ReadyNAS NV+ storage servers. They will serve as a generic storage on a local area network. I plan to set up replication jobs between them, so that each unit is a backup of the other. This way, for example, when I buy new music and save it on one of them, the content will be replicated to the other home, ready to be played there when I move.
The Infrant units will host Slimservers to power a local array of Squeezeboxes to handle multi - room audio around each home. This is easy to do now, as the latest Infrant boxes come with Slimserver preloaded.
Looking forward the Infrant units will serve as multi-purpose DLNA - compliant home servers, to be able to stream videos to various devices like the PS3 console or a Loewe Connected TV, or pictures to connected photo frames around each home.
Infrants will also store live picture snapshots from IP cameras, so the WiFi photo frames will be able to show near-real-time pictures from the other end. Living in the city it will always be nice to have a look at the wonderful virgin winter in the country :)
There will be other addons, like UPS units, WiFi access points, I will be describing them if they deserve some attention.

That is all from the distant perspective... will see how it goes... as the devil is in the details (as always!).

Linksys VPN

2006-12-29T14:21:00.000+01:00

Recently I have finally succeeded in setting up a VPN connection to my home network running Linksys WRV200 at its heart. Support for VPNs was one of the primary reasons I decided to upgrade from my old WRT-54GC. The other reason was the RangeBooster feature - I described it on the Headworx blog.

WRV200 is supposed to run VPNs out of the box. Unfortunately things are not so straightforward, so below are the issues I managed to solve and in the end VPNs run as advertised.

Upgrade your firmware. At the moment I run the 1.0.24 version released on December 1st, 2006 and it works bot stable and functionally complete. The previous one I had was fairly unstable (frequent reboots required) and I could not make it working with VPNs.
You need a special VPN client software. I was a bit naive to think I could use the standard Windows XP VPN connection to connect to the Linksys WRV200. It will not work. You have to use the Linksys QuickVPN application. It is available for download from the WRV200 product page on linksys.com.
The QuickVPN application does not work with Windows Firewall. One workaround is to disable the firewall, but this is absolutely not what I would ever do. You should add the QuickVPN to the Windows Firewall exceptions list, but this is not enough. You will still not be able to connect, as there is a bug in the Microsoft code. Fortunately there is a fix available (http://support.microsoft.com/kb/889527), so download and install it.
If you happen to connect from a network running another Linksys product (like the WAP54GX in my case - we have them in our office), you may be in trouble. After upgrading my Windows Firewall I was able to connect from my notebook over the wired network, but all the attempts to connect over wireless were failing, exactly the same way as before the Windows Firewall upgrade (the QuickVPN was stuck on the "Verifying Network" message). It simply looked like the IPSec ICMP packets were being dropped again. After looking here and there I found this post on the linksysinfo.org. So if there is a WAP54GX on your way, you have to bypass it (or wait for Linksys to fix the issue).

Overall I am happy with the solution. Of course would prefer not to use a special VPN client, but hey, I can live with that :) I have no clue why the Microsoft bug has not made it into the official Windows Update system... And it is a bit frustrating to have one Linksys product blocking the feature of another Linksys product. I am sure there are many people trying to make their VPNs working. I hope my post will help...

SlimServer Embedded

2006-08-15T21:17:00.000+02:00

Igor has recently come with an idea to build an embedded version of SlimServer, the open source software we use to stream music to our Squeezeboxes around the house. Most of the time the Squeezeboxes are tuned to the Pandora Radio, but from time to time it is nice to have them play some local music (local - means stored locally - in house, as opposed to the Internet). To be able to do that, a local streaming server is necessary, as Squeezebox does not have any built-in storage - it is just a network player / streamer. My first approach was to build a silent PC, dedicated as a media server (and running SlimServer software among other tasks), but this has several drawbacks - boot time, Windows patching, and price. Igor found the guys at NSLU2-Linux do run SlimServer on a tiny Linksys NSLU2 NAS (Network Attached Storage) device. The idea is really cool and I decided to give it a try.

Here is what I prepared to start with:

Brand new Linksys NSLU2 device ($83)
40GB 2.5" Hard Drive to store the music (excavated from my IBM T41, but you can use just any IDE drive)
2.5" USB HDD Enclosure to house the hard drive, with cable (something like that)

First I thought of using a two drive configuration with flash USB memory stick as a main system volume and HDD as a "media" drive for music, but after reading a bit here and there I realized the system drive has to have a "swap" partition. Flash drives have limited number of write cycles they can survive, so placing a swap on a flash would potentially reduce its lifespan considerably. Therefore I decided to go with a single drive configuration (i.e. one drive to store both operating system files and media / music). This has paid off in yet another way. I have noticed my 2,5" drive was stopping sometimes (during long writes), and the reason was the power consumption of the drive. It was just a little over the limit of 500mA supplied by a USB port. So finally I settled with a Y-split USB cable (actually the one that came with the USB enclosure) - so now one port (port 2) is used for communicating with the drive and second port (port 1) is used as an additional current source.

The process took the following steps to complete:

Installing standard NSLU2 and drives, to check if everything works fine and get used to the platform.
Installing Unslung firmware on the NSLU2.
Unslinging the NSLU2 (i.e. moving Linux OS files from internal flash to the external USB memory stick).
Installing Unslung Development Environment (compilers, make, etc.) and libraries (including Perl) necessary for the SlimServer software on the NSLU2.
Compiling SlimServer remotely (on the NSLU2 box). During this process UDE will automatically download all the necessary components from the internet.
Configuring the music library.

And here is the entire procedure from start to the end:

Start with setting up the NSLU2 the way Linksys wants you to. This way you will learn how the device behaves and you will be sure the hardware works OK. Format the drives from the web admin interface. Upgrade the internal flash rom at this step to the latest Linksys version. Also make sure the internet connection is working fine, as later on the NSLU2 will download certain files automatically. There is a nice feature of administrative alerts that are sent to the user-defined email address. I suppose most of you (like me) have an Internet router in the home network, so the natural approach is to plug the NSLU2 to one of the LAN ports in the router.
Note: if the setup utility does not detect the NSLU2, then probably you need to turn the Windows XP firewall off to complete the setup procedure. And don't forget to turn it on again... [time: 1-3 hours]
When everything works fine with the standard configuration, install the latest Unslung firmware. Go to http://www.nslu2-linux.org/wiki/Main/HomePage or directly to the http://www.slug-firmware.net/u-dls.php. Download the latest release, unzip it and read the Readme document several times, until you are sure you understand everything you are doing. [time: 1 hour reading the docs, 15 minutes preparation and flashing]
Unslinging. This is a process of moving the root file system of the NSLU2 to an external drive and preparing the drive for further installations. Detailed instructions are in the Unslung firmware readme document you downloaded in step 2. [time: 15 minutes]
Now install the SlimServer. There are several steps involved in this process, the detailed guide can be found at http://www.nslu2-linux.org/wiki/Applications/SlimServer. As I do not have any Linux experience (yet!), there were several things that left me scratching my head and looking for an answer:

Copying the SlimServer source to the NSLU2. First download the SlimServer Perl Source Code to your PC. Make sure it lands with a .tar.gz extension. Then using the NSLU2 web interface create a public share, open that share with Windows explorer and drag&drop the file there. It will land in /public directory on the NSLU2. Then using cp (copy) or mv (move) command copy or move it over to /usr/local and there just execute tar xzvf... as described in the original guide.

Editing the build-perl-modules.pl was another story simply solved by copying the file to /public, where it could have been picked by Windows WordPad for editing (for those of you who do not know vi).

I proceeded carefully line by line with the original guide and after about an hour my SlimServer was up and running and I could log on to it via the web interface (port 9000). [time: 1 hour]
Configure SlimServer (using the web interface: http://...). For tests I highly recommend using just a couple of music files, as indexing them is very slow on the NSLU2. Basically all you have to do there is configure the music and playlists folders, in my case I pointed both of them to /public and invoking full scan of the music library. [configuration: 15 minutes, actual scan: depending on the size of the music library - in my case it was some 3 hours to scan some 5000 songs]
And finally configure your Linux OS to automatically start the SlimServer process when system starts. This is done by adding the following two lines:

cd /usr/local/SlimServer_v6.0.2
./slimserver.pl --daemon --prefsfile /etc/slim-data/slimserver.pref --cachedir /etc/slim-data

to the rc.local file located in /etc/rc.d folder.
Of course if your SlimServer landed in a different folder, you have to adjust the cd /usr/local/SlimServer_v6.0.2 command accordingly.

You probably wonder how to edit the rc.local file... Well... go and use the famous vi editor by typing vi rc.local. And here is how to operate it :) [time: 15 minutes]

On thing I am missing a little bit is the lack of WiFi connectivity on the NSLU2. There is a workaround here - if you are using the Slim Devices Squeezebox WiFi streamer. Squeezebox can act as a WiFi bridge, so you may just hook the NSLU2 to it, and the combo will be wireless.

All in all this exercise ignited my interest in small, yet powerful SBCs (Single Board Computers). More and more of these devices use one or the other form of Linux as an operating system and really prove software portability. My first SlimServer runs on a Windows XP machine based on Intel Pentium CPU (with a couple of fans). This is my second one and it runs on an embedded Linux machine (big as a pack of cigarettes) based on ARM. Fantastic!

IBM ThinkPad HDD Upgrade

2006-07-31T10:14:00.000+02:00

Recently I decided to upgrade the original 40GB hard drive in my ThinkPad T41 to something bigger (and faster). HDD upgrade is not something I like. It is as complicated, as changing the old laptop for a new one, but in the end you still have your old laptop, so the reward is... not that rewarding. Why is it so difficult and time consuming? I work with my computer easily ten hours a day (on average). And everyday I do something that makes it better. Add a few links, store a password or two, customize several websites, or install an application that makes my life easier. So imagine after, say 500 days, I decide to change the drive. I can always use a tool like Norton Ghost, to mirror my old drive (stream the content to the new one), but at the same time, I do realize my 500 days old Windows operating system is cluttered with the remains of old applications, unused registry settings and lots of rubbish that I no longer use, but what occupies the precious RAM and causes instabilities. Windows does require periodical refresh (that means fresh install most of the times). So usually when I decide to upgrade the hard drive, it is a good time to clean-install a fresh copy of the operating system. But then it takes almost a month to bring everything back to where it used to be... Metadata metachallenges... One day this will be universally solved.

But as this blog is not about life - changing ideas, I will not discuss the general (poor) state of the metadata solutions. The purpose of this bulletin is to share the way I upgraded a drive in my IBM Thinkpad T41 (should generally apply to other IBM laptops).

Where was the challenge? I had no Windows installation CD. IBM laptops come with Windows preinstalled, so you can restore the computer to factory default state (that means reformatting the hard drive) by pressing the "Access IBM" button at startup and then choosing the "Recover to factory settings" option. Of course... but this works ONLY when your hard drive has something they call "Predesktop Area", a piece of a drive with Windows install files on it. As you can imagine, the new aftermarket drives simply don't have that special area...

My plan was generally simple:

Transfer the IBM predesktop area from the old drive to the new one
Use the Access IBM button at startup to rebuild original Windows from the new drive.

Unfortunately it did not work. I purchased the latest Norton Ghost, then using IDE-TO-USB converter cable plugged the new drive to the laptop, and used the "duplicate drive" option of Ghost to mirror the old drive to the new one. After that, I removed the old drive from the laptop and installed the new one, booted the laptop and pressed the Blue button... just to learn Ghost failed to mirror the drive properly. I don't know exactly what happened, but the Blue button was not giving the usual options, throwing an error message instead. I tried several other drive mirroring tools and none worked (it took several days, installing the mirroring soft, executing the mirror operation and learning it failed). Then I realized I would not do it with "normal" tools. IBM Predesktop is simply not visible to them the way it should be.

So I started digging The Net and here is what I learned:

The predesktop area is not a legal partition. Most (if not all) of the mirroring software just can't see it.
When you get to the "Recover to factory..." option via the blue "Access IBM" button at startup, there is a hidden exit by pressing F3. It brings you to the command shell (DOS). Once there, you may use fwbackup.exe and fwrestor.exe applications you will find there. Fwbackup backs up the predesktop area somewhere, and fwrestore does the opposite.

So now my new HDD upgrade plan was modified to look like this:

Prepare a IDE-TO-USB converter.
Prepare a THIRD (intermediate) HDD (6GB is enough, I used an old drive from some old Toshiba laptop, but generally you can use any USB drive for that (as long as it can be formatted with FAT32).
Prepare a bootable Windows 95 or Windows 98 CD (again from one of my old machines).
Boot Windows normally from the old drive, then connect the intermediate drive over USB and format it using FAT32 filesystem. The choice of FAT32 is because the drive has to be visible after the machine is booted with DOS shell of Win 95/98.
Reboot and press the blue "Access IBM" button, then go to "Recover to factory..." and press F3 (undocumented) to exit to the DOS command shell.
Make sure the intermediate drive is visible (it mounted as drive D: in my case). Go to A:\RECOVERY (A: is a virtual drive mounted during the IBM recovery procedure) and launch FWBACKUP application:
fwbackup size=640 file=d:\backup
This will take fairly long time (2 hours+ in my case), and will produce a set of backup.nnn files on the intermediate drive.
Copy the FWRESTOR.EXE from A: to the intermediate drive (you will need this application to restore the backup.nnn files created in step 6).
Power off the machine, replace the old hard drive with a new, blank one. Leave the intermediate drive with backup files connected over USB.
Boot the computer with the Windows 9x CD (actually do not start Windows, just go to the DOS shell). From there go to the intermediate drive (still conencted over USB) and run:
fwrestor file=d:\backup
This will restore the predesktop area to the new drive. We are almost home...
Reboot, press the blue "Access IBM" and go to the "Recover to factory...". This will setup you a fresh copy of Windows XP, direct from the predesktop area, just transferred over the intermediate drive from your old to the new one. Ufffff......

The nice thing about this rather lenghty procedure is you will recover everything exactly as it was intended to by IBM. Now it is just a matter of updating your Windows to the latest patches (another 3-5 hours), install the applications (1-3 days) and copy over all your passwords and cookies (2 weeks...). Now you know why I hate this process, just hoping the description above will save you some work and time.

Till next time...