Sony-Ericsson V600i and Bluetooth

Who needs Windows to transfer files to/from the cellphone?

Copyright © 2006-2024 Howard Pritchett.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is available from the Free Software Foundation.

For various reasons I decided to switch cellphone operators earlier this month. I also decided to use the changeover as an opportunity to enter the 21st century and get myself a phone with better networking capabilities, and decided on the Sony-Ericsson V600i, which is a 3G phone with the ability to communicate with a computer via the provided USB cable, over a bluetooth connection or via infrared. I'd browsed over several howto pages on the 'Net, which all tended to demonstrate that it was possible to do this using Linux − I didn't want a setup that would work only with Windows. The main idea was that the 1.3 megapixel camera in the phone would more than likely take better pictures than my ageing, sub-megapixel Konica Q-M100 camera (and it does…), and I'd be able to use it when taking pictures for sites I put together. Obviously, I'd need some way of offloading the pictures from the phone's slightly limited memory (about 29MB usable) while on site, ideally using my laptop and some kind of connection to the phone.

I found no way to transfer files using the cable or the infrared port using Linux. While they worked fine in Windows, I wasn't about to let a jumped up lump of plastic get the better of a penguin, especially as the Windows software provided really sucks. It puts black holes to shame, and (what passes for) the Sony-Ericsson customer service really doesn't give a damn about its suckiness.

I'd read that support of Bluetooth USB dongles was good in the Linux kernel, so I decided to investigate that avenue. What the hell, those devices are dirt cheap nowadays (I got mine for about US$12) so even if it doesn't work it's no big deal. Mine turned up late yesterday morning. I had to go out for most of the afternoon, but by the evening I was happily beaming data between the phone and the laptop.

In order to get this working you need three levels of software:

BlueZ (Linux Bluetooth stack) and hardware support in the kernel
BlueZ userland support applications
End-user applications

1 − Kernel BlueZ and hardware support

If you're using the stock kernel of a major distribution then the chances are that support for Bluetooth and your dongle are already provided. Insert the dongle into a vacant USB port and wait for a few seconds, then in a console, run /sbin/lsmod. If you see modules such as bluez (for 2.4.x kernels) or bluetooth (for 2.6.x kernels), rfcomm, hci_usb and l2cap listed, then you're already in business and you can skip straight to part 2. If not, read on because you're going to have to add some stuff to your kernel. Since you're not using a stock kernel, you've probably already compiled your own so I'll make no attempt here to explain how to build one. If you don't know how to yet, you can search the web and find plenty of documents that explain how to go about it.

I'll be assuming henceforth that you're using the "make menuconfig" method. The areas in which you'll find what needs to be added to your kernel depend on the kernel version you're using:

For 2.4.x kernels

These screenshots are from the configuration of a 2.4.32 kernel. Note that there were some issues with older versions, around 2.4.11 or 2.4.12. However, if you're using something that old, you really should upgrade anyway.

Find "Bluetooth support" in the main configuration page:

Select elements as follows:

Then move into "Bluetooth device drivers"
and select elements as follows:

For 2.6.x kernels

These are screenshots from the configuration of a 2.6.16.11 kernel:

Find the "Networking" option
and enter its submenu:

Select "Bluetooth subsystem support" as a module:

Then enter the submenu and
select options as follows:

Enter the "Bluetooth device drivers" submenu
and select options as follows:

The options described here are obviously in addition to what you need for the normal operation of your system… They're also rather kitchen-sink-like in that many of them aren't needed for this, but since I'm no expert at this level I thought it best to let hotplug deal with what's needed and what isn't.

Build the new kernel, install it and reboot. Plug the dongle in, wait for a few seconds and inspect the list of loaded modules again (/sbin/lsmod). You should see the required modules this time.

If your /dev directory is managed dynamically by udev then you need not concern yourself with this part because the /dev/rfcomm0 device node will be created automatically for you when the appropriate modules are loaded. If, however, you manage your /dev directory's device nodes yourself then the chances are that you'll need to create this one:

# mknod --mode=660 /dev/rfcomm0 c 216 0
# chown root:uucp /dev/rfcomm0

Users who are to be granted access to the Bluetooth subsystem should be made members of the "uucp" group.

2 − BlueZ userland support applications

Now that the hardware and the Bluetooth stack are handled by the kernel, we need a few low-level tools to manage this network. This is the function of the BlueZ utilities available from bluez.org.

Here too, it might well be that these tools were already installed along with your Linux distribution. "su -" to root and run this (assuming that your USB dongle is still plugged in):

# hciconfig
hci0:   Type: USB
        BD Address: 00:11:22:33:44:55 ACL MTU: 377:10 SCO MTU: 16:0
        UP RUNNING PSCAN ISCAN
        RX bytes:136 acl:0 sco:0 events:18 errors:0
        TX bytes:323 acl:0 sco:0 commands:17 errors:0

If you get something that looks approximately like this then the BlueZ utilities and the necessary underlying libraries are already installed. You can skip to part 2b. Otherwise, read on.

I assume you're familiar with the methods involved in decompressing source packages, and configuring and then building the software. There are no particular things to look out for with the packages involved here, they're straightforward autoconf'ed packages which use the standard "./configure, make, make install" cycle with the appropriate --prefix options and optionally --sysconfdir for the bluez packages. The --prefix for the kde-bluetooth package mentioned later obviously should be the directory where your KDE setup is.

Build and install bluez-libs first of all, then bluez-utils. As mentioned on the downloads page of the bluez.org site, you probably won't need the other two packages, but it won't hurt to install them anyway just in case.

Now attempt to bring the Bluetooth network interface up and check again that the operation was successful:

# hciconfig hci0 up
# hciconfig
hci0:   Type: USB
        BD Address: 00:11:22:33:44:55 ACL MTU: 377:10 SCO MTU: 16:0
        UP RUNNING PSCAN ISCAN
        RX bytes:136 acl:0 sco:0 events:18 errors:0
        TX bytes:323 acl:0 sco:0 commands:17 errors:0

So far so good, now we can scan for the phone and "ping" it to ensure that the communications channel will work:

# hcitool scan
Scanning ...
        00:12:34:56:78:9A       V600i

The various "BD" addresses you see on this page are kind of Bluetooth's answer to a MAC address on a regular IP network. It identifies the device in question so that other devices know with whom they're connected and chatting. Therefore, for obvious security reasons, I have not used the real BD addresses of my USB dongle or my cellphone. Instead, I've used 00:11:22:33:44:55 for the USB dongle and 00:12:34:56:78:9A for the phone.

Next thing to do is to "ping" the cellphone to check that all's well (hit Ctrl+C to stop, and that command l2ping starts with a lowercase "ell", not a figure "one"):

# l2ping 00:12:34:56:78:9A
Ping: 00:12:34:56:78:9A from 00:11:22:33:44:55 (data size 44) ...
44 bytes from 00:12:34:56:78:9A id 0 time 48.25ms
44 bytes from 00:12:34:56:78:9A id 1 time 20.32ms
44 bytes from 00:12:34:56:78:9A id 2 time 22.13ms
44 bytes from 00:12:34:56:78:9A id 3 time 22.98ms
44 bytes from 00:12:34:56:78:9A id 4 time 22.32ms
44 bytes from 00:12:34:56:78:9A id 5 time 43.41ms
44 bytes from 00:12:34:56:78:9A id 6 time 21.38ms
44 bytes from 00:12:34:56:78:9A id 7 time 21.21ms
44 bytes from 00:12:34:56:78:9A id 8 time 22.05ms
9 sent, 9 received, 0% loss

2b − Configuring the software

All Bluetooth devices authenticate against your network with a PIN code. You will need to set the PIN for your computer before you pair it with your phone. There are several ways you can manage this, this is how I did it.

You will have three configuration files in your /etc/bluetooth directory if you're using the software as it was set up for your distribution, or maybe /usr/etc/bluetooth or /usr/local/etc/bluetooth depending on how you built the software when you installed it. The file pin should be readable only by root and should contain the PIN that you'll have to enter into the phone when trying to pair it with the computer. I'll use 1234 here, replace with the PIN you want to use. Also, adjust the path in the first command below according to the location of the Bluetooth configuration directory on your system:

# cd /usr/local/etc/bluetooth
# echo 1234 > pin
# chown root pin
# chmod 600 pin

Next, you'll need to create a wrapper script that'll be used as the "PIN helper" for the hcid daemon. The "PIN helper" is a small application designed to print out "ERR" in the event of a problem, or "PIN:####" (with #### obviously being the real PIN) otherwise. Create this script in /usr/local/sbin, call it "btpin" and make it executable, obviously adjusting the paths mentioned according to your system:

#!/bin/sh

/usr/bin/echo -n "PIN:"
/usr/bin/cat /usr/local/etc/bluetooth/pin

Next, we need to tell hcid to use this PIN helper. Load hcid.conf into your favorite text editor and make these changes. Edit the line in the "options" section of this file so that it reads like this:

        # PIN helper
        pin_helper /usr/local/sbin/btpin;

Also adjust the name in the "device" section. This is the name that your cellphone will present to you in the list of devices it finds when you get it to scan for your computer prior to pairing them together. I suggest you use something fairly explicit and unambiguous. I used this:

# Default settings for HCI devices
device {
        # Local device name
        #   %d - device id
        #   %h - host name
        name "Laptop (%h)";

The third configuration file, rfcomm.conf, would appear to have no effect for this particular application. The information in it does not reflect the real BD address of my phone. We'll leave this be.

With these adjustments made, we can now start 2 daemons that are going to help manage Bluetooth sessions:

# hcid
# sdpd

Make sure these daemons are started at boot-time. There are many ways different distributions achieve this. Refer to your distribution's insctructions. On a Slackware system it's simply a question of adding this to the end of your /etc/rc.d/rc.local file:

echo "Starting Bluetooth stuff..."
/usr/local/sbin/hcid
/usr/local/sbin/sdpd

The next step is to pair the computer and the phone together. Make sure Bluetooth is active on the cellphone and scan for devices from it (Menu / Settings / joystick left to reach the "Connectivity" tab / Bluetooth / My devices / New device). You will be prompted to ensure that the other device (your computer) is powered with Bluetooth on, and that you have the PIN ready. It will then scan for live Bluetooth devices and should find your computer and display it using the name you defined in the hcid.conf file earlier. Select this device. You will be prompted for the PIN, so enter the one you stored in the pin file earlier. If all went well, your phone should tell you that the computer was added to the phone's list of "My devices".

Optionally, you can allow the computer to connect to your phone without your having to authorize each attempt. Scroll to the computer in the phone's "My devices" list, press the "More" button, "Allow connection", select "Always".

Now we can move on to the end-user applications with which we're going to be doing the file transfers.

3 − End-user applications

The two applications we're going to be using here are kbluetoothd and kbtobexclient, which are part of the kde-bluetooth project. kde-bluetooth itself requires bluez-libs and bluez-utils that you installed earlier, and also Openobex, which is a set of libraries that implement the Open Object Exchange protocol.

Before downloading and installing software for nothing, start by checking whether the required software is already provided with your distro. Check for kbluetoothd in your current $PATH:

# which kbluetoothd
/opt/kde/bin/kbluetoothd

If you get the fully-qualified path to the kbluetoothd executable back then the software is already installed and you can skip this paragraph. If not, then download the Openobex and kde-bluetooth sources from the links given above, build and install Openobex first and then kde-bluetooth.

From this point onwards all the software you'll be needing is installed and no further system-wide configuration is required. You can therefore drop down from your escalated privileges back to your usual user.

Now start the kbluetoothd daemon discarding the pages of debug information you'll be given. There's so much of the stuff spewed out that it's impossible to find anything worthwhile in there:

$ kbluetoothd > /dev/null 2>&1

If you're using a kernel prior to 2.6.10-mh3 you'll receive a warning that a security feature is missing. Click on the "Details" button for full information:

Additionally, the first time kbluetoothd is started, you'll be asked if you want to use the PIN helper supplied with the kde-bluetooth package:

Since we've already taken care of the PIN problem, we ask kbluetoothd not to show this message any more so that we can get on with what we want to do.

One last step needs to be taken before the setup is complete. You need to ensure that kbluetoothd is started automatically whenever your X session is started. In most cases, whatever was running when X was last shut down will be started again when you start X up again. If not, then:

For KDE:

# mkdir -p $HOME/.kde/Autostart
# ln -s `which kbluetoothd` ~/.kde/Autostart

For XFCE:

# mkdir -p $HOME/Desktop/Autostart
# ln -s `which kbluetoothd` ~/Desktop/Autostart

For other desktop managers:

Consult your DM's documentation.

Pushing a file from the phone to the computer

Using this communications model, it's the sender of the data who initiates the session. Simply browse to a picture or movie you've shot with the camera, or to a sound such as a ringtone, "More" button / Send / Via Bluetooth. You will be presented with a list of devices to which you can send it − your computer should be in there, so scroll to it and press the "Select" button. The computer will ask you if you want to allow the connection from the phone:

Using the drop-down in this dialog you can inform the computer whether the connection policy should remain unchanged, whether you should be prompted each time, or whether the incoming connection from the V600i should be allowed (or denied) implicitly for future connections. How you manage this is up to you but should be decided upon with security in mind. Bluetooth is not an overly secure protocol, but if, like me, your Bluetooth network is only up when you need it to transfer files, then you can set the policy to "allow".

Next you are informed that you can always make changes to your decision later on:

This assumes you're using KDE as your desktop manager. I'm not, I use xfce personally, but I do have the base KDE libraries installed for the few KDE applications that I really find useful (this is one of them, another is konsole, and a third is kppp). However, kbluetoothd also sets up an icon in your taskbar. You can therefore change these settings by right-clicking on the KBlueTooth icon / Configuration... / Configure services... / "Confirmation" tab.

Assuming you agreed to the connection, the transfer will commence. A progress bar in this dialog (it says kB when it should in fact say %…) lets you know how much of the file currently being transferred has been pushed through the pipe and is greyed out once all the files selected on the phone (you can indeed select multiple files to transfer) have been pushed over:

Once the transfer is finished, the "Save" button is enabled. Clicking on it will have the effect of copying the files received into the directory ("destination folder") specified just above, which you can change by clicking on the "Browse" button just to the right of it, and, if the "Open destination folder" checkbox is checked, opening up a Konqueror window on that directory. If, on the other hand, you click on "Cancel", the files received are discarded.

Pushing a file from the computer to the phone

Here too, it's the sender of the data who initiates the connection and pushes the files to the other device. The phone recognizes a few filename extensions and will deposit the received files automatically into the appropriate folder (Sounds, Pictures etc…).

You'll be using the KDE Bluetooth OBEX client for this, so fire it up (the command is kbtobexclient − you might want to add a shortcut to it on your desktop or in your panel) and make sure that Bluetooth is active on your phone and that it's visible to other devices:

The OBEX client will start by scanning for available bluetooth devices. Once your phone has been found, it will appear in the "Device selector" pane and, if it's the only device found, it'll be selected and its BD address shown in the status bar. I have blurred the BD address of my own phone for obvious security reasons.

Now, all you have to do is use the top part of this window to navigate to the file(s) you want to upload, select the file(s) to send to the phone, then drag it/them into the "File to send" pane:

Now simply click on the "Send" button. The phone will ask you if you want to accept the file being sent for each file. It's a bit annoying but no software is perfect, right? Also, after the last file has been transferred, the phone will warn you that the connection was lost. This doesn't seem to affect the transfer itself because the last file is indeed transferred correctly.

That's it − you're done! Don't forget to bring down the Bluetooth network once you've finished. Turn off Bluetooth on your phone unless you're using a wireless headset (don't forget to engage "Power saving" on the phone in that case since it will prevent other Bluetooth devices from connecting to it if one is already connected), and pull the dongle out of the computer's USB port.

A few tips:

Regardless of the range boasted by the manufacturer of your USB dongle, you will always be limited by the device with the shortest range, and that's the phone in most cases. Don't expect this to work if your computer is more than about 20 feet away from the phone. That's about the limit here (it's considerably less if the RF signal has to go through walls), even though the dongle is supposed to have a range of 70 meters (that's about 230 feet). Things may be closer to that somewhat optimistic specification if you're setting up a connection between two identical dongles.
Nowhere in the phone's user manual or anywhere else on the 'Net was I able to find the resolution of the V600i's screen. Through trial and error and looking at photos that were already stored in the phone when I had it new, I deduced that the screen resolution was 176×220 pixels. Hopefully google will pick this page up not too long from now and others looking for the same answer will be directed here. You might want to keep that screen resolution in mind when creating your own wallpapers. If I get time I might create a few myself from photos of my own or from images generated with POV-Ray and link to them from here.
Totally unrelated to Bluetooth but good to know… The buttons on the sides of the phone (video call on the left, Internet access on the right) are far too easy to press inadvertantly if you have the phone in your pocket, handbag, whatever, and the services accessed are not cheap. Always keep the phone's keyboard locked ("*" key followed by the right menu key) unless you're sure nobody's going to run you up a huge bill by connecting the phone to the Internet for a couple of hours!
The V600i does have PDA functions. You can store ToDo lists, appointments etc… and synchronize your contacts list with a computer, but that is absolutely nothing to do with this howto. For that, you might find KMobileTools useful. I'll not cover any of that particular use of the V600i because, owning a PDA already, I have no need for these features on the phone.

A footnote about Sony-Ericsson's attitude to customers

When I first received the phone, I had to install Windows 2000 on my laptop in order to exchange data between the two devices using the provided USB cable (or the infrared port). Given that the software does install device drivers, I found it normal that it should be installed by an administrator rather than a normal user, even a power user.

The software itself is divided into 6 parts:

The device driver enabling the phone monitor to communicate with the phone.
The phone monitor itself, which scans for the phone's presence and, if found, integrates access to the phone's memory into the Windows Explorer.
A sync manager to sync the phone's contacts with your address book and its calendar with that of Outlook.
A file transfer application allowing the user to transfer files to/from the phone's memory.
An MMS creation studio.
Mobile tools allowing you to use the phone to dial up to the Internet and use it as a straightforward modem connected to your PC by cable, infrared or (presumably) Bluetooth.

Device driver

This would appear to work as advertized since the phone monitor detects the phone's presence and data communication can take place.

Phone monitor

This is a real piece of garbageware.

Since the laptop was a dual-boot system (W2000/Linux), and since Windows is clearly incapable of managing daylight saving time without resetting the system clock, I decided to set the laptop's system clock to GMT and tell Windows not to adjust it for Summer/Winter time. Linux handles this extremely gracefully whatever you decide to do with the clock.

The cellphone, on the other hand, is set to local time, and the timezone is set accordingly. So, when the PC says that it's 16:00 GMT and the phone says that it's midday GMT -0400, that's the same time, right? Not acording to the phone monitor. A message pops up asking me if I want to sync the phone's clock to the PC's clock. In that dialog box there's a checkbox that says "Do not ask me this question any more", and the buttons available are "Cancel" and "OK".

If you click on "Cancel" to prevent the time sync from taking place, then the system isn't going to take any notice of the "Don't ask me again" checkbox. It should do if you click on "OK" and subsequently reset the phone's clock to the right time (remember, the crapware phone monitor very thoughtfully just set your phone's clock to the wrong time), but it doesn't anyway. There is no way to prevent the phone monitor from bugging you about the phone and the PC being set to different times, even if they aren't.

My next step was to uninstall the software provided with the phone and to download the latest version from the Sony-Ericsson website in the hope that the bug would have been corrected. No such luck. Not only is that particular bug still present in the software, but now, whenever you connect the phone, the system says it's about to install something (you have no idea what) and then it bombs out. Solution: keep hitting the Escape key when you plug the phone in.

And people wonder why I hate having to use Windows…

In the end, I wrote to SE customer service:

I've found what appears to be a bug in your PC-Suite software (V1.7.10 that I've just downloaded) that I use with my V600i terminal.

Environment:
Windows 2000 Pro SP4
PC Suite 1.7.10

My PC's system clock is set to GMT for various reasons. When I connect my V600i (which is set to local time) to the PC, the Phone Monitor asks me if I want to set my phone's clock to the PC's clock. I obviously don't, and if you click on "Cancel" instead of on "OK", the Phone Monitor doesn't take into account the status of the "Don't ask me again" checkbox.

If I go into the Windows Control Panel, "Phone Monitor options", "Setup" tab and uncheck the "Allow synchronizing of the PC and phone clock" checkbox, the setting doesn't stay. If I return to that control panel having previously applied the setting and closed it, the "Allow synchronizing....." checkbox is checked again.

The software was installed by a Windows 2000 administrator. Indeed, device drivers are installed during the process so requiring administrator rights seems perfectly normal to me. However, I use the software as a Power User. If it is necessary even to use the software as an administrator, maybe that's something you should put right?

Three days later I received this (useless) reply:

Thank you for contacting Sony Ericsson customer relations.

Please set the clocks on your PC and on the V600i (time, timezone, country) and reinstall the PC Suite.

Ya think? Guess what I'd already done before contacting them…

I sent them this reply straight away:

The problem remains.

The PC is set to GMT. I want it to remain set to GMT.

The V600i is set to local time. I want it to remain set to local time.

The timezone on both devices is set correctly.

There is no way to instruct the Phone Monitor not to ask if the user wants to synchronize the phone and PC clocks. This is a bug.

That was nearly 2 weeks ago. No reply (surprise, surprise).

Sync manager and file transfer

These tools would appear to work correctly. No problems with the file transfer applications whether you're using the USB cable or the infrared port (I never tried it with Bluetooth). The sync manager does indeed sync your Windows address book as advertized. I've never had the misfortune of having Outlook on any of my machines so I can't tell you if that part of the deal works or not.

MMS creation studio

This doesn't work at all. Whatever you attempt to do you just get blown off with a "Can't load file" error message. The only thing you can do is quit the application.

Mobile tools

I didn't try these.

All of this is obviously irrelevant now since I've found a way to do what I want using Open Source tools that don't require me to run badly designed software on a badly designed operating system. I do, however, have sympathy for the millions of users out there who are stuck with Windows or who don't even know that there are far superior alternatives.

NAVIGATION:
>> /

Last update: 24-OCT-2006
This page has been served 41005 times since 27-APR-2006