Hi, I just found out that this same problem also applies when trying to connect to a BTSPP (or Obex) socket on a Samsung Galaxy Tab (or Galaxy S4). It does however work when I connect to a BTSPP service on a Windows 7 machine using the Microsoft Bluetooth stack. I am very sure that this did work using our software (the avetanaBluetooth Library) with MacOS < X.10. So the situation is that the same software that used to work with any BT counterpart before MacOS X.10, now only works with a limited number of counterparts. Does anyone have an idea about what could have happened? Thanks Moritz
Am 20.04.2015 um 08:46 schrieb Moritz Gmelin <moritz.gmelin@gmx.de>:
Hi,
yes the Thread that is doing the bluetooth stuff is within a RunLoop. And as I said, it does work with all other devices I’ve had in hands so far.
I have done one log of a failed connection attempt and one of a successfull connection from within the BlueChat application (yes, I’ve changed the UUID to BTSPP, which I don’t even use since I’m directly connecting to channel 1 without even doing an SDP inquiry.
Why do I see an SDP search before the real connection even when I did not request one?
The difference I see between the 2 logs is that in the successful log, the connection to PSM 3 is done much earlier (before the SDP reqeust) than in the unsuccessful log. Who is doing this request and can I skip that?
Thanks
Moritz
<logs.zip>
Am 17.04.2015 um 13:50 schrieb Moritz Gmelin <moritz.gmelin@gmx.de>:
Hi,
yes the Thread that is doing the bluetooth stuff is within a RunLoop. And as I said, it does work with all other devices I’ve had in hands so far.
I have done one log of a failed connection attempt and one of a successfull connection from within the BlueChat application (yes, I’ve changed the UUID to BTSPP, which I don’t even use since I’m directly connecting to channel 1 without even doing an SDP inquiry.
Why do I see an SDP search before the real connection even when I did not request one?
The difference I see between the 2 logs is that in the successful log, the connection to PSM 3 is done much earlier (before the SDP reqeust) than in the unsuccessful log. Who is doing this request and can I skip that?
Thanks
Moritz
<BT12Fail.pklg><BT12Success.pklg>
Am 16.04.2015 um 19:33 schrieb Alexander Traud <alex@traud.de>:
Any clues where I could start searching?
In the Xcode Hardware I/O Tools <https://developer.apple.com/downloads/>, you find the Apple PacketLogger which is very handy for Bluetooth Classic.
Are you sure the RFComm channel is still 1? ConnectToServer extracts the channel ID via the Service-Discovery Profile (SDP) and an UUID. By the way, this opens a Bluetooth Baseband connection as well. But you saw that, I guess, because gExampleChatServiceClassUUID is a private UUID, not the one for the Serial-Port Profile (SSP) you are looking for. Mhm.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/moritz.gmelin%40gmx.de
This email sent to moritz.gmelin@gmx.de
_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/moritz.gmelin%40gmx.de
This email sent to moritz.gmelin@gmx.de
_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com