6

The information being sought with this question is I think similar (but not the same) as the information sought here...

"How many devices we can pair via Bluetooth of BLE to Android?"

...and so let's re-ask it a different way:

Let's say we have a use case where someone with a mobile phone may want to connect securely (using industry standard security mechanisms) to a Bluetooth LE device using Pairing. When Pairing occurs, bonding information is stored in the mobile phones - - > Settings - - > Wireless - -> Bluetooth - - > Paired Devices window (dialog).

These 'Paired Devices' will remain present in this list regardless of whether or not active connections are maintained, correct?

And if this answer is correct, how many hundreds or thousands of previously Paired/bonded devices can be accrued in this list before the Android OS (or iPhone's iOS) begins to start to incur performance issues?

My understanding is... neither Android OS or iPhone OS offer programmatic ability to 'clean out' the list of old paired / bonded devices. And mobile phone users who neglect to remove those devices manually could have a challenging task at hand if they've allowed the list of Paired/Bonded devices to get out-of-hand.

Thoughts? Thanks much in advance, --DJ Regan

2018-November-12 Update... New news today: In profiling many BLE paired devices with Android - - > a team mate of mine discovered their Bluetooth radio had become unavailable (as in un-useable) after attempting to pair to the 102nd device+ today. Additional profiling is on-going. So... perhaps this is a use case that neither iOS or Android should be trusted to support? --DJ Regan

DJ Regan
  • 69
  • 5
  • I doubt that the list would ever grow large enough to cause performance issues. – Paulw11 Oct 29 '18 at 18:29
  • 1
    Hi Paulw11, You may be right. :) But, if folks are going to roll-out a solution that grows at a rate of hundreds of thousands of new devices per year... they need to have 'beyond a doubt' confidence in solid performance. Does anyone already have an example use case where this confidence is known with 'beyond a doubt' certainty? I realize this is an 'expensive' use case to profile. – DJ Regan Oct 29 '18 at 19:22
  • You are going to require a user to personally bond their device with 100,000 different devices per year. 273 per day, every day? I suspect you have a bigger issue than the paired device table. There would be a negative impact on the useability of the Bluetooth settings screen. This is probably reached at about 100 devices – Paulw11 Oct 29 '18 at 19:25
  • Here is a practical real use case... Let's say a mobile phone app is created that enables authorized users (utility service persons, in this case) to read customer utility meters. In this case... the user with mobile phone would go door-to-door, and would pair with the BLE enabled sensor securely. This secure pairing effort will cause bonding information in the "Paired Devices" to grow indefinitely. Who has experience with this use case? – DJ Regan Oct 29 '18 at 19:36
  • I don't think anyone is going to have experience with this use case, because I think pairing/bonding is impractical in this case; what PIN is the meter reader going to enter? If it is a "well known" PIN that each meter has in common, the pairing is pointless. If the reader needs to obtain a PIN, say from the meter itself, then the reading process will be pretty slow, and again is probably pointless. Are utility meter readings a big secret? – Paulw11 Oct 29 '18 at 19:41
  • Hi Paulw11... Utility meters are not necessarily 'headless' displays, and often have a minimum user interface that allows for 'numeric comparison' passkey exchange efforts. These passkeys are randomized six digit values between 000000 and 999999. – DJ Regan Oct 29 '18 at 19:46
  • Right, so the user needs to obtain a PIN and then perform the pairing; anyone could do this if they have access to the meter, so why bother with the pairing. Anyway, I'm afraid your question is probably opinion-based since you will probably just hit a usability issue with the size of the paired devices list before you hit any technical limitation. A large pairing list won't have any impact on the normal operation of the device, and if the device is dedicated for a task and the user never enters the Bluetooth settings they may not care how big the list is. – Paulw11 Oct 29 '18 at 19:49
  • Most utilities are moving to meters that can be read remotely, since the biggest cost is sending someone to read the meter, regardless of how they obtain the data once they are there. – Paulw11 Oct 29 '18 at 19:52
  • There is a great article explaining various passkey exchange processes here "https://www.digikey.com/eewiki/display/Wireless/A+Basic+Introduction+to+BLE+Security#ABasicIntroductiontoBLESecurity-PairingMethodsforLESecureConnections(4.2devicesonly)", but, that said the PIN is displayed on both phone and meter, and the user only has to acknowledge the random six digit passkey is the same. Getting back to my original question... you believe no one will have experience with this use case? – DJ Regan Oct 29 '18 at 19:56
  • It's a big community, so who knows, but I don't think this is a very practical use case or solution. Why would a utility install a new meter that still required the physical attendance of a meter reader? Regardless, a simpler approach would be to not require pairing and simply have the meter digitally sign the data with a private key. The reader app would have the public key so it could validate the read. Someone attempting to spoof the meter data wouldn't have the private key and couldn't, therefore, sign their spoofed data. – Paulw11 Oct 29 '18 at 20:05
  • @DJ Regan, you need custom approach, we already have had such use case. – Mihail Jan 25 '19 at 22:01

3 Answers3

4

From sources I guess 100 is the right number pointing to the max devices you can bond with. Also proved in practise.

 /* The number of security records for peer devices. */
    #ifndef BTM_SEC_MAX_DEVICE_RECORDS
    #define BTM_SEC_MAX_DEVICE_RECORDS  100
    #endif

... 

/************************************************************************************
    **  Local type definitions
    ************************************************************************************/
    typedef struct
    {
        uint32_t num_devices;
        bt_bdaddr_t devices[BTM_SEC_MAX_DEVICE_RECORDS];
    } btif_bonded_devices_t;
Mihail
  • 403
  • 4
  • 8
3

According to the bluetooth implementation, if there are more than 100 device records the allocation will fail.

The responsible BTM_SEC_MAX_DEVICE_RECORDS is defined in bt_target.h:

/* The number of security records for peer devices. */
#ifndef BTM_SEC_MAX_DEVICE_RECORDS
#define BTM_SEC_MAX_DEVICE_RECORDS  100
#endif

This is then used inside btm_dev.c, specifically in BTM_SecAddDevice which returns false after 100 pairings:

   /* There is no device record, allocate one.
    * If we can not find an empty spot for this one, let it fail. */
    for (i = 0; i < BTM_SEC_MAX_DEVICE_RECORDS; i++)
Jake Lee
  • 7,549
  • 8
  • 45
  • 86
0

You can connect maximum 8 devices via bluetooth.

Ranu Dhurandhar
  • 93
  • 1
  • 10
  • 1
    Connected & Paired Devices are two different things – Tushar Walzade Jan 23 '19 at 08:53
  • but why only 8? – Sagar koyani Jan 23 '19 at 10:23
  • 2
    Tushar is correct - Connected vs Paired are two different things. Question is 'how large?' is the list of bonded (paired) devices permitted to get? Mihail's answer of 100... sounds correct based on a few simulated tests we've run on a couple phones. I had heard there were newer releases that could go above 100 - but... for those devices, what is the new ceiling? We'll see. Or maybe someone knows? – DJ Regan Jan 23 '19 at 21:36
  • If we reference the source code again, you can see that #define GAP_MAX_CONNECTIONS 8, The maximum number of simultaneous GAP L2CAP connections – Mihail Jan 25 '19 at 16:07