Always reconnect after peers deleted

RE: Always reconnect after peers deleted

Borden — Tue, 30 May 2017 12:07:04 GMT

Ok Petter, thanks for your help, that's kinda sad, looks like I can only accept it for now, I'm going to try changing the address later.

RE: Always reconnect after peers deleted

Petter Myhre — Tue, 30 May 2017 11:44:44 GMT

I see.

There is no event before BLE_GAP_EVT_CONNECTED.

I don't see any other option than changing the device address.

RE: Always reconnect after peers deleted

Borden — Tue, 30 May 2017 11:36:37 GMT

Alex, I have no apps, and also I can't sacrifice the compatibility of my device to do that:)

RE: Always reconnect after peers deleted

Borden — Tue, 30 May 2017 11:31:00 GMT

Hi Petter again:)

Yes I use bt setting directly, we're making a generic gamepad, we have no apps.

By "disconnect from A" I mean disconnect from A's bt setting panel. I tested on 2 Android phones and an iphone, one Android phone won't auto reconnect while disconnect from the setting panel, another one will, as for iPhone, there's no way to explicitly disconnect without unbond. So as you can see, things differ, there's no safe bet on how these phones react.

I wonder if there's an event when central initiated a connecting request but before BLE_GAP_EVT_CONNECTED? if we have that chance, then we can partially solve my problem with blacklist while disconnection is initiated from peripheral.

RE: Always reconnect after peers deleted

Alex — Tue, 30 May 2017 11:22:17 GMT

You can implement your special command over one of your characteristics. Once central sends that command to peripheral then peripheral will disconnect from that central and start ignoring reconnection for certain period of time. After timeout peripheral will return to normal mode

RE: Always reconnect after peers deleted

Borden — Tue, 30 May 2017 11:11:58 GMT

Thanks Alex, that question is very helpful, let me know that someone had been in a similar situation as I am.

To be a flawless device, I think only blacklist is not enough, even if it can be implemented(which I don't know). Blacklist can solve the problem which disconnecting is initiated from peripheral, but often disconnecting is originated from central, in this case, we don't know if it's on purpose, or due to radio jam, so we can't simply refuse to reconnect request anyway, without knowing the cause.

RE: Always reconnect after peers deleted

Petter Myhre — Tue, 30 May 2017 10:58:25 GMT

Now I understand your problem a bit better I think.

Are you using Bluetooth Settings directly? Or do you have an app?

When you say "if I disconnect from A", how are disconnecting? Are you disconnecting from the gamepad or from the smart phone? If you disconnect (not delete bond) from the smart phones Bluetooth Settings my experience is that it doesn't autoconnect. Let me know if you are experience something else. If not, could it be a solution?

Yes, the 6 byte device address. If you use two different, you can use it to decide which device you want to automatically connect to you. You can also alternate between them (after bonded) if you want both autoconnect.

RE: Always reconnect after peers deleted

Alex — Tue, 30 May 2017 08:42:32 GMT

I see now. Look at this question.

RE: Always reconnect after peers deleted

Borden — Tue, 30 May 2017 08:29:28 GMT

Hi Alex, nice to see you again:)

Still, I don't think WL is really the essential in my situation. I feel what's really matter is, to find a way to tell accidentally disconnection from disconnection on purpose. Once I can do that, then the WL is just involved in how to deal with these to situations.

RE: Always reconnect after peers deleted

Alex — Tue, 30 May 2017 07:20:24 GMT

I'm not very familiar with WL code but from what you explain I understand that you need to modify it so it will work in two modes. One is how it works now where it will accept only bonded connections, and second one will work in reverse rejecting only bonded connections. kind of black list. If whitelisting done in SD then it will be difficult to implement without Nordic help.

RE: Always reconnect after peers deleted

Borden — Mon, 29 May 2017 18:36:00 GMT

As for changing address, I'm not sure what address you were talking about, is the 6 bytes bt address? I'm only a newbie in BLE dev. No matter what address it is, if I change it to bond with B, then B must have a different address in its bond info from A, then my device will not be able to connect to both of them with a single address, is that correct?

RE: Always reconnect after peers deleted

Borden — Mon, 29 May 2017 16:20:53 GMT

Let me describe my dilemma in a more generic way, from a user's perspective.

Say I have two Android phone A&B, in the same place, then I realize there's no elegant way to add them both in my device's whitelist.

Once my device bonded with A,

if I disconnect from A, it will reconnect to A instantly, I have no chance to be discovered by B;
if I power up it with pm_peers_delete(), it will reconnect to A anyway, and since I want to add both A&B in my WL, deleting peer is not an option;
delete bond from A is a feasible way, but not elegant, they need to repair later;
turn off BT of A is currently my best choice, but still not so elegant, because A may have connected with other BT devices which I don't like to cut off.

And although I don't really understand why it's not possible to have my device connectable without a whitelist, I've still kept it, I merely don't advertise with it, because I haven't actually see the point of adv with WL in my scenario yet. If I do adv with WL, even if I turn the BT of A off, to let my device restart advertising, B still can't discover it cause B is not in it's WL. that's the reason why I set options.ble_adv_whitelist_enabled = false;

RE: Always reconnect after peers deleted

Petter Myhre — Mon, 29 May 2017 12:15:34 GMT

Yes, set .allow_repairing to true.

It is not possible, without a whitelist any device can connect to your device. There are ways of figuring out if a device has been bonded with you before after you have connected, and then disconnect if the device is not familiar with you. See this for more information. Can changing the device address work for you? So that the phone that has deleted its bond can't recognize your device?

RE: Always reconnect after peers deleted

Borden — Mon, 29 May 2017 10:51:57 GMT

Oh I see now, turn out the phone is in the leading role:

if the phone has bonding info but my device hasn't, they will connect anyway;
if the phone has no bonding info but my device has, repairing will be rejected.

So based on my usage scenario, I'd like to reverse it. For the latter situation, I think I know how to handle, as you said, just don't reject the pairing request, in the case PM_EVT_CONN_SEC_CONFIG_REQ, right? But for the former situation, I still don't know how to let them not to reconnect, since in that situation the WL is empty, my device have no idea if the connection request is from the last host.

Now I've thought this through, what I really want is, in a situation a new host which my device has no bond info about, send a connection request, if the host has no bond info of my device either, accept it; if the host has, that means I have deleted bond info from the device, then reject it. Is this possible?

BTW I'm using SDK12, s130v2.

RE: Always reconnect after peers deleted

Petter Myhre — Mon, 29 May 2017 09:23:28 GMT

If you don't use whitelist your gamepad will accept any connection request, and if you have configured the phone to reconnect it will do that regardless if you have deleted bonds or not, it doesn't know that you have deleted the bonds on the gamepad. If you don't want your phone to reconnect you can configured it not to reconnect, delete the bond information on the phone, or change the device address of your gamepad.
Do you mean if you delete bond on the phone, but not on the gamepad? Then you should be able to make a new bond, but I believe the default SDK behavior is to reject pairing requests from peers that it already has bonds with. Which SDK are you using?

RE: Always reconnect after peers deleted

Borden — Mon, 29 May 2017 09:05:36 GMT

Thanks for your tips Petter, but WL and advertising is actually irrelevant to my question, currently I've always keep WL disabled while advertising.

What I expect is:

Once I have all peers deleted during power up, my gamepad should not automatically reconnect to last host, but keep advertising.
Once I delete bond info on my phone while connected, the gamepad should restart advertising and appear again in the available device list again, then if I click it, it should connect and bond again.

But what I get is:

No matter if peers are deleted during power up, the gamepad always auto-reconnected to my phone.
If bond info is deleted on my phone, the gamepad restarts advertising and appear in the available device list as I expected, that's fine. But if I click it, the phone pop up an err message says device refused pairing request.

So I just want to know how to correct this to what I expected? Or maybe my expectation is impractical?

RE: Always reconnect after peers deleted

Petter Myhre — Mon, 29 May 2017 08:32:15 GMT

As Alex said, it doesn't make sense to do connectable advertising with an empty whitelist, because then no device will be able to connect to you. You are probably doing advertising without a whitelist. If you don't want the Android device to recognize your device, you can try to change the device address.

RE: Always reconnect after peers deleted

Borden — Sat, 27 May 2017 01:27:50 GMT

of course I've tried adv with WL, like I said above, I've tried every possible way, none of them can stop it from auto reconnect to host.

RE: Always reconnect after peers deleted

Alex — Fri, 26 May 2017 15:21:50 GMT

There are probably several ways to manage bonding in different SDKs. I use Device Manager. From examples in device_manager_init() it is enough to set init_data.clear_persistent_data=true; to clear bonded devices , whitelist will be cleared as well. Do you advertise with whitelist by the way? If whitelist is empty then probably no point advertising at all? ble_advertising_start() function if can't find Whitelist(empty) will advertise without whitelist, so you need to control this situation.

RE: Always reconnect after peers deleted

Borden — Fri, 26 May 2017 14:59:42 GMT

But when I enabled the whitelist, and had all peers deleted, I thought the whitelist should be empty then, right? but it still reconnect automatically in the blink of an eye.

Whitelist, no whitelist, bonds, no bonds, I've tried sorts of ways, haven't found one to prohibit this behavior yet.

RE: Always reconnect after peers deleted

Alex — Fri, 26 May 2017 14:15:53 GMT

Another thought. Most of Android devices I used don't automatically reconnect unless background application is trying to connect to bonded device. But I do remember on one Android tablet I had autoconnection by Android.

RE: Always reconnect after peers deleted

Alex — Fri, 26 May 2017 14:08:43 GMT

It is expected behavior. Android remembers bonding information and automatically tries to connect to BLE device. Then BLE device accepts connection. If you want to stop that connection then either delete bonding information from Android or somehow reject any connection you don't want. As I mentioned Whitelist will reject unwanted connections.

RE: Always reconnect after peers deleted

Borden — Fri, 26 May 2017 13:58:49 GMT

Thanks for your tips Alex. My problem is not being rejected, but is accepted anyway, the whitelist is disabled on purpose, but have no effect yet, my device still auto reconnect stubbornly.

RE: Always reconnect after peers deleted

Alex — Fri, 26 May 2017 13:40:26 GMT

For the way you want it to work you need to start using Whitelisting in your BLE device. Any connection from device not in white list will be rejected.