How to setup a reliable RFCOMM connection

Bluez-users amateur 2 participants 6 messages Dec 8, 2006 – Dec 10, 2006 Bluetooth drivers

Share & tools

amateur

author

2006-12-08 08:45 UTC #0 lore raw

How to setup a reliable RFCOMM connection, that is, a connection with infinite flush timeout. I find the RFCOMM_LM_RELIABLE option in the example program l2test.c. It compiles, but at runtime setsockopt with RFCOMM_LM give me an error. I'm using kernel-2.4.21 patched by patch-2.4.21-mh10. So what's the problem. Doesn't kernel-2.4.21-mh10 support RFCOMM_LM? If so, how can I setup a reliable RFCOMM connection?

Signature · 14 lines

AWAKE! FEAR! FIRE! FOES! AWAKE!
	FEAR! FIRE! FOES!
		AWAKE! AWAKE!
		-- J. R. R. Tolkien

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Marcel Holtmann

maintainer

2006-12-08 10:24 UTC #1 lore raw

Hi,

Quoted 6 lines

How to setup a reliable RFCOMM connection, that is, a connection with infinite flush timeout. I find the RFCOMM_LM_RELIABLE option in the example program l2test.c. It compiles, but at runtime setsockopt with RFCOMM_LM give me an error. I'm using kernel-2.4.21 patched by patch-2.4.21-mh10. So what's the problem. Doesn't kernel-2.4.21-mh10 support RFCOMM_LM? If so, how can I setup a reliable RFCOMM connection?

the RFCOMM channels are always reliable. No need for any other options.

Regards

Marcel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

amateur

author

2006-12-09 01:50 UTC #2 lore raw

Quoted 11 lines · Marcel Holtmann

Hi,
Quoted 6 lines
How to setup a reliable RFCOMM connection, that is, a connection with infinite flush timeout. I find the RFCOMM_LM_RELIABLE option in the example program l2test.c. It compiles, but at runtime setsockopt with RFCOMM_LM give me an error. I'm using kernel-2.4.21 patched by patch-2.4.21-mh10. So what's the problem. Doesn't kernel-2.4.21-mh10 support RFCOMM_LM? If so, how can I setup a reliable RFCOMM connection?
the RFCOMM channels are always reliable. No need for any other options.

Does that mean that the Automatic Flush Timeout Timer for the L2CAP connection underlying the RFCOMM connection is set to 0xFFFF by default? And when does the RFCOMM_LM option introduced?

Marcel Holtmann

maintainer

2006-12-10 12:39 UTC #3 lore raw

Hi,

Quoted 7 lines

Quoted 7 lines
Quoted 6 lines
How to setup a reliable RFCOMM connection, that is, a connection with infinite flush timeout. I find the RFCOMM_LM_RELIABLE option in the example program l2test.c. It compiles, but at runtime setsockopt with RFCOMM_LM give me an error. I'm using kernel-2.4.21 patched by patch-2.4.21-mh10. So what's the problem. Doesn't kernel-2.4.21-mh10 support RFCOMM_LM? If so, how can I setup a reliable RFCOMM connection?

Quoted 5 lines

Quoted 2 lines
the RFCOMM channels are always reliable. No need for any other options.
Does that mean that the Automatic Flush Timeout Timer for the L2CAP connection underlying the RFCOMM connection is set to 0xFFFF by default? And when does the RFCOMM_LM option introduced?

this won't fly. The underlaying L2CAP connection must be reliable and so we are not using an automatic flush timeout at all for that channel. Please check the specification for details.

Regards

Marcel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

amateur

author

2006-12-10 14:10 UTC #4 lore raw

Quoted 11 lines · Marcel Holtmann

Hi,
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
How to setup a reliable RFCOMM connection, that is, a connection with infinite flush timeout. I find the RFCOMM_LM_RELIABLE option in the example program l2test.c. It compiles, but at runtime setsockopt with RFCOMM_LM give me an error. I'm using kernel-2.4.21 patched by patch-2.4.21-mh10. So what's the problem. Doesn't kernel-2.4.21-mh10 support RFCOMM_LM? If so, how can I setup a reliable RFCOMM connection?
the RFCOMM channels are always reliable. No need for any other options.

Quoted 7 lines

Quoted 3 lines
Does that mean that the Automatic Flush Timeout Timer for the L2CAP connection underlying the RFCOMM connection is set to 0xFFFF by default? And when does the RFCOMM_LM option introduced?
this won't fly. The underlaying L2CAP connection must be reliable and so we are not using an automatic flush timeout at all for that channel. Please check the specification for details.

In my understanding of the specification, the Automatic Flush Timeout is applied on a connection handle which corresponds to the ACL link. So does that mean once a RFCOMM connection is established, the automatic flush timeout would be disabled(to ensure link reliability)? Or that bluez doesn't use automatic flush timeout at all for all connections?

Signature · 12 lines

He that is giddy thinks the world turns round.
		-- William Shakespeare, "The Taming of the Shrew"

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Marcel Holtmann

maintainer

2006-12-10 14:18 UTC #5 lore raw

Hi,

Quoted 16 lines

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 6 lines
How to setup a reliable RFCOMM connection, that is, a connection with infinite flush timeout. I find the RFCOMM_LM_RELIABLE option in the example program l2test.c. It compiles, but at runtime setsockopt with RFCOMM_LM give me an error. I'm using kernel-2.4.21 patched by patch-2.4.21-mh10. So what's the problem. Doesn't kernel-2.4.21-mh10 support RFCOMM_LM? If so, how can I setup a reliable RFCOMM connection?
the RFCOMM channels are always reliable. No need for any other options.
Quoted 7 lines
Quoted 3 lines
Does that mean that the Automatic Flush Timeout Timer for the L2CAP connection underlying the RFCOMM connection is set to 0xFFFF by default? And when does the RFCOMM_LM option introduced?
this won't fly. The underlaying L2CAP connection must be reliable and so we are not using an automatic flush timeout at all for that channel. Please check the specification for details.

Quoted 6 lines

In my understanding of the specification, the Automatic Flush Timeout is applied on a connection handle which corresponds to the ACL link. So does that mean once a RFCOMM connection is established, the automatic flush timeout would be disabled(to ensure link reliability)? Or that bluez doesn't use automatic flush timeout at all for all connections?

we should use automatic flush timeout, but we actually don't. It currently makes no sense for use to use it, because all upper layers assume that the lower layers are reliable. With Bluetooth 2.1 this will change and you can mark L2CAP channels as flushable. This is needed for the A2DP audio channels were it doesn't matter if you loose a packet.

Regards

Marcel