BTServer is invincible

[Paul Reimer]

Hello all,

I'm trying to get the simple test app running on my 1st-Gen iPhone, OS
3.1. Compiling works fine, my iPhoneOS.platform directory is in a non-
standard location, but I modified this in configure.in, as well as
tried different SDK versions (2.0, 2.2, and 3.0, but I'm using the
default 2.0 now).

When I try and run BTdaemon/test via SSH, I get the following error
from BTdaemon, which causes test to exit:
socket_connection_accept new connection 4
[2009-09-13 08:41:12.446] CMD => 02 F4 01 01
Cannot read termcap database;
using dumb terminal settings.
connect(com.apple.uart.bluetooth) failed (error = Resource busy)
Unable to open device.
device returned 1

This seems to happen for nearly all use cases. I've tried:
-turning off Bluetooth via SBSettings
-turning off Bluetooth via Settings.app
-In /System/Library/LaunchDaemons/com.apple.BTServer.plist:
-setting <key>Disabled</key> to false
-removing the <key>KeepAlive</key> and <dict> ... </dict>
-sudo killall BTServer
-su -c killall BTServer

I've tried combinations of each of these, and when each combination
didn't work I tried rebooting at each stage. The BT icon in the status
bar disappears, but after attempting to run BTdaemon/test, BTServer
starts up and enables BT again.

The only semi-successful attempt I've had is by running
-launchctl unload -w /System/Library/LaunchDaemons/
com.apple.BTServer.plist, and rebooting the phone.

This drives the OS nuts, and reviewing the logs in iPhone
Configuration Utility, it is constantly scanning for BTServer. The
response time for pushing a button is ~10 seconds, and loading any app
takes up to a minute. However, BTdaemon seems to successfully connect
and autobaud this time, although I still cannot connect to my Wiimote
(yes, I changed the addr in test.c). This might be a different
problem, but obviously I cannot use my phone when the OS is thrashing
about looking for a BTServer that isn't there.

I'd really like BTstack to work more consistently, but I'm not sure
what I'm doing wrong.

Thanks in advance for any help!
Paul

[jagheterfredrik]

killall -9 BTServer

[Paul Reimer]

Hmmm.... BTServer still restarts, but now the BT icon does not
reappear in the status bar.
Unfortunately, I still get the same error (Resource busy).

Also, it seems setting <key>Disabled</key> to <false/> in
com.apple.BTServer.plist has no effect. Bluetooth is always ON after a
reboot.

[Paul Reimer]

Maybe it also helps to know that BTdaemon has no problem connecting to
BT when in Airplane mode (although it still can't find my Wiimote). I
prefer to debug on my laptop over SSH, so I can grab multiple TTYs,
but at least I get a hint that it may eventually work.

Cheers,
Paul

[Matthias Ringwald]

Hi Paul

I didn't try on 3.1 yet. How did you install it? :) I've also tried to
used launchd to stop BTserver once, but this was not well received by
the iPhone either. :)

Some others had problem accessing the Bluetooth chipset, but so far it
was not related to the BTServer. On my iPhone (2G, 3.0), BTdaemon
works fine, if Apple's Bluetooth icon is not shown. That's all.
BTserver is running but it does not interfere.

Can you try to reset your changes to the BTserver and its launchd
config and try the binaries of BTdaemon and test here: http://btstack.ringwald.ch/btstack-test-20090902-iphone.zip

Cheers,
Matthias

[Paul Reimer]

Hi Matthias,

Oops, I of course meant 3.0.1; I used redsn0w with the vanilla
iPhone1,1_3.0.1_7A400_Restore.ipsw.

I tried your binaries, but with no luck. Still, BTserver takes over
right after BTdamon accepts a new connection.

Thanks,
Paul

On Sep 13, 12:24 pm, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:

[Matthias Ringwald]

Hi Paul

very strange. Can you give it one more try:

1. reset whatever you did to your 3.0.1 phone...
2. turn off Bluetooth in the Settings
3. reboot the phone
4. log in via SSH or Mobile Terminal
5. run: BlueTool
6. enter: device -D

you should get: "Opening com.apple.uart.bluetooth @ 115200 baud."

all this is not related to the BTstack, so if this fails, I'm clueless
and can only suggest to re-install 3.01 again... sorry :(

Matthias

[Paul Reimer]

Ok, I seem to be able to consistently run BTdaemon and accept
connections from the test example. I upgraded to 3.1 with PwnageTool,
and wiped my root partition to boot.

I have compiled with SDK_VERSION=2.2.1, as well as tested Matthias'
binaries. Note that I had to disable springboard support as there was
no SpringBoard.h in 3rdparty? The svn repo has no such header, but
SpringBoard support is mentioned in the TODO.txt so I assume it is a
feature in development.

Of course, my Wiimote has a different btaddr, so I cannot fully check
the test executable. When I use my own test binary (with the
appropriate btaddr), I cannot see accelerometer data, and I'm not sure
what to make of the debug output:

[2009-09-19 13:06:57.088] EVT <= 81 01 01
[2009-09-19 13:06:57.088] CMD => 03 0C 00
[2009-09-19 13:06:57.566] EVT <= 0F 04 00 01 00 00
[2009-09-19 13:06:57.680] EVT <= 0E 04 01 03 0C 00
[2009-09-19 13:06:57.681] CMD => 09 10 00
[2009-09-19 13:06:57.685] EVT <= 0E 0A 01 09 10 00 4B 6A 3E B3 1C 00
[2009-09-19 13:06:57.685] CMD => 18 0C 02 00 60
[2009-09-19 13:06:57.690] EVT <= 0E 04 01 18 0C 00
[2009-09-19 13:06:57.691] CMD => 1A 0C 01 03
[2009-09-19 13:06:57.696] EVT <= 0E 04 01 1A 0C 00
Bluetooth status: 2
[2009-09-19 13:06:57.699] CMD => 13 0C F8 42 54 73 74 61 63 6B 2D 54
65 73 74 00 00 00 00 50 72 65 73 73 20 31 2B 32 20 6F 6E 20 57 69 69
4D 6F 74 65 20 74 6F 20 6D 61 6B 65 20 69 74 20 64 69 73 63 6F 76 65
72 61 62 6C 65 20 2D 20 50 72 65 73 73 20 48 4F 4D 45 20 74 6F 20 64
69 73 63 6F 6E 6E 65 63 74 20 6C 61 74 65 72 20 3A 29 00 00 00 00 50
6C 65 61 73 65 20 65 6E 74 65 72 20 50 49 4E 20 31 32 33 34 20 6F 6E
20 72 65 6D 6F 74 65 20 64 65 76 69 63 65 00 00 43 68 61 6E 6E 65 6C
20 73 75 63 63 65 73 73 66 75 6C 6C 79 20 6F 70 65 6E 65 64 3A 20 00
00 00 2C 20 68 61 6E 64 6C 65 20 30 78 25 30 32 78 2C 20 70 73 6D 20
30 78 25 30 32 78 2C 20 73 6F 75 72 63 65 20 63 69 64 20 30 78 25 30
32 78 2C 20 64 65 73 74 20 63 69 64 20 30 78 25 30 32 78 0A 00 00 00
00 42 61 73 65 62 61 6E 6B
[2009-09-19 13:06:57.743] EVT <= 0E 04 01 13 0C 00
[2009-09-19 13:06:57.746] CMD => 20 0C 01 00
[2009-09-19 13:06:57.750] EVT <= 0E 04 01 20 0C 00
[2009-09-19 13:06:57.753] CMD => 20 F4 08 58 6D AD 1D 19 00 13 00
Create_connection to 00-19-1D-AD-6D-58
[2009-09-19 13:06:57.755] CMD => 05 04 0D 58 6D AD 1D 19 00 18 00 00
00 00 00 00
[2009-09-19 13:06:57.776] EVT <= 0F 04 00 01 05 04

The WiiMote never decides which player it is; it simply flashes the
LEDs and gives up no matter how many times 1+2 are pressed.

Does this indicate a fully working BTdaemon (without springboard
support) and a slightly broken test?

Thanks for all the help so far,
Paul

On Sep 17, 10:31 pm, Matthias Ringwald <matthias.ringw...@gmail.com>
wrote:

[Matthias Ringwald]

Hi Paul

On Sep 19, 2009, at 10:11 PM, Paul Reimer wrote:

Ok, I seem to be able to consistently run BTdaemon and accept
connections from the test example. I upgraded to 3.1 with PwnageTool,
and wiped my root partition to boot.

We're getting somewhere! :)

I have compiled with SDK_VERSION=2.2.1, as well as tested Matthias'
binaries. Note that I had to disable springboard support as there was
no SpringBoard.h in 3rdparty? The svn repo has no such header, but
SpringBoard support is mentioned in the TODO.txt so I assume it is a
feature in development.

Yes that's true, it's work-in-progress. I just changed the source to compile without the SpringBoard.h.

Thanks for the ping.

As for your log, your Bluetooth is initialized properly.

Create_connection to 00-19-1D-AD-6D-58
[2009-09-19 13:06:57.755] CMD => 05 04 0D 58 6D AD 1D 19 00 18 00 00
00 00 00 00
[2009-09-19 13:06:57.776] EVT <= 0F 04 00 01 05 04

In the end, the command for creating a base band connection is sent and acknowledged by the module, but neither success nor failure event is reported. 

You can actually quickly get an idea about Bluetooth HCI Events using Apple's Bluetooth Explorer. It has a nice Bluetooth HCI Decoder where you can enter the first one or two hex bytes.

For a command, the first two byes make up the OpCode (it's little endian - so you enter 0405), and for events only one byte. The last event is an Command Status event. The next event which you should get might be related to pairing, or an connection complete event with a status field for ok/failed.

So, in any case you should get at least one more event from the module. I've had this before, and the reason which took me a while until I figured it out, is that I was using SSH over WLAN to connect to the iPhone and the WLAN broke down when the Bluetooth action started. It does do this always, but more often than not. I've also added some comments on the GettingStarted wiki page about that. I'm not sure if this can be prevented or if the same happens with Apple's stack.

Please try USB-Tethering for SSH or use the MobileTerminal on the iPhone directly. It supports multiple sessions by tipping on the right part of the status bar...

The WiiMote never decides which player it is; it simply flashes the
LEDs and gives up no matter how many times 1+2 are pressed.

You only press 1+2 once to put the WiiMote into discoverable mode. It will blink until it turns off, or a connection is made AND a "Set LEDs" command is sent.

Cheers,

 Matthias