Re: Bluetooth-dev Digest, Vol 10, Issue 283
Re: Bluetooth-dev Digest, Vol 10, Issue 283
- Subject: Re: Bluetooth-dev Digest, Vol 10, Issue 283
- From: Marco Peluso <email@hidden>
- Date: Thu, 21 Nov 2013 16:11:58 +0000
We should have literature on the other side
On 21 Nov 2013, at 16:02, email@hidden wrote:
Send Bluetooth-dev mailing list submissions to
email@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.apple.com/mailman/listinfo/bluetooth-dev
or, via email, send a message with subject or body 'help' to
email@hidden
You can reach the person managing the list at
email@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bluetooth-dev digest..."
Today's Topics:
1. Re: Suddenly seeing constant BLE connect/disconnect (Rick Mann)
2. RE: Help needed with IOBluetoothHandsFreeDevice (Mihai Fratu)
3. Question about characteristic value transmission from a
peripheral (Richard Lipes)
4. Re: Recognizing previously connected peripheral
(William Henderson)
----------------------------------------------------------------------
Message: 1
Date: Wed, 20 Nov 2013 12:06:09 -0800
From: Rick Mann <email@hidden>
To: "email@hidden Bluetooth"
<email@hidden>
Subject: Re: Suddenly seeing constant BLE connect/disconnect
Message-ID: <email@hidden>
Content-Type: text/plain; charset="utf-8"
Oh, I think I know what might be doing this. NVM.
> On Nov 20, 2013, at 11:58 , Rick Mann <email@hidden> wrote:
>
> We develop a BLE peripheral, normally interacting with iOS. Suddenly, on my Mac, I'm seeing very frequent Bluetooth connect/disconnect messages (as reported by Hardware Growler) between the Mac and a couple of different devices. But I'm not running any BLE apps (that I know of) on this machine. In fact, I just rebooted. And ever since Xcode dropped BLE support in the Simulator, I haven't bothered to connect at all. Also, I only have the built-in radio installed.
>
> --
> Rick
>
>
>
> _______________________________________________
> 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
--
Rick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.apple.com/mailman/private/bluetooth-dev/attachments/20131120/5850c358/attachment.asc>
------------------------------
Message: 2
Date: Wed, 20 Nov 2013 23:25:28 +0100
From: Mihai Fratu <email@hidden>
To: Peter Sichel <email@hidden>,
"email@hidden" <email@hidden>
Subject: RE: Help needed with IOBluetoothHandsFreeDevice
Message-ID: <email@hidden>
Content-Type: text/plain; charset="windows-1252"
Hey Peter!
Once again thanks for your nice reply. It really put some light onto my problem but I still have no idea what I'm missing from this equation.
So let me explain the setup I have right now:
1). My app starts2) I than select a device using the build in Mac OSX Bluetooth device selector which I filter on with the kBluetoothSDPUUID16ServiceClassHandsFreeAudioGateway IOBluetoothSDPUUID so that only devices offering that service will be shown.3) After I select my iPhone from the list I create a IOBluetoothHandsFreeDevice with the newly created IOBluetoothDevice4) I call -(void)connect on the IOBluetoothHandsFreeDevice5) The device connects (I fixed my earlier problem)6) With a really simply interface I enter a phone number and call -(void)dialNumber: on the IOBluetoothHandsFreeDevice7) My delegate methods get called and my iPhone actually starts dialing. My MAC shows up as the selected route for the audio on my iPhone8) My Mac lowers volume for all ongoing audio. For ex: if iTunes is playing music you can hear how it's volume is going low9) My phone connects to the other side10) I can hangup or stay in the call.
The thing is there is no audio on my Mac. Shouldn't IOBluetoothHandsFreeDevice take care of this? Or I have to do some other things to get the audio from my iPhone to be heard on my Mac?
Cheers,Mihai
> Subject: Re: Help needed with IOBluetoothHandsFreeDevice
> From: email@hidden
> Date: Wed, 20 Nov 2013 09:31:47 -0500
> To: email@hidden
>
>> On Nov 20, 2013, at 4:32 AM, Mihai Fratu <email@hidden> wrote:
>>
>> Peter!
>>
>> Thank you very much for your reply. I have two questions for you:
>>
>> 1. What's DTS? Who am I suppose to ask for more help?
>
> DTS stands for Developer Technical Support. Registered Apple Developers receive two “code level" DTS support incidents per year. Another big support opportunity is the Bluetooth Lab at WWDC.
>
>> 2. I already use the IOBlietoothHandsFreeDevice for connecting to my phone. I managed to connect to it, dial a number, receive an incoming call notification, but there is no audio playing on my PC during a phone call.
>>
>> The thing that I've observed is that if I search for a handsfreeaudiogateway and open an rmfcomm channel to it, my IOBlietoothHandsFreeDevice won't connect. When I call it's connect method it will just hang until my rmfcomm channel get's closed with no information why.
>>
>> If I search for a SerialPort service instead and open a rmfcomm channel to that service everything looks to go fine and my IOBlietoothHandsFreeDevice connects when it's connect method get's called. What's up with that?
>
> Bluetooth HFP (HandsFree Profile) is built on top of Bluetooth SPP (Serial Port Profile). The specs for both of these are available on line. The iPhone does not expose the SPP, but many other phones do. If you see an SPP service, it means you are not using an iPhone.
>
> To connect using the SPP, you can just open an RFCOMM channel and begin sending AT commands. There is not support for handling call audio.
>
> When connecting with HFP, an additional handshake is needed to establish a “Service Level Connection”. IOBluetoothHandsFreeDevice is designed to open the needed RFCOMM channel for you so it might fail if you have already opened an RFCOMM channel to the audio gateway service on the peer device. If you just tell it to connect with the corresponding service record, it usually works.
>
> When using HFP, the phone implements the Audio Gateway (AG) side of the HFP, while the Mac implements the HandsFree (HF) side of HFP. Technically, the Mac needs to publish an SDP (Service Discovery Profile) record indicating that it supports the HF side of HFP. Some Audio Gateways will look for this record before accepting an HFP connection. Apple’s APIs make it relatively simple to publish an SDP record, but you still have to understand the content and format of this record.
>
> Kind Regards,
>
> - Peter
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.apple.com/mailman/private/bluetooth-dev/attachments/20131120/8d28573c/attachment.html>
------------------------------
Message: 3
Date: Wed, 20 Nov 2013 18:19:43 -0800
From: Richard Lipes <email@hidden>
To: email@hidden
Subject: Question about characteristic value transmission from a
peripheral
Message-ID: <CEB2A60C.1A215%email@hidden>
Content-Type: text/plain; charset="iso-8859-1"
I have a question about transmitting a characteristic value from a
PeripheralManager object. Suppose I have received a callback
peripheralManager:central:didSubscribeToCharacteristic. I can start sending
the characteristic value with the method
updateValue:forCharacteristic:onSubscribedCentrals. It is possible the
entire vale will not be sent (as a queue may be filled) in which case I will
subsequently receive a callback peripheralManagerIsReadyToUpdateSubscribers
which allows me to send additional ³chunks² of the characteristic value
with another call to updateValue:forCharacteristic:onSubscribedCentrals.
My question is, ³Am I guaranteed that the CoreBluetooth Framework will NOT
issue an additional callback
peripheralManager:central:didSubscribeToCharacteristic between the first
peripheralManager:central:didSubscribeToCharacteristic callback and a
followup callback peripheralManagerIsReadyToUpdateSubscribers²? If there is
no such guarantee, is there any recommended coding practice for handling
this situation with a single PeripheralManager object or (even more
complicated) for multiple PeripheralManager objects? It seems to me that
some sort of ordered queue handling is required.
The Apple developer site
https://developer.apple.com/library/ios/samplecode/BTLE_Transfer/Listings/BT
LE_Transfer_BTLEPeripheralViewController_m.html provides sample code that
seems to implicitly assume that an additional calllback
peripheralManager:central:didSubscribeToCharacteristic will NOT occur
between the first peripheralManager:central:didSubscribeToCharacteristic
callback and a followup callback
peripheralManagerIsReadyToUpdateSubscribers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.apple.com/mailman/private/bluetooth-dev/attachments/20131120/0d9986cd/attachment.html>
------------------------------
Message: 4
Date: Wed, 20 Nov 2013 10:16:36 -0800
From: William Henderson <email@hidden>
To: Etan Kissling <email@hidden>
Cc: "=?utf-8?Q?bluetooth-dev=40lists.apple.com_Bluetooth?="
<email@hidden>
Subject: Re: Recognizing previously connected peripheral
Message-ID: <email@hidden>
Content-Type: text/plain; charset="utf-8"
The service UUID idea is interesting. I can see why Apple might not like it, as it sort of circumvents their privacy scheme – but let’s be honest, we are all circumventing it with the connect-and-read-a-customer-characteristic approach anyway. Ironically, this could make the privacy problem worse as it’s up to each developer to ensure their users are not trackable.
The other (big) problem with the connect-and-read characteristic approach is that it is slow and wasteful in pracitce This is exacerbated by the fact that connecting to multiple devices in parallel doesn’t work reliably. So, you have to connect in series, which means your worst case is ~2 seconds times the number N of devices in the room. And like Darrin I am seeing UDIDs rotate every 15 minutes or so, meaning my app needs to do those (N-1) wasteful connections every 15 minutes. Our app (Knock) does its best to work around these limitations but there are real world consequences in the form of slower connections and greater-than-necessary battery usage.
William
> On Tuesday, November 19, 2013 at 11:58 PM, Etan Kissling wrote:
>
> Darrin,
>
> yes, it is possible to spoof a YesNo pairing with a Man in the middle attack.
> Only PIN-based methods (supported by iOS) or transmitting the keys OOB (not supported by iOS)
> protects against this.
>
> BLE security is pretty weak, though, so if someone really wants to hack it, you should build an own
> encryption layer on top of BLE anyway: http://eprint.iacr.org/2013/309
>
> Both devices can choose their capabilities in the pairing process. You cannot control what the iOS
> device will send (it’s always Display + Full Keyboard), but your remote device can send restricted
> capabilities that prevent the automatic choice of the PIN-based pairing.
>
> Based on your last message, it seems that you also use iOS for the central device. In this case,
> you won’t be able to accomplish a YesNo pairing.
>
> However, there might be another glimmer of hope: While normally, a BLE 4.0 peripheral can only
> be connected to one central at a time, iOS leverages this restriction and allows multiple parallel
> connections (at least in theory). Therefore, you shouldn’t worry about connecting and reading out
> a custom characteristic that contains a unique identifier for your application.
> Reports claimed that after 7 parallel connections, BT becomes unstable, even though BLE should
> support many more connections. If you are only connecting to read out a single value, this shouldn’t
> be a problem though.
>
> Another advantage of using iOS-to-iOS connection is that you may be able to make use of the
> “overflow area” in the advertisement packets. They provide a best-effort (sometimes work, sometimes
> it doesn’t) way of adding multiple service UUIDs in a single advertisement packet. So you may try
> approach were you inject the app identifier into one of those service UUIDs. It’s not a clean approach
> though, and you may run into App store issues, as the service UUIDs are not intended for this use case.
>
> Etan
>
>
>
>> On 20.11.2013, at 06:59, Darrin Massena <email@hidden (mailto:email@hidden)> wrote:
>> Thanks Etan, David, William. Your responses are very helpful.
>>
>> Etan, I'm trying to learn more about UI-less YesNo pairing but can't find discussion of it in the Core Bluetooth documentation. Can you provide a pointer? In my case, the peripheral is an iOS device so how would it indicate itself as a display/button-less device?
>>
>> If this can be made to work, would I be right to assume that such a peripheral would be spoofable? I.e. without encryption one can see how the pairing works and mimic it with a different device.
>>
>> Regarding the identifier changing every 15 minutes, from my logs:
>>
>> 2013-11-19 21:24:55.005 CardsMac[40233:303] Discovered peripheral NameTag (<CBPeripheral: 0x6080000ad800 identifier = F3C38468-F250-4067-BACB-37A7D8DEF71A, Name = "NameTag", state = disconnected>) with RSSI -44 and advertisementData {
>> kCBAdvDataLocalName = NameTag;
>> kCBAdvDataServiceUUIDs = (
>> "Unknown (<0f4266cc 6ec44798 9fe087b3 5b7e8d1c>)"
>> );
>> }
>> <... intervening connect/cancelPeripheralConnection and stop/startScans removed ...>
>> 2013-11-19 21:39:34.617 CardsMac[40233:303] Discovered peripheral NameTag (<CBPeripheral: 0x6180000aed00 identifier = B2E8A6AB-C9AC-4FA3-A35E-63FC92B3189B, Name = "NameTag", state = disconnected>) with RSSI -50 and advertisementData {
>> kCBAdvDataLocalName = NameTag;
>> kCBAdvDataServiceUUIDs = (
>> "Unknown (<0f4266cc 6ec44798 9fe087b3 5b7e8d1c>)"
>> );
>> }
>>
>>
>> Another thing I'm looking into is that when this rediscovery happens and I attempt to connect to the 'new' peripheral (note that I am not maintaining a connection to the original CBPeripheral), my connection attempt hangs, i.e. no did*Connect callbacks are received. I'll have to figure that out for any of the connection-dependent solutions to this problem to be viable.
>>
>>
>>
>>> On Tue, Nov 19, 2013 at 7:01 AM, Etan Kissling <email@hidden (mailto:email@hidden)> wrote:
>>> Darrin,
>>>
>>> You won’t need to do a full pairing with PIN entry if it is only for private address resolving.
>>>
>>> YesNo pairing can be initiated by registering as a device without display / button and works with the iPhone.
>>> You will not be able to encrypt the channel, but can store the pairing information on the accessory for
>>> associating a new address with the old identity.
>>>
>>> This key still works for address resolving after BT off / on, unpair from the phone, phone reboot and even secure erase.
>>>
>>> This means that you should not link the BT info to a specific identity - as it won’t change when the phone changes its owner.
>>>
>>>
>>> If you still are not able to perform this initial Yes/No pairing, you could either connect to the phone and implement
>>> a custom identity variable that contains the app-manufacturer-specific device UUID.
>>>
>>>
>>> Or use Davids approach.
>>>
>>> Note however, that using custom advertisement data works only properly in foreground mode, though.
>>> When your app is in background, the local name may change, and the serviceUUIDs may be moved to an invisible area.
>>>
>>> Also, I’m not sure if apple likes when you abuse the serviceUUIDs key for unintended purposes.
>>>
>>>
>>> BTW:
>>> I have never seen the iPhone change already after 15 mins - it often requires a reboot to happen,
>>> or a significantly longer time to change addresses.
>>>
>>>
>>> Maybe there are other workarounds like tracking of the RSSI and then mapping it to the new BD_ADDR (with a similar RSSI) when the address changes.
>>>
>>> Or abusing the ANCS by injecting a custom hidden message in it that’s unique to a single device.
>>> Have not experimented yet with the ANCS so not sure what’s possible with it :)
>>>
>>>
>>> I would suggest that you provide us with the concrete use case, so we can discuss a solution that’s more tailored to your needs.
>>>
>>>
>>>
>>>> On 19.11.2013, at 06:53, David Chu <email@hidden (mailto:email@hidden)> wrote:
>>>> The only way I can think of is if the iOS Device advertised a serviceUUID or Local Name that was unique to only itself.
>>>>
>>>> In CBPeripheralManager, the only advertising data that you are allowed to set are.
>>>> 1. CBAvertisementDataLocalNameKey
>>>> 2. CBAdvertisementDataServiceUUIDsKey
>>>>
>>>> You could discovery the device and read the advertisingData dictionary without connecting to the device.
>>>>
>>>> Dave
>>>>
>>>>
>>>>> On Nov 19, 2013, at 1:24 PM, William Henderson <email@hidden (mailto:email@hidden)> wrote:
>>>>> You can’t. You’ll need to connect and implement your own identification scheme.
>>>>>
>>>>> --
>>>>> William
>>>>> Sent from my iPhone
>>>>>
>>>>>
>>>>>> On Monday, November 18, 2013 at 9:22 PM, Darrin Massena wrote:
>>>>>>
>>>>>> An iOS device used as a Bluetooth LE peripheral changes its identifier every 15 mins or so. Scanning Centrals rediscover it and think it is a new peripheral. Without pairing with the peripheral, how can a Central recognize that this is the same peripheral it has previously connected to?
>>>>>>
>>>>>> Thanks,
>>>>>> Darrin
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Bluetooth-dev mailing list (email@hidden (mailto:email@hidden))
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>> This email sent to email@hidden (mailto:email@hidden)
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Bluetooth-dev mailing list (email@hidden (mailto:email@hidden))
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden (mailto:email@hidden)
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Bluetooth-dev mailing list (email@hidden (mailto:email@hidden))
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden (mailto:email@hidden)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.apple.com/mailman/private/bluetooth-dev/attachments/20131120/1be22413/attachment.html>
------------------------------
_______________________________________________
Bluetooth-dev mailing list
email@hidden
https://lists.apple.com/mailman/listinfo/bluetooth-dev
End of Bluetooth-dev Digest, Vol 10, Issue 283
**********************************************
--
Qardio, QardioArm, QardioCore and the Qardio logo are trademarks of Qardio,
Inc.
This e-mail is for the sole use of the intended recipient, if you are not
the intended recipient of this e-mail, please do not read this e-mail and
delete this message and any file attached from your system and then notify
us immediately by reply e-mail to email@hidden The information
herein is believed to be reliable and has been obtained from sources
believed to be reliable, but we make no representation or warranty, express
or implied, with respect to the fairness, correctness, accuracy,
reasonableness or completeness of such information. In addition we have no
obligation to update, modify or amend this communication or to otherwise
notify a recipient in the event that any matter stated herein, or any
opinion, projection, forecast or estimate set forth herein, changes or
subsequently becomes inaccurate. We strongly suggest that recipients seek
their own independent advice in relation to any investment, financial,
legal, tax, accounting or regulatory issues discussed herein. Analyses and
opinions contained herein may be based on assumptions that if altered can
change the analyses or opinions expressed. Nothing contained herein shall
constitute any representation or warranty as to future performance of any
financial instrument or economic measure. This communication is provided
for information purposes only. It is not an offer to sell, or a
solicitation of an offer to buy, any security, nor to enter into any
agreement or contract with Qardio, Inc. or any affiliates. Any offering or
potential transaction that may be related to the subject matter of this
communication will be made pursuant to separate and distinct documentation
and in such case the information contained herein will be superseded in its
entirety by such documentation in final form. This communication and the
information contained herein is confidential and may not be reproduced or
distributed in whole or in part without our prior written consent.
_______________________________________________
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