My original goal was to connect the SE M600i smartphone of my wife to the Internet through Bluetooth via my desktop PC. For a trip to Hamburg I wanted to experiment with navigation software running on the mobile phone.

I got it working in the end, more or less, but overall this was an experience, where I really envied the Windows and Mac OSX folks, who click a few dialog boxes and are then ready to go. The lack of user-level documentation was annoying in particular. It seems, that the Bluez is currently in the transition phase to a new service framework and all the documentation, you’ll find via Google still describes the the pre-service framework situation.

It took several passes, recompilation with additional Gentoo USE flags, looking at the sources code, a missing network.conf file, which wasn’t installed. Anyway I didn’t get it working with the new service framework. The last obstacle are probably these lines form the /var/log/messages, which I don’t know how to fix.

Nov 23 13:20:00 trio network[947]: Can't create GN bridge
Nov 23 13:20:00 trio network[947]: Can't create NAP bridge

This Debian oriented document finally helped me to get it at least working with the older pand-daemon. Instead of the iptables NAT setup, I simply used an Apache 2.2 web server operating as a proxy. This worked just as well. This whole stuff is still a pretty much manual approach however.

Finally the server move has been successfully completed. My encoding problems turned out to have something to do with MySQL session setup concerning the responses of an SQL query.

On the old server with MySQL 4.x and WordPress 2.0.x I was using this combination already with UTF-8 encoding although WordPress 2.0.x is originally intended for ISO-8859-1 only. However no encoding changes took place on the way from the database to the browser, so this was actually no problem.

On the new server the database base (now MySQL 5.0.x) is operating with the default encoding of ISO-8859-1. Now the UTF-8 data within the tables was converted to ISO-8859-1 character, which resulted funny looking articles with German umlaut characters. After having finally found this article and having set DB_CHARSET and DB_COLLATE in the wp-config.php files, everything is good again.

Changing versions of multiple components at the same time has always the increased risk, that something get screwed up along the way.