I have tried a number of times in the past to get my Sony Ericsson P900 connected to my workstation (which runs Debian GNU/Linux Testing with the odd bit of Unstable, basically Mono and a couple of C# applications) either by Bluetooth or using the USB cradle. I have never managed to achieve the real goal which is managing the phone's filestore from the workstation and synchronizing the phone with Evolution. This time I decided I had to get it all working.
Getting basic file transfer using Bluetooth is actually relatively easy. I am running kernel 2.6.8-2 which means that all the necessary bits that need to be in the kernel are already in the stock kernel. So by loading the standard Bluetooth packages and getting Edd Dumbill's Gnome Bluetooth packages and using gnome-obex-server and gnome-obex-send I have Bluetooth file transfer in both directions. The site I used as a driver for my actions was Stefan Bellon's page on Debian GNU/Linux and the P900.
Next step was to follow Stefan's instructions for getting p3nfs working. The p3nfs package downloads and installs fine. Stefan then says load nfsapp into your phone. OK, so where is nfsapp? It is not in the downloaded package anywhere as far as I can see. Looking in /usr/share/p3nfs, it seems the package includes the source and you are supposed to build it yourself but that means loading the whole Symbian SDK in order to do the compilation. On speculation I downloaded the p3nfs source package and there was a precompiled file: bin/nfsapp-2.8-UIQ.sis. I used gnome-obex-push to send it to the phone and it worked nicely. Well it started and seemed to be behaving sensibly anyway. I wonder if the p3nfs packager needs to think a bit more carefully about the p3nfs binary package so that the prebuilt nfsapp actually arrives with the binary package.
Stefan's page then tells you to configure the rfcomm stuff which is easy except that he doesn't mention how to get the , i.e. the bluetooth address of the phone. He assumes you know that using "hcitool scan" gets you the information. OK so /etc/bluetooth/rfcomm.conf is set up. Stefan then says run "p3nfsd -UIQ -tty /dev/rfcomm11 -dir " (where for me is /media/RLW-P900) after having started nfsclient (presumably nfsapp!) on the phone -- NB I had already added set uid on the p3nfs command. Easily done and fails. I got:
|> p3nfsd -UIQ -tty /dev/rfcomm11 -dir /media/RLW-P900 p3nfsd: version 5.15, using /dev/rfcomm11 (115200), mounting on /media/RLW-P900 /dev/rfcomm11: No such device
but of course it is there:
|> ll /dev/rfcomm11 crw-rw---- 1 root dialout 216, 11 2005-02-18 19:28 /dev/rfcomm11
and I am in group dialout and p3nfs is set uid so I can run it as me rather than root. I emailed Stefan about this and we agreed that it may well be a udev problem. More experimentation needed to sort this out.
So I then looked at the p3nfs documentation (/usr/share/doc/p3nfs/doc/bluetooth.linux). It proposes using /dev/rfcomm0 rather than /dev/rfcomm11 and performing the rfcomm port binding manually rather than using the configuration file. I notice that the p3nfs documentation assumes you already have nfsapp (or is it nfsclient :-) loaded on the phone but following the instructions at least caused some communication between workstation and phone. Starting the nfsapp on the phone already starts the Bluetooth mode (despite what the documentation says in Point 7, do "rfcomm bind /dev/rfcomm0 11" as root or using sudo followed by "p3nfsd -UIQ -tty /dev/rfcomm0 -dir /media/RLW-P900" and I get a dialogue on the phone asking if I wish to accept the connection. Looking good. Press accept. And it worked. Amazing :-)
|> p3nfsd -UIQ -tty /dev/rfcomm0 -dir /media/RLW-P900 p3nfsd: version 5.15, using /dev/rfcomm0 (115200), mounting on /media/RLW-P900 p3nfsd: to stop the server do "ls /media/RLW-P900/exit". (pid 22305)
I was then able to wander around the A:, C:, D: and Z: drives of the phone from the workstation. Wonderful. OK, it may seem sad to find such a trivial thing exciting but it is progress and a lot further than I have got before.
Further experimentation indicates that using /dev/rfcomm11 works fine as Stefan said it would if the binding is done manually rather than relying on the /etc/bluetooth/rfcomm.conf file. I guess Stefan's instructions would have worked if whatever it is in the rfcomm system was doing what it should be doing. I guess the manual bind forces something that doesn't happen if you rely on the rfcomm configuration to do the binding. More experimentation needed.
Anyway enough for now. Next I try the cradle.