weird behaviour with bluez and obex
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Johan,
Quoted 17 lines
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.
Quoted 6 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Quoted 3 lines · Marcel Holtmann
the rfcomm connect method allows you to specific the --raw switch which sets the resulting
/dev/rfcommXdevice into TTY raw mode. By default the echoing is enabled on TTY's and this can cause problems.
This solved the problem. Thanks!
Johan