RFCOMM connection Bluez -> BTstack fails

[GoogleCodeExporter]

Not 100% sure why, but a Bluez -> BTstack RFCOMM connection fails.

BTstack is running rfcomm-echo and I try to initate a connection from the Bluez 
end with 'rfcomm -i hci1 connect  /dev/rfcomm1 00:0F:B3:99:6B:CC'

Connection appears to start,but then fails with 
--
Can't connect RFCOMM socket: Operation now in progress
--

HCI dump attached.

It appears that Bluez sends
--
> ACL data: handle 41 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
--

and is then waiting for something....

Found this page describing the SABM sequence
http://www.palowireless.com/infotooth/tutorial/rfcomm.asp#TS%2007.10%20Multiplex
er%20Startup%20&%20Closedown%20Procedure

Original issue reported on code.google.com by mungew...@gmail.com on 4 May 2011 at 4:43

Attachments:

• bluez_rfcomm_connect_fail.txt

[GoogleCodeExporter]

Looks like 'rfcomm_multiplexers' linked list is always empty.

rfcomm.c:713 is never hit, and therefore the multiplexer for incoming's BDADDR 
is not created (would be on line 739)

Original comment by mungew...@gmail.com on 4 May 2011 at 5:33

[GoogleCodeExporter]

The following patch allows the RFCOMM channel to be established and the console 
on which rfcomm-echo is started reports the keypresses in the Bluez consoles.

This might not be a correct solution, but it appears to show it can work...
--
root@womble:/home/simon/btstack-git-svn/src# git diff rfcomm.c
diff --git a/src/rfcomm.c b/src/rfcomm.c
index 5f81cf6..d11d41d 100644
--- a/src/rfcomm.c
+++ b/src/rfcomm.c
@@ -703,6 +703,10 @@ static int rfcomm_multiplexer_hci_event_handler(uint8_t 
*packet, uint16_t size)
                 l2cap_decline_connection_internal(l2cap_cid,  0x13);
             } else {
                 log_dbg(" => accept\n");
+            multiplexer = rfcomm_multiplexer_create_for_addr(&event_addr);
+            multiplexer->con_handle = con_handle;
+            multiplexer->l2cap_cid = l2cap_cid;
+            multiplexer->state = RFCOMM_MULTIPLEXER_W4_SABM_0;
                 // bt_send_cmd(&l2cap_accept_connection, l2cap_cid);
                 l2cap_accept_connection_internal(l2cap_cid);
             }
--

Original comment by mungew...@gmail.com on 4 May 2011 at 5:54

[GoogleCodeExporter]

Hi Simon. If you're reporting problems/errors, please configure BTstack to 
output packet logs either in hci_dump or in packetlogger format. I can then 
just look at them in wireshark.

Thanks for reporting and even fixing. I hope to look at it tonight (CEST).

Original comment by matthias.ringwald@gmail.com on 4 May 2011 at 6:46

[GoogleCodeExporter]

err... bluez_rfcomm_connect_fail.bluez :-)

Original comment by mungew...@gmail.com on 4 May 2011 at 7:55

[GoogleCodeExporter]

Just a quick note, with the above patch and some further improvements to my usb 
transports I got to the point where I could bring up a RFCOMM link (bluez -> 
BTstack) and use minicom to type to/at the rfcomm-echo demo applications.

Simon

Original comment by mungew...@gmail.com on 5 May 2011 at 5:57

[GoogleCodeExporter]

hi simon.

I"ve looked at your blueZ_to_btstack_work.pklg file. In it, the l2cap 
connection establishment is incomplete. 

L2CAP goes like that:
one device sends connection request, the other answers with connection response
then, both devices send a configuration request and answer the other's config 
request.

For incoming connection, BTstack currently send two ACL packets back to back. 
This can be tricky for the transport implementation. In your log, the 
configuration response from blueZ doesn't show up. Because of that, the L2CAP 
connection is never considered open, and the RFCOMM multiplexer is not prepared 
when the first RFCOMM message arrives.

Your patch sets up the RFCOMM multiplexer on the incoming connection request 
and works around and hides that fact. Looking at the code, this wouldn't work 
for outgoing connection, although the order of L2CAP messages differs.

I'd suggest to get a packet log on both sides (hci_dump on linux) and verify if 
blueZ sends that missing configuration response. If it doesn't, check if blueZ 
receives the configuration command. And if not, then the send fails in your 
configuration.

Original comment by matthias.ringwald@gmail.com on 5 May 2011 at 7:30

[GoogleCodeExporter]

Original comment by matthias.ringwald@gmail.com on 5 May 2011 at 7:31

• Changed state: WontFix

[GoogleCodeExporter]

> I'd suggest to get a packet log on both sides (hci_dump on linux) and verify 
if blueZ sends that missing configuration response.

It could be that the 2 ACL packets are causing replies (from Bluez) close 
together and my timer based HCI_USB implementation is missing the second one....

At present the async reply has a long timeout and a timer is used with a 
maximum value to check every so often (or when the reply would time out). There 
is some dead time between packet arriving and reply buffer being 're-armed'.

I did have some level of working with 'pollfd' but it was very slow (if at all) 
to get started - hence the timer based solution.

I'll look at both ends of the link, but what you say make total sense.
Simon.

Original comment by mungew...@gmail.com on 5 May 2011 at 8:17

[GoogleCodeExporter]

I didn't get very far with understanding the concepts of libusb, but I'm happy 
about:
> ... but what you say make total sense. 

:)

Original comment by matthias.ringwald@gmail.com on 5 May 2011 at 8:24