Closed GoogleCodeExporter closed 8 years ago
Forgot to mention that this is on IOS 5.1.1 (9B206). The same behavior was
noticed on both an iPad2 and iPhone 4S.
Original comment by north.ov...@gmail.com
on 21 Jan 2013 at 8:06
hi. 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)
Original comment by matthias.ringwald@gmail.com
on 21 Jan 2013 at 8:10
That 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.
Original comment by north.ov...@gmail.com
on 21 Jan 2013 at 8:14
Attachments:
The 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)?
Original comment by matthias.ringwald@gmail.com
on 21 Jan 2013 at 10:32
Ok, 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.
Original comment by north.ov...@gmail.com
on 22 Jan 2013 at 2:23
Attachments:
Any update on this? Were you able to reproduce the problem with the test
program I e-mailed you?
Original comment by north.ov...@gmail.com
on 30 Jan 2013 at 2:15
I 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.
Original comment by ahma...@gmail.com
on 5 Feb 2013 at 11:49
Hi 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?
Original comment by north.ov...@gmail.com
on 11 Feb 2013 at 11:37
hi. 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.
Original comment by matthias.ringwald@gmail.com
on 12 Feb 2013 at 10:32
Thanks 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.
Original comment by north.ov...@gmail.com
on 12 Feb 2013 at 8:39
Ok, 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?
Original comment by north.ov...@gmail.com
on 12 Feb 2013 at 9:20
Attachments:
Awesome! 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
Original comment by matthias.ringwald@gmail.com
on 12 Feb 2013 at 9:36
Great 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!
Original comment by ahma...@gmail.com
on 14 Feb 2013 at 4:01
Fixed in BTstack-0.6-9 (although it took me a month to finish this)
Original comment by matthias.ringwald@gmail.com
on 14 Mar 2013 at 10:47
Hurrah. Thank you. :)
Original comment by north.ov...@gmail.com
on 14 Mar 2013 at 11:28
You're welcome. You found the bug! :)
Original comment by matthias.ringwald@gmail.com
on 15 Mar 2013 at 10:15
Original issue reported on code.google.com by
north.ov...@gmail.com
on 21 Jan 2013 at 8:04Attachments: