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%20Multiplexer%20Startup%20&%20Closedown%20Procedure

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)

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);

}

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).

err... bluez_rfcomm_connect_fail.bluez :-)

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

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.

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.

I didn't get very far with understanding the concepts of libusb, but I'm happy about:

... but what you say make total sense.

:)