What steps will reproduce the problem? 1. open connection to btstack 2. register l2cap service(s). (services appear to register correctly) 3. attempt to initiate connection from hardware device, but L2CAP_EVENT_INCOMING_CONNECTION is never received. This worked before upgrading to latest btstack (0.5-1715) from Cydia. Device initiating the connection is a playstation 3 sixaxis controller, with the bluetooth address of the ipad programmed into it.
What is the expected output? What do you see instead?
Expect to receive an HCI_EVENT_PACKET of type L2CAP_EVENT_INCOMING_CONNECTION when the ps3 controller attempts to initiate a connection. Instead I am getting no packets notifying an incoming connection to the registered packet handler.
What version of the product are you using? On what operating system?
Version 0.5-1715 from Cydia. One interesting thing to note is that when I took the time and compiled the same 1715 svn revision on my machine, this problem is NOT present. The problem only shows up with the Cydia package.
Please attach a package log, as described here: http://btstack.uservoice.com/knowledgebase/articles/69548-how-to-get- btstack-communication-log
and provide any additional information below.
- hci_dump.pklg 1.17KB
Comment #1
Posted on Jan 21, 2013 by Quick RabbitForgot to mention that this is on IOS 5.1.1 (9B206). The same behavior was noticed on both an iPad2 and iPhone 4S.
Comment #2
Posted on Jan 21, 2013 by Swift Oxhi. that's surprising. Anyway, could you send a log with an actual connection? The log only shows the l2cap setup for HID. (it can be opened with PacketLogger on iOS or Wireshark)
Comment #3
Posted on Jan 21, 2013 by Quick RabbitThat is all the log that I get in the case where it's not working. I have no idea why the incoming packets are nowhere to be seen. I did make another log with my recompiled 0.5-1715 and have attached here. This shows the incoming connection as well as a bunch of data packets from the controller. (running the exact same code as previous dump)
Let me know if there's something else I can provide to help.
- hci_dump_good.pklg 21.51KB
Comment #4
Posted on Jan 21, 2013 by Swift OxThe only difference in the logs is that the "good" version doesn't send a Write Scan Enable while the "bad" one doesn't , or at least no in the part. It sets it to paging yes, inquriy no, which is ok for the Sixaxis.
There's no incoming connection and the only influence for that could be the Scan Enable mode.
If you like, you could post the complete init, too, i.e., enable packet logger, restart BTdaemon and try again to capture the complete Bluetooth module state.
The Cydia version is compiled from the SVN with a minor fix for iOS 6 that I've kept private so far. For 5.1.1, there are no changes. I also recently tested WeBe++ agin, which also provides setups HID L2CAP services and it worked
Could you sent me a test application (e.g. as a .deb)?
Comment #5
Posted on Jan 22, 2013 by Quick RabbitOk, so I have made a small test app and run the packet logger while restarting BTdaemon to try to capture the complete init and bt module state. I am attaching these new logs. They both have the write scan enable in them. I am really puzzled what could be causing the issue. I am also e-mailing you a small console based test app that I used for these latest packet captures.
Perhaps I am doing something wrong? The only weird thing is that the code works unchanged when I compile r1715 myself from svn.
- hci_dump.pklg 2.3KB
- hci_dump_good.pklg 9.02KB
Comment #6
Posted on Jan 30, 2013 by Quick RabbitAny update on this? Were you able to reproduce the problem with the test program I e-mailed you?
Comment #7
Posted on Feb 5, 2013 by Massive HorseI can confirm the same issue on btstack version 0.5-1715 from Cydia. Today, I upgrade my iPad 3 from 0.5-1693 to the latest one from Cydia (0.5-1715). After the upgrade, my PS3 Controller failed to connect to the iPad. It was working with version 0.5-1693. My iPad runs iOS 5.1.1 and the only thing that I did was upgraded the btstack from 1693 to 1715. Everything else stays the same.
The symptom is that I've never received L2CAP_EVENT_INCOMING_CONNECTION event, exactly as north.overby described.
Comment #8
Posted on Feb 11, 2013 by Quick RabbitHi Matthias. I know you're probably busy but just curious if you had a chance to look into this yet? I noticed that issue #305 mentions WeBe++ is not compatible with the latest update of btstack so it seems like this problem might affect more than just the sixaxis incoming L2CAP connections?
I tried updating my iPhone 4S to iOS 6.1, and for some reason when I compile btstack for iOS 6.1 I cannot get btstack to even turn on in preferences app. So now I am stuck without sixaxis on my iPhone. Is there something special in the compilation process that is different for iOS 6?
Comment #9
Posted on Feb 12, 2013 by Swift Oxhi. still busy. Could you guys to a trivial test and try to connect/pair e.g. from your Mac? Really the only reason I can see for missing connection attempt (at HCI level), is that the device is not in page scan mode, which it is according to the logs before - I have not problems with the Cydia package on my iPhone 5 or iPad 3.
Comment #10
Posted on Feb 12, 2013 by Quick RabbitThanks for the quick response. I will try to form a L2CAP connection from one iOS device to another and let you know how that turns out.
Comment #11
Posted on Feb 12, 2013 by Quick RabbitOk, I think I found the issue. I was debugging the btstack startup procedure and have been staring at the init sequence in the log files. The attached log is with the cydia deployed 0.5-1715. If you look closely at the log, you can see that the result for the hci read device address command is returning 00:24:33:6a:2a:6d, but the actual device bluetooth hardware address is 60:fa:cd:cb:e1:04.
I tried this on two different iOS devices and discovered that it ALWAYS uses the same 00:24:33:6a:2a:6d device address. So it looks like we have bluetooth spoofing. The reason that myself and Simon had trouble was that the sixaxis requires programming the server device address into the controller and we were using what ios settings->general->about told us was the bluetooth address. When I reprogrammed the controller with the spoofed address, the latest cydia works on either iOS device/version.
So maybe that address is hardcoded somewhere it shouldn't be?
- hci_dump.pklg 1.26KB
Comment #12
Posted on Feb 12, 2013 by Swift OxAwesome! Totally my fault. Sorry.
The hard-coded device address is of course the one from my PS 3 as I was to lazy to set the master of the Dual Shock... - but then forgot about that quick test hack.
I'll do some more checks and commits and release a bug fix update in the next days.
thanks again! matthias
Comment #13
Posted on Feb 14, 2013 by Massive HorseGreat job, guys! I've just re-tested with the hard-coded PS3 BT address. Both my iPad 3 & iPhone 5 running iOS 6.1 works like a charm. Looking forward to the fixed Cydia version. Thank you, North & Matthias!
Comment #14
Posted on Mar 14, 2013 by Swift OxFixed in BTstack-0.6-9 (although it took me a month to finish this)
Comment #15
Posted on Mar 14, 2013 by Quick RabbitHurrah. Thank you. :)
Comment #16
Posted on Mar 15, 2013 by Swift OxYou're welcome. You found the bug! :)
Status: Fixed
Labels:
Type-Defect
Priority-Medium