Our RFCOMM application conducts a brief session to validate the application on a
partner device, then terminates the session and gives the user an option to
reconnect to the partner application. When the local application uses the
Microsoft stack or Toshiba stack on a WinXP, and the remote application uses
BlueZ, the user-driven connect fails if issued less than 60 secs before the
first session is disconnected.
This appears to be a flaw in the BlueZ implementation, but I am no expert on the
subject. Is my analysis correct? If it is, can someone suggest a workaround?
The RFCOMM specification from Bluetooth 1.1 says
<< The device closing the last connection (DLC) on a particular session is
responsible for closing the multiplexer by closing the corresponding L2CAP channel.
Closing the multiplexer by first sending a DISC command on DLCI 0 is optional,
but it is mandatory to respond correctly to a DISC (with UA response). >>
I posted a test case, with source code, executables, console output, and an
hcidump trace, at http://65.104.11.121/MissingDisconnect/. The BlueZ server
application accepts an RFCOMM connection, closes the socket 15 seconds later,
then recycles to accept another connection. The client application, written for
the Microsoft Win32 stack, discovers the target service, connects to it, waits
for the disconnection, sleeps 5 seconds, then recycles for one more pass.
In response to a socket close, the server application sends an RFCOMM DISC for
dlci=2 (23:13:50.182534 in the trace). Following receipt of the client's RFCOMM
UA, other servers send RFCOMM DISC for dlci=0. Not so BlueZ. It does
essentially nothing. For clients using BlueZ or a Win32 Broadcom stack, the
client stack compensates for this deficiency. For Win32 clients using the
Microsoft or Toshiba stack, the client waits 60 seconds after the RFCOMM DISC
dlci=2 for an L2CAP disconnect before sending one of its own (23:14:49.948835).
For a Win32 Microsoft client, this 60 second delay blocks the client's
subsequent connect() request. For a Win32 Toshiba client, the delay causes the
connect() request to fail.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Art,
> Our RFCOMM application conducts a brief session to validate the application on a
> partner device, then terminates the session and gives the user an option to
> reconnect to the partner application. When the local application uses the
> Microsoft stack or Toshiba stack on a WinXP, and the remote application uses
> BlueZ, the user-driven connect fails if issued less than 60 secs before the
> first session is disconnected.
>
> This appears to be a flaw in the BlueZ implementation, but I am no expert on the
> subject. Is my analysis correct? If it is, can someone suggest a workaround?
>
> The RFCOMM specification from Bluetooth 1.1 says
>
> << The device closing the last connection (DLC) on a particular session is
> responsible for closing the multiplexer by closing the corresponding L2CAP channel.
the Linux kernel 2.6.22 should behave according to the specification.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel