RFCOMM DISC dlci=0 missing after server closesocket?
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
Marcel Holtmann
maintainerHi Art,
Quoted 7 lines
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.
Quoted 7 lines
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
Marcel Holtmann <marcel <at> holtmann.org> writes:
...
Quoted 1 line
the Linux kernel 2.6.22 should behave according to the specification.
Thanks. That was fast! My Ubuntu Feisty is at 2.6.20-16. As far as I can tell, Ubuntu packages for 2.6.21 or 2.6.22 are not yet available, and 2.6.22 is barely two weeks old. Are you aware of any distributions that use 2.6.22 yet?
-------------------------------------------------------------------------
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
Marcel Holtmann
maintainerHi Art,
Quoted 5 lines
Quoted 1 line
the Linux kernel 2.6.22 should behave according to the specification.
Thanks. That was fast! My Ubuntu Feisty is at 2.6.20-16. As far as I can tell, Ubuntu packages for 2.6.21 or 2.6.22 are not yet available, and 2.6.22 is barely two weeks old. Are you aware of any distributions that use 2.6.22 yet?
the upcoming Ubuntu Gutsy should be based on 2.6.22. Otherwise you can test with the latest Maemo kernel if you have a N800. The patch should be included there.
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
Quoted 1 line · Marcel Holtmann <marcel <at> holtmann.org> writes:
the upcoming Ubuntu Gutsy should be based on 2.6.22. ...
Fix confirmed in 2.6.22-7 with Tribe 2 of Ubuntu Gutsy. Thanks.
Can you suggest any application workarounds, however obscure they may be, for earlier kernels?
-------------------------------------------------------------------------
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
Marcel Holtmann
maintainerHi Art,
Quoted 6 lines
Quoted 1 line
the upcoming Ubuntu Gutsy should be based on 2.6.22. ...
Fix confirmed in 2.6.22-7 with Tribe 2 of Ubuntu Gutsy. Thanks.
Can you suggest any application workarounds, however obscure they may be, for earlier kernels?
there exists no workaround I know of.
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
Quoted 1 line · Marcel Holtmann <marcel <at> holtmann.org> writes:
there exists no workaround I know of.
Bummer. Thanks nonetheless.
-------------------------------------------------------------------------
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