On Fri, 2009-02-06 at 16:55 +0100, Ilya Bakulin wrote: > On Fri, 6 Feb 2009 10:01:11 +0000 > Mark Ellis <m...@mpellis.org.uk> wrote: > > > > As I remember, Mark did some steps to support syncing via BT. FreeBSD now > > > lacks "ActiveSync" BT profile support, but as I see in Linux dund > > > sources, it's simple to add it -- just register another SDP service UUID. > > > I'll try to do so next week -- probably FreeBSD will get BT sync support > > > then... > > > > > > > If you make any progress with WM5/6 BT connections I'd love to hear > > about it, I got it to work once but haven't been able to duplicate that > > success since, very frustrating, WM2003 on the other hand works > > perfectly. > > > > Mark > > > > > > It works! :-) > It even doesn't need BT PAN networking! > > So, here is my way to sync via Bluetooth. Though it may be FreeBSD-specific, > general idea should be the same on all *nixes... > > Windows ActiveSync (on desktop side) uses serial connection to communicate > via Bluetooth -- if you setup BT sync, you need to specify COM port number. > So, our task is to create virtual COM port and make our soft communicate via > it. > > In FreeBSD, there is a special program called "rfcomm_sppd". I invoke it as > follows: > > # rfcomm_sppd -S -c 16 -t /dev/ttyp2 > -S --> work in server mode; > -c 16 -- register itself at SDP on RFCOMM channel 16 (0<chan<30, could be > chosen by magic dice); > -t /dev/ttyp2 -- connect to master TTY "ttyp2". >
Look like the BSD commands are going to be completely different to the linux ones, which I guess is no surprise. Did you not need to specify which services to advertise ? I always assumed that was what was causing my problems. > Now we have /dev/ttyp2 as a pipe which represents virtual COM port. > Attached Python script is a standalone version of hal-synce-serial addon, > which invokes pppd on /dev/ttyp2. This way it connects pppd to other side of > pipe. > > Our FreeBSD PC is ready to accept connections via SPP profile, and it > advertises SPP via SDP. > > I have ASUS P535 with Broadcom Bluetooth stack. So I have to describe further > steps using this stack. Hope M$ stack has the same features... > Broadcom stack has an "ActiveSync via Bluetooth" option in Connection Master. > I select this option, select my PC in devices list. It finds!!! ActiveSync > connection and allows me to create a shortcut for it. > After that, it connects to my SPP service, passes all usual negotiation, > finally connection is established. > > I see following in /var/log/messages: > > ======================================= > Feb 6 18:38:28 kibab-nb pppd[23822]: pppd 2.3.5 started by kibab, uid 0 > Feb 6 18:39:13 kibab-nb pppd[23822]: Connect: ppp0 <--> /dev/ttyp2 > Feb 6 18:39:16 kibab-nb pppd[23822]: Received bad configure-nak/rej: 12 06 > 00 00 00 01 > Feb 6 18:39:16 kibab-nb pppd[23822]: local IP address 192.168.131.3 > Feb 6 18:39:16 kibab-nb pppd[23822]: remote IP address 192.168.131.131 > Feb 6 18:39:21 kibab-nb hal-dccm[23818]: CRITICAL: synce_device_init: failed > to initialize direct hal context: (null): (null) > Feb 6 18:39:21 kibab-nb libhal.c 1884 : LibHalContext *ctx is NULL > Feb 6 18:39:21 kibab-nb hal-dccm[23818]: CRITICAL: > synce_device_set_hal_props: failed to set property pda.pocketpc.name: (null): > (null) > Feb 6 18:39:21 kibab-nb libhal.c 1884 : LibHalContext *ctx is NULL snip... > Feb 6 18:39:21 kibab-nb hal-dccm[23818]: CRITICAL: > synce_device_set_hal_props: failed to set property > pda.pocketpc.hotsync_interface: (null): (null) > Feb 6 18:39:21 kibab-nb hal-dccm[23818]: CRITICAL: > dbus_g_connection_register_g_object: assertion `connection != NULL' failed > Feb 6 18:39:21 kibab-nb libhal.c 3997 : LibHalContext *ctx is NULL > Feb 6 18:39:21 kibab-nb hal-dccm[23818]: CRITICAL: > synce_device_set_hal_props: failed to claim dbus interface: (null): (null) > Feb 6 18:39:21 kibab-nb hal-dccm[23818]: CRITICAL: > synce_device_change_password_flags: failed to set property > "pda.pocketpc.password": (null): (null) > Feb 6 18:39:21 kibab-nb hal-dccm[23818]: CRITICAL: > synce_device_rndis_info_received: failed to notify hal that device is ready: > (null): (null) > Feb 6 18:39:27 kibab-nb hal-dccm[23818]: CRITICAL: > synce_device_change_password_flags: failed to set property > "pda.pocketpc.password": (null): (null) > ======================================= > > Critical errors cause is obvios. There is no device node in HAL that has > pda.pocketpc.* properties -- we've launched hal addon script by hand, hal > itself doesn't know anything about our device... > Of course all commands such as "pls", "pcp" fail now, because they rely on > HAL to get information about connected device. But in fact links exists and > is UP: > > ki...@kibab-nb%ifconfig ppp0 > ppp0: flags=108051<UP,POINTOPOINT,RUNNING,MULTICAST,NEEDSGIANT> metric 0 mtu > 1500 > inet 192.168.131.3 --> 192.168.131.131 netmask 0xffffff00 > > > The main problem is that [on FreeBSD] hal doesn't know anything about ttyp* > devices, so we need to create fake device to add required properties to it, > or use some other approach to retrieve information... Also, we have no way to > be notified about device connection via HAL. Maybe this problem exists only > on BSD, don't know... > I'll give a rundown of how I did it on linux, should be easy to modify to BSD. All the files can be found in synce-hal 0.13 dund (dial up networking daemon, presumably similar to your rfcomm_sppd) is started and listens for connections. When something connects, it calls pppd with the synce-bt-peer peers file, which most significantly sets ipparam to synce-bt so we can distinguish it from other ppp connections. The ip-up script is called as a normal ppp ip-up command, and does nothing if ipparam isn't synce-bt. But this is the sneaky bit :) We use hal-device to create a device node in hal, using the info passed to us by pppd, that looks very much like a device connected by cable. This pseudo device has an addon hal-synce-bluetooth, which fires up hal-dccm, and now you have a normal synce device in hal, which any of the normal clients can use. There is also an ip-down ppp script, which uses hal-device to remove our psuedo device when the link drops. So as long as you can get pppd to call the scripts at the right time, you should have no trouble using the rest of the framework almost without change. Mark
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________ SynCE-Devel mailing list SynCE-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
