Closed GoogleCodeExporter closed 8 years ago
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
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
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
err... bluez_rfcomm_connect_fail.bluez :-)
Original comment by mungew...@gmail.com
on 4 May 2011 at 7:55
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
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
Original comment by matthias.ringwald@gmail.com
on 5 May 2011 at 7:31
> 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
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
Original issue reported on code.google.com by
mungew...@gmail.com
on 4 May 2011 at 4:43Attachments: