Is it possible to refuse a connection from a central device?

[Yannick L]

I'm developing a project based on the Nordik UART Service and I wouldn't use pairing as in the example.

However I have some problem when a central device is already connected to my nRF52, if I try to connect a second central, I don't have any refuse but some sort of timeout from my second central.

It's actually possible to refuse a pairing by responding BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP on a BLE_GAP_EVT_SEC_PARAMS_REQUEST, is it possible to do something similar with connection to clearly signal to a new central device that the peripheral isn't accessible or the only asumption is that the advertisement will stop after a connection ?

Thanks

[endnode]

You cannot "refuse" connection by forcing Soft Device to "ignore" CONNECT_REQ packet but you can terminate connection any time from any side so you can terminate it on very next connection interval if you want.

[Edit]

Sorry, I've probably misunderstood. If you speak about issuing CONNECT_REQ from GAP Central side then it's little bit strange. If Peripheral is ready for connection it advertises. If it doesn't then there is no advertisement hence nowhere to connect. If you want to just broadcast there are non-connectable advertising formats. If you want to accept connection only from certain Central there is directed advertisement. What exactly is your problem?

[Yannick L]

Imagine that 2 central a seing the advertising from the device. The first central initiate the connection with the device and it's then connected.

The second central doesn't receive anymore the advertisement but keep a trace of the discovered device (in Android for example, you will still see the device in the list). At this moment, if you try to connect your second central to the device, there is a timeout (on my test however, I may be modified something wrong).

I agree this is a special situation which doesn't append very often but I would like to know if there is something to handle this case or at least to understand the process behind this case.

Based on your response, I understand that in this case, I can't refuse CONNECT_REQ packet.

Thanks

[RK]

The delay has nothing to do with the already connected peripheral or central, you've not understood the message flow in BLE for connections.

Connection is ONLY attempted as a response to an advertisement packet (a connectable one) so when you ask a central to connect to a peripheral what it actually does is scan for advertising packets from that peripheral and when it sees one, sends the connect request. So in this case the peripheral has connected and it's stopped advertising so the second central never sees an advertising packet, never sends out a connection request and eventually times out.

It should be clear then there is nothing you can do on the peripheral to deal with this. The peripheral doesn't even know a second central is trying to connect to it because the second central hasn't done anything yet.

So what you need to do is fix the central to time out faster.

[Yannick L]

Understood, so this behavior is related to Android in my case. Thank you for the help

[endnode]

Yes. All BLE apps which work as GAP Central should be ready for situation where you see Advertisement but it suddenly disappears (wither another device connected to it or it was turned off or went too far away). On most platforms you should have visibility on adv. interval and time since last adv. packet received so you could act accordingly (e.g. don't connect to devices which are not seen for 5/10/20 adv. intervals). But there will always be cases where GAP Peripheral stops right at the moment GAP Central tries to connect so it will timeout.