Re: Connection to Panasonic module Pan1322 fails
Re: Connection to Panasonic module Pan1322 fails
- Subject: Re: Connection to Panasonic module Pan1322 fails
- From: Matthias Ringwald <email@hidden>
- Date: Sat, 16 May 2015 21:01:39 +0200
Hi Moritz
I don't know what changed in OS X. Looking at the logs, one thing that looks suspicious is that in the failed log, there's an Authenthication Complete event but no Encryption Change event. In the success case, there's an Ecnryption Event but no Authentication Event. According to the Bluetooth spec, if Security Mode 4 is used and both devices support SSP, a device is not allowed to accept a connection to a PSM other than SDP if the security level isn't at least 2, which is encryption.
How there's an Authentication Complete event but not Encryption Change is unclear, I would expect to get both actually. Maybe the the link keys have been verified and hence the devices are authenticated, but the encryption was never turned on? (It 's the initiating side that's supposed to enable encryption, but the responding side is free to do so, too)
Hope this might help a bit.
Best regards,
Matthias
---
Dr. sc. Matthias Ringwald
BlueKitchen GmbH, Zürich
> On 20.04.2015, at 08:46, Moritz Gmelin <email@hidden> wrote:
>
> 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 <email@hidden>:
>>
>>
>> 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 <email@hidden>:
>>>
>>>> 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 (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Bluetooth-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden