William, there's not much information about this from the official side. Therefore, I would assume that the behavior you describe is intended. I don't think that it is a bug that the error codes trigger different schemes ;-) both seem to be tailored for their corresponding use case. Note that CoreBluetooth isn't exactly standards conform at every edge, and this seems to be such a case, as the Core Spec describes more security modes than just "authenticated pairing" and "unauthenticated pairing". Normally, there is also a way to initiate pairing from the central, and the automatic handling of the InsufficientAuthentication / Authorization error codes is completely iOS specific. Etan On 17.04.2013, at 20:28, William Henderson <william.c.henderson@gmail.com> wrote:

Got it. FWIW, insufficient authentication triggers just a Pair/Cancel dialog whereas insufficient authorization triggers the entire pairing ritual (type in a number, confirm, etc). However, either appears to be enough to get the caching behavior. Hence, if caching is all you want then using insufficient authentication is certainly less of a burden for your users. Can anyone weigh in on if this is intended behavior and/or something that is likely to change?

Thanks,

William

On Wed, Apr 17, 2013 at 11:16 AM, Etan Kissling <kissling@oberon.ch> wrote: William,

On the BLE level, InsufficientAuthentication is the correct one to use.

Authorization is handled on a per-application basis and is not defined strictly.

On iOS, it may also indicate that pairing is requested. However, on a different platform, you may experience different results.

See Bluetooth Core Spec V4.0 Vol 3 Part C Section 10.5:

10.5 AUTHORIZATION PROCEDURE A service may require authorization before allowing access. Authorization is a confirmation by the user to continue with the procedure. Authentication does not necessarily provide authorization. Authorization may be granted by user confirmation after successful authentication.

Etan

On 17.04.2013, at 20:08, William Henderson <william.c.henderson@gmail.com> wrote:

...

Interesting. In my testing they both trigger a pair, but maybe that's not intended?

William

On Wed, Apr 17, 2013 at 10:59 AM, Arvydas Sidorenko <asido4@gmail.com> wrote:

...

[peripheralManager respondToRequest:request withResult:CBATTErrorInsufficientAuthorization]; William, it is CBATTErrorInsufficientAuthentication which triggers pairing on the central and not CBATTErrorInsufficientAuthorization.

On Wed, Apr 17, 2013 at 6:44 PM, William Henderson <william.c.henderson@gmail.com> wrote:

...

I've tested the described caching behavior and can very that it works on iOS 6.1.3 but does not on Mac OS 10.8.3.

As mentioned above, caching happens only for paired devices. To pair, you need to respond to a write request with an insufficient authorization error. For example, for an iOS peripheral you would write something like:

- (void)peripheralManager:(CBPeripheralManager *)peripheralManager didReceiveWriteRequests:(NSArray *)requests { ...

[peripheralManager respondToRequest:request withResult:CBATTErrorInsufficientAuthorization];

... }

That will pop up a pairing dialog on the iOS peripheral, after which point you will be paired. Other than that you don't have to change your code – just call discoverServices etc as normal and they will respond more quickly (ie instantly).

William

On Wed, Apr 17, 2013 at 3:17 AM, Etan Kissling <kissling@oberon.ch> wrote:

...

John,

nope, i haven't tested caching / encryption yet.

Etan

On 17.04.2013, at 09:48, John Earl <jearl@airsource.co.uk> wrote:

Etan,

This discussion seems to imply that discovered services and characteristics can be cached across disconnect/reconnect pairs if the application runs continuously in the background, so long as CBCentralManager does not power down.

Have you tried this and/or do you use this functionality yourself?

John

On 17 Apr 2013, at 08:14, Etan Kissling wrote:

Jack,

In the mentioned session they explained that characteristics are only cached when encryption is on. I haven't tested whether this is true, but may be worth trying.

To speed up characteristic discovery, consider lowering the connection interval for the first 30 seconds or so from your peripheral. You can do this by sending a connection parameter update request.

Also ensure that all your services with 16-bit uuids are grouped at the beginning of your peripheral gatt database. This allows to read up to four 16-bit uuid services at a time with the default MTU of 23 bytes.

Regarding serialization of cb* objects: it's not possible with public apis and even if you could serialize them for nsuserdefaults storage, you would still run into problems as the documentation clearly states that all peripherals etc are invalidated when the cbcentralmanager state falls below a certain level. When you create a new manager, state defaults to "unknown" which is the lowest level ;-)

Cheers Etan

On 17.04.2013, at 08:34, "Jack Phan" <jackphan02@gmail.com> wrote:

Thank you very much for all your comments.

Jack

On Apr 16, 2013, at 11:28 PM, Andras Kovi <allprog@gmail.com> wrote:

Well, if you retrieve or discover a peripheral, then its services will be nil. Those are read only from our perspective so there is not even a theoretical way to save and then restore the characteristics. Maybe they come up with some caching this year (WWDC 2013 hasn't happened yet to my best knowledge :) ) but I doubt that as that would introduce a whole bunch of issues. Rediscovery is not a big deal, you just have to plan for it.

Cheers, Andras

On 2013.04.17., at 8:09, Jack Phan <jackphan02@gmail.com> wrote:

I may be wrong but I remember that in Advanced Core Bluetooth session from this years WWDC, they said we could catch the characteristics.

Jack

On Apr 16, 2013, at 11:06 PM, Andras Kovi <allprog@gmail.com> wrote:

Yes, Khaos is right. You cannot save neither the characteristics or the services. They must be rediscovered every time.

Andras

On 2013.04.17., at 7:44, Khaos Tian <khaos.tian@gmail.com> wrote:

It seems you had to re-discover characteristics every time you established a new connection.

Here are threads that discussed this problem previously.

http://prod.lists.apple.com/archives/bluetooth-dev/2013/Mar/msg00032.html

Best Wishes, Khaos Tian

On Apr 17, 2013, at 1:25 PM, Jack Phan <jackphan02@gmail.com> wrote:

The reason is that I don't want to scan again. I would like to reconnect but don't want to discover characteristics again because it takes too long. So when the user opens the app, I reconnect, no discover characteristics, but send characteristic values that I had saved to Peripheral.

Jack

On Apr 16, 2013, at 10:14 PM, Khaos Tian <khaos.tian@gmail.com> wrote:

sorry for the typo.

I mean why don't you perform a discover characteristics action and then use that CBCharacteristic to perform action you want?

Best Wishes, Khaos Tian

On Apr 17, 2013, at 1:06 PM, Jack Phan <jackphan02@gmail.com> wrote:

Hi Khaos,

Yes. I would like to save CBCharacteristic *myChar into NSUserDefauts and then load it when user open the app. Thanks,

Jack

On Apr 16, 2013, at 10:02 PM, Khaos Tian <khaos.tian@gmail.com> wrote:

May I ask why would you like to say CBCharacteristic into NSUserDefaults?

Best Wishes, Khaos Tian

On Apr 17, 2013, at 12:56 PM, Jack Phan <jackphan02@gmail.com> wrote:

Hi Group,

I'm working on a project for iPhone (Central) with TI CC2541 (Peripheral) and would like to save a CBCharacteristic *myChar to NSUserDefaults but I don't know how. Please give me a way to solve this. It's great if you could share your code for it.

Thanks a lot,

Jack _______________________________________________ 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/khaos.tian%40gmail.com

This email sent to khaos.tian@gmail.com

_______________________________________________ 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/allprog%40gmail.com

This email sent to allprog@gmail.com

_______________________________________________ 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/kissling%40oberon.ch

This email sent to kissling@oberon.ch

_______________________________________________ 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/jearl%40airsource.co.u...

This email sent to jearl@airsource.co.uk

_______________________________________________ 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/william.c.henderson%40...

This email sent to william.c.henderson@gmail.com

-- William Sent from my iPhone

_______________________________________________ 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/asido4%40gmail.com

This email sent to asido4@gmail.com

-- William Sent from my iPhone

-- William Sent from my iPhone

_______________________________________________ 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