Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

endnode — Mon, 29 May 2017 07:21:42 GMT

You can use some wired interface (UART, SPI, I2C...), provision it in production (if you know all addresses at that stage and they fit into the memory), you could use NFC, you could even use keyboard and manual input. Simply whatever else then BLE.

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

purgoufr — Mon, 29 May 2017 05:45:03 GMT

Hi, How to use Out of Band to send address of the central to our peripheral ?

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

Aleksander Nowakowski — Mon, 06 Mar 2017 11:29:39 GMT

It's not only that on Android 6+ user must grant the location permission to an app (BLE scanning requires a runtime location permission, Bluetooth permission is granted automatically). A web can't just scan in background without user knowing it. Scanning will show a popup (like one shown on the link I gave above) and will scan for few seconds. I guess even on CES or other shows like this where WiFi and Bluetooth are everywhere and people are walking around and scanning it is not that terrible. Although I have never been there, just heard that there were problems with connectivity but now not complete DoS. And this is a kind of an extreme environment. Btw, if you want to block BLE it's best to use a good WiFi router that takes all space available. BLE nodes are too lazy in doing so.

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

Roger Clark — Mon, 06 Mar 2017 11:08:31 GMT

Thanks Aleksander

I have not upgraded to Android 6 yet, to use the Web BLE API, but my understanding was that the user had to approve it once, but I don't think this is much of a barrier as most users just click Yes when asked to turn on Bluetooth. And I'm not sure if its once per page or just Once per every time Chrome is run.

I'm not sure if this feature will always off by default. The settings were in the experimental section of the currently released version of Chrome for Android, but I can't see them in the Chrome Beta App, so I presumed that in the next release (i.e when the beta gets released) that this feature will be On by default.

BTW. On iOS, it will scan in the background, but it appears to slowly increase the interval between each scan, the longer you leave it scanning. However its easy to stop the scan and start it again e.g. every 15 seconds, even in the background

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

endnode — Mon, 06 Mar 2017 11:00:40 GMT

I totally agree that Web BLE API shouldn't be any danger in terms of DOS (it will provide other attack vectors;), because even if you would stay for longer time on such web site and enabled access to BLE it would hardly achieve such activity from generic BLE chip set. These DOS scenarios described by me above (flooding adv. channels or connecting to every ADV_IND packet which comes around) are already difficult if you run it as embedded application on nRF5x chip and SD S13x, you would most likely need several such fixtures to really block the Peripheral. Web BLE API could disturb BLE app (especially if it isn't designed properly) but I don't think that's worth writing an script by some kiddie;)

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

Aleksander Nowakowski — Mon, 06 Mar 2017 10:53:01 GMT

Web BLE API requires users to actively select Scan for devices, where Chrome popup shows on top of the screen showing devices. A website can't scan on it's own. Also, as far as I know web-ble is still by default disabled feature (?) in Chrome and needs to be enabled in flags config. developers.google.com/.../interact-with-ble-devices-on-the-web

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

Aleksander Nowakowski — Mon, 06 Mar 2017 10:51:12 GMT

Hi, some insights from an Android developer. Background scanning on Android of course can be done using high power scanning, but it's a very bad practice and leads to draining the battery quickly. There are 4 options to scan: high power (continuous), balanced (2 sec out of 5), low power (0.5 sec/5 sec) and opportunistic (app gets updates only when another app is scanning). All Android tools, like Physical Web or Google Play service, that may scan in the background, do it in least disturbing mode, so more phones are required to fully block connections, unless all they open their favorite app (nRF Connect, of course ;) ) and start scanning at the same time. Also, it used to be, that some phones (Nexus 4 or 7) were sending only one Scan Request per scanning to one device. This approach was preventing from DoS, but also from tracking changing RSSI, so it has been fixed.

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

endnode — Mon, 06 Mar 2017 10:44:00 GMT

Thanks Alex, this is interesting, I'm obviously not mobile developer so I missed that! It's worth trying, will recommend to our mobile development team...

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

Aleksander Nowakowski — Mon, 06 Mar 2017 10:41:45 GMT

Hi, on Android you may set the TX power for advertisements. There are 4 options to choose from: -21 bBm, -15 dBm, -7 dBm and +1 dBm. You may also set the connectible/non-connectible flag. On iOS there also should be something like that (see CBAdvertisementDataTxPowerLevelKey).

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

endnode — Mon, 06 Mar 2017 10:23:53 GMT

Thanks, this is helpful (although not applicable when GAP Peripheral is also mobile phone where you cannot affect such low-level BLE parameters;). So have you heard about such complains from the users of your chips or during your in-house tests/demos?

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

Hung Bui — Mon, 06 Mar 2017 10:21:15 GMT

Hi Jan,

I agree on what you are discussing in the comments. It could be an issue if we have an environment where several phones, device keeps scanning and sending scan request or connection request.

I just want to add, some solutions if you want to establish a connection in a crowded environment:

Reduce TXpower when advertising, and put the device you want to connect closer to your central. This is to avoid the unwanted scanners to send scan/connect request.
Use Out of Band to send address of the central to your peripheral for example with NFC. After that let the peripheral advertising in directed mode so that other scanner will not send scan/connect request

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

Roger Clark — Sun, 05 Mar 2017 20:07:15 GMT

Hi Jan

My concern was not for a hardware DOS style attach, where the channels were effectively jammed by sending random noise, as I dont know if its possible to write a phone app to make the phone hardware do that.

I was more concerned with web pages maliciously using the BLE web api without the user knowing it was happening. i.e if an app deliberately does this, its likely google and apple would remove it from their App stores. But scripts on websites are a lot harder to ban.

At the moment I dont know enough about the BLE protocol to know how to defend from the script kiddie type DOS attack.

I have investigated multiple beacons in close proximity ( 100 beacons in the same room) and I did not see to many problems with this, but I have not tried lots of phones and a few beacons. I suppose I could simulate this by reflashing my Smartbeacons with some Central code.

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

endnode — Sun, 05 Mar 2017 11:30:21 GMT

... if applications are in the foreground (which is unusual) or it is something pretty recent so similar reports are yet to come.

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

endnode — Sun, 05 Mar 2017 11:29:23 GMT

Few more things on the issue:

It really looks like having any mobile app on mobile which causes heavy active (SCAN_REQ) scanning in GAP Scanner/Central role can take 15-30% of available "slots" (aka RX windows following ADV_IND packets from GAP Peripheral) so at 3-4 devices in the range you wills tart to observe occasional collisions and with 5-6 you will already have big troubles to find any available RX window to start connection.
Note that this can be hardly prevented as users can have BT enabled and any application running and you can do very little about it.
This would mean that any "dense" areas such as airports, office spaces, rush streets etc. should be full of such "DOS" zones. However there seems to be no such complains so I'm wondering if this "heavy scanning" behavior is limited only to few devices (I've tested Samsung Galaxy S6/7/8) or it happens only...

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

endnode — Sun, 05 Mar 2017 11:12:36 GMT

Hi Roger, you are right, there are two well known and pretty easy DOS attacks on BLE:

"flooding" all 3 adv. channels (or entire 40) with noise
connecting to every adv. packet issued (so peripheral device won't be available for legitimate Central).

Note that there is almost no mitigation possible and that's also reason why you will have big problems to deliver radio-based applications to critical applications such as healthcare, military and security. Anyway that's not what I'm describing here. For two DOS scenarios I've mentioned you need to be active attacker with clearly malicious intentions (or absolutely ignorant to standards and regulations) so you could track it and put the attacker down. The scenario I'm describing in this question is different: all the parties behave normally and perfectly according to the specifications, yet they create DOS when reaching critical mass.

RE: Heavy scanning activity from Android (and iOS) devices might prevent connecting to BLE GAP Peripheral

Roger Clark — Sun, 05 Mar 2017 03:01:53 GMT

Hi Jan

I can see DOS attacks being more and more common, especially with the BLE Web API being released by Google recently (in Chrome)

I have thought about defence strategies for this, and one option I considered was changing the "connectable" flags if your software thinks its under DOS attack

e.g. just turn it off for a few seconds, of perhaps longer.

But. I've not tried this myself yet.

I also looked at trying to prevent devices connecting in an attempt to flatten the battery.

So I tried immediately disconnecting, if the first attempt didn't immediately write to a custom (authorisation) characteristic, with a password. But it didnt help, because Android appears to immediately tries to reconnect, over and over again, until it times out (which seems to take around 5 secs)

Hence I considered changing the connectable flag, but didnt have time to investigate whether that would work