I just got a Treo 700p and wanted to sync it to my ThinkPad X41 laptop, running FreeBSD 6.1-RELEASE, using the Treo's USB cable and the pilot-link software package. While apparently this kind of thing has worked in previous releases, I couldn't get past a nondescript error in the bowels of the USB protocol stack.
Both my Treo and my laptop have Bluetooth, and in theory it is possible to Hotsync this way. The Treo is able to run the Hotsync protocol over either a Bluetooth RFCOMM "virtual serial port" or over an RFCOMM "dialup networking" (DUN) connection. The pilot-link Bluetooth HOWTO document talks about how to do Network Hotsync (that is, over TCP) on top of a DUN connection on top of Bluetooth, but that requires setting up a bunch of network infrastructure including a PPP server. I suspect there are also security considerations embodied in the suggestion to specify a Hotsync port of net:any to pilot-xfer. All in all it seemed more desirable to follow the "virtual serial port" approach.
The FreeBSD Bluetooth infrastructure comes with a program, rfcomm_sppd, which will connect the FreeBSD machine to a virtual serial port offered by a remote Bluetooth server, but (as shipped with FreeBSD 6.1) it won't create and advertise a virtual serial port which remote devices such as my Treo can connect to.
patch.rfcomm_sppd.c is a patch which adds a server mode to rfcomm_sppd.
Usage notes:
- Run rfcomm_sppd -S -t /dev/ttyp9 and then pilot-xfer -p /dev/ttyp9 and then launch HotSync on your Palm device. You'll need to have paired the devices, of course.
- If your Palm device crashes (!!), make sure your FreeBSD machine is running sdpd. If your Palm reports "the port is already in use", what it probably really means is that it was unable to contact your FreeBSD machine, find an appropriate server registered (use sdpcontrol -l browse to see what you're offering), and connect to it. Lucky thing the message is so specific, eh!
- Since the Service Discovery Protocol daemon (sdpd)
allows only root to register services, you must run rfcomm_sppd
as root, and it will thus
chown()the pseudo-tty device to root, group "tty". So you must run pilot-xfer as root (which I would otherwise not recommend) and either manually chmod 666 /dev/ttypxxx, or add yourself to group "tty". - The patch does not modify the one-shot nature of rfcomm_sppd, which will run one session and then exit.
- Pending official interest in the patch, I have not updated the man page.
- In server mode, if you specify a Bluetooth address for the peer device, incoming connections from anybody but that device will be rejected.
I hope this helps somebody. In general I think that the virtual serial port model makes more sense for the average user than the DUN model, and would like to see it more widely available.
Status: I sent the patch to the author and also submitted it as a a FreeBSD change request (submitted 2006-08-25; accepted with modifications into -current 2007-01-25).
