[Bluez-devel] weird behaviour with bluez and obex

[Bluez-devel] weird behaviour with bluez and obex

[Johan Hedberg]

Hi,

I have been trying to get obex file transfer working with bluez and
openobex by using a local rfcomm device which is bound to the OBEX file
transfer RFCOMM channel of my phone.

The problem I encountered was that the connection was dropped almost
imediately after some bytes were writen to the device. After some
further investigation, it turned out that the connection is always
dropped when more than two bytes are written to the device. This happens
also for OBEX Object Push. Using "rfcomm connect" instead of binding
causes this behaviour also. Other profiles (eg. DUN) do not have
this behaviour.

If I use the bluez socket interface to create the connection everything
works fine (and I guess this is the way most existing BT OBEX
applications work). I also checked with affix (which now also has
binding support) and the problem does not exist there.

The HCI Disconnection Complete event which is generated by the
disconnection has 0x16 (connection terminated by local host) as the
reason parameter, which implies that the problem is not on the phone
side, but in bluez.

Can anyone reproduce this behaviour? Any ideas what's causing it?

I'm using kernel version 2.6.5.

Johan



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] weird behaviour with bluez and obex

[Marcel Holtmann]

Hi Johan,

> I have been trying to get obex file transfer working with bluez and
> openobex by using a local rfcomm device which is bound to the OBEX file
> transfer RFCOMM channel of my phone.
> 
> The problem I encountered was that the connection was dropped almost
> imediately after some bytes were writen to the device. After some
> further investigation, it turned out that the connection is always
> dropped when more than two bytes are written to the device. This happens
> also for OBEX Object Push. Using "rfcomm connect" instead of binding
> causes this behaviour also. Other profiles (eg. DUN) do not have
> this behaviour.
> 
> If I use the bluez socket interface to create the connection everything
> works fine (and I guess this is the way most existing BT OBEX
> applications work). I also checked with affix (which now also has
> binding support) and the problem does not exist there.
> 
> The HCI Disconnection Complete event which is generated by the
> disconnection has 0x16 (connection terminated by local host) as the
> reason parameter, which implies that the problem is not on the phone
> side, but in bluez.
> 
> Can anyone reproduce this behaviour? Any ideas what's causing it?

the rfcomm connect method allows you to specific the --raw switch which
sets the resulting /dev/rfcommX device into TTY raw mode. By default the
echoing is enabled on TTY's and this can cause problems.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] weird behaviour with bluez and obex

[Johan Hedberg]

On Thu, Apr 08, 2004, Marcel Holtmann wrote:
> the rfcomm connect method allows you to specific the --raw switch which
> sets the resulting /dev/rfcommX device into TTY raw mode. By default the
> echoing is enabled on TTY's and this can cause problems.

This solved the problem. Thanks!

Johan