This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Dear Nordic team and community,

Have you encountered the problem where standard BT4.0/4.1 GAP Peripheral device would be "blocked" from connection (kind of "denial of service" situation) by too many actively scanning GAP Scanners/Centrals? We are seeing this with certain mobile phones (especially Android) in "observing" role and this is pretty independent on adv. interval we use (typically 20-200ms). All adv. events are "loaded" with SCAN_REQ packets when there are 5 or more "scanning" phones and beside SCAN_REQ collisions (which are typically not critical for BLE solutions) basically all CONNECT_REQ collide with some SCAN_REQ packet and thus Peripheral never follows the connection.

Any suggestions (beside trying to lower scanning activity on phones' side which obviously isn't always possible)?

Thanks Jan

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

    1. "flooding" all 3 adv. channels (or entire 40) with noise
    2. 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.

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

    1. "flooding" all 3 adv. channels (or entire 40) with noise
    2. 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.

Children
No Data
Related