Android asking for pairing after DFU

RE: Android asking for pairing after DFU

Einar Thorsrud — Thu, 08 Sep 2022 15:28:19 GMT

[quote user="Randy Lee"]Is it possible for the android app to be asking for connections and keys before something is ready on the device side to deal with it so that it thinks that the information hasn't been stored?[/quote]

I did not test this, but if you start advertising before initializing the peer manager that might be the case. Normally you will do all initialization in the firmware before starting to advertise, though. Can you check that in your firmware?

However, I do not expect this is the issue. Normally, if the bonds were lost on the nRF for some reason, the Android phone would first try to secure the link using the existing bond, and if that does not exist on the nRF, securing the link would fail and it would disconnect. However, in both your description and the sniffer trace there is no sign of the Android trying to secure the link using an existing bond. Instead, it attempts to bond right away. This is not expected behavior. Can you double check if the bond gets erased on the Android at some point before connecting again after the DFU? (I cannot say what should delete it).

[quote user="Randy Lee"]about the DFU port: This is pretty much a straight up SDK.. the backport from another SDK is in the main application not the bootloader itself.[/quote]

I see. Based on what I have seen so far there is nothing pointing to an issue in the nRF firmware, but for some reason the Android device misbehaves (trying to re-pair to a device it is already bonded to). The question is why this happens. And to be frank, I have never seen any reports of this before.

RE: Android asking for pairing after DFU

Randy Lee — Wed, 07 Sep 2022 17:51:02 GMT

thought: The device is using all the normal Nordic code and mechanisms for this stuff along with the soft device. Keys and such are stored in FDA areas as usual (see above). Is it possible for the android app to be asking for connections and keys before something is ready on the device side to deal with it so that it thinks that the information hasn't been stored?

Thinking outside the box here. I don't see how, but then again, things happen with embedded systems that aren't always obvious.

RE: Android asking for pairing after DFU

Randy Lee — Wed, 07 Sep 2022 15:44:20 GMT

Greetings Einar!

Yes, this is generally reproduced using mobile version of nRFconnect on Android phones.

RE: Android asking for pairing after DFU

Randy Lee — Wed, 07 Sep 2022 15:42:53 GMT

about the DFU port: This is pretty much a straight up SDK.. the backport from another SDK is in the main application not the bootloader itself.

RE: Android asking for pairing after DFU

Einar Thorsrud — Wed, 07 Sep 2022 13:07:26 GMT

Hi,

I have inherited this case from Edvin.

Looking at connection after DFU.pcapng, everything looks normal, as if connecting to a device with no existing bond. My first gut feeling after reading this thread was that perhaps the nRF BT address was different, but that is the same in both traces, so that is not it. Could it be that your custom app for some reason deletes the bond when performing DFU? Are you able to reproduce this using only nRF Connect for mobile and not your app at all (make sure it is not running in the background as well)?

Einar

RE: Android asking for pairing after DFU

Randy Lee — Tue, 06 Sep 2022 11:33:01 GMT

TOok some time as we had to get the hardware to do this, but attached are the sniffer logsdevzone.nordicsemi.com/.../connection-after-DFU.pcapng devzone.nordicsemi.com/.../normal-connection.pcapng

RE: Android asking for pairing after DFU

Edvin — Mon, 01 Aug 2022 14:03:35 GMT

Hello,

Ok. I am back (and will stay for a while this time).

Can you please try to capture a sniffer trace of the connection being entered. Preferably one after a DFU, and one with a normal connection (where the bonding is not requested). Please note that in order for the sniffer to be able to follow into a bonded connection, you probably need to erase the bonds, connect -> bond -> disconnect -> reconnect for the sniffer to be able to capture the LTK. If you are using OOB (6-digit passkey), you need to enter this manually in the sniffer.

To capture a sniffer trace, you can use the nRF Sniffer for Bluetooth LE.

And again, if there is some way for me to reproduce this, please zip a project application that can reproduce the issue. You say that it is a slightly modified ble_app_buttonless_dfu application, but please zip the one that is used for reproducing the issue. I also see that you are mixing a few different SDK versions. Can you please try to stick to one, and see if it is still reproducible, just to make sure that it is not the backport that is causing something to behave weirdly?

Best regards,

Edvin

RE: Android asking for pairing after DFU

Randy Lee — Thu, 21 Jul 2022 15:15:37 GMT

Oh, and, I understand the time thing in the summer.... Thank you for being able to keep following this thing...

RE: Android asking for pairing after DFU

Randy Lee — Thu, 21 Jul 2022 15:14:28 GMT

The "Allow repairing" thing is a code note to myself meaning, in this case, that we've got something in the whitelist and to allow that MAC address to talk to me. The app is very locked down here using whitelists to not allow anyone to connect to it unless it's gone through some serious upper level handshakes. This notation just says that, yes, the whitelists survived the update. Those whitelists use fds so that are hasn't been wiped (this was a previous bug that we had in the code)

1) Yes, we're using a couple of different ones. One team tends to use a Pixel and most of the other teams tend to use a Lenovo tablet. Different versions of Android.

2) The bootstrap here is effectively the buttonless dfu using SDK15.3 (with a couple of mods backporting some SDK17 fixes). devzone.nordicsemi.com/.../5707.bootloader.zip

RE: Android asking for pairing after DFU

Edvin — Thu, 21 Jul 2022 13:07:16 GMT

I assume that since the log says "Allow repairing: 1", that the phone requests to pair again, as if it has lost the bonding information. Exactly why the phone decides to do that, I am not sure.

1: Did you test this with different android phones? If not, can you please do?

2: Is there some way for me to reproduce this? Did you try to reproduce it using the ble_app_buttonless_dfu example? If so, can you zip that modified ble_app_buttonless_dfu example so that I can try to reproduce the issue, preferably without doing too many changes to the rest of the SDK?

I am sorry for the long response time. We are a bit understaffed during the summer holidays. Sorry for the inconvenience.

Best regards,

Edvin

RE: Android asking for pairing after DFU

Randy Lee — Mon, 11 Jul 2022 14:57:19 GMT

Yes, I get that... interestingly enough a couple of times...

00> [1634809769.258] Baby service: Version=0.8.4.10, Family=91, ProgramChecksum=05107740
00> [1634809769.261] BLE: bounds: peer_count: 1
00> [1634809769.261] BLE: bounds: peer id 0 is valid
00> [1634809769.261] BLE: bounds: peer address: f0:5c:77:f5:2f:63
00> [1634809769.262] FDS: File found
00> [1634809769.262] FDS: File read successfully
00> [1634809769.262] BLE: Whitelist contains a peer. Start advertising.
00> [1634809769.262] Whitelist: Applied whitelist with addr_cnt=1 irk_cnt=1
00> [1634809200.272] SIM Restart
00> [1634809200.274] temperature: 26.0C
00> [1634809200.275] Vbat: 100% (2.52V)
00> [1634809200.290] LOG: 242,9,0x00,0x00
00> [1634809200.345] Motion set: a=-0.158072, A[xyz]=0.005859,-0.115234,-0.833984
00> [1634809200.516] Switched from event 0 to event 11
00> [1634809200.536] LOG: 11,9,0x00,0x00
00> [1634809201.766] BLE: Unhandled PeerManager event 5 (PM_EVT_CONN_SEC_PARAMS_REQ?)
00> [1634809201.766] BLE: Unhandled PeerManager event 8 (PM_EVT_PEER_DATA_UPDATE_SUCCEEDED)
00> [1634809201.766] BLE: Bonded Peer Connected (PM_EVT_PEER_DATA_UPDATE_SUCCEEDED)
00> [1634809201.767] BLE: Unhandled PeerManager event 14 (PM_EVT_LOCAL_DB_CACHE_APPLIED)
00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
00> [1634809201.768] BLE: Peer connected (PM_EVT_BONDED_PEER_CONNECTED)
00> <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 27 bytes.
00> <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
00> <debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
00> [1634809201.951] BLE: Data len is set to 0xF4(244)
00> <debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.
00> <debug> nrf_ble_gatt: max_rx_octets: 27
00> <debug> nrf_ble_gatt: max_tx_octets: 251
00> <debug> nrf_ble_gatt: max_rx_time: 328
00> <debug> nrf_ble_gatt: max_tx_time: 2120
00> <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes.
00> <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
00> <debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.
00> <debug> nrf_ble_gatt: max_rx_octets: 251
00> <debug> nrf_ble_gatt: max_tx_octets: 251
00> <debug> nrf_ble_gatt: max_rx_time: 2120
00> <debug> nrf_ble_gatt: max_tx_time: 2120
00> <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes.
00> <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
00> <debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.
00> <debug> nrf_ble_gatt: max_rx_octets: 251
00> <debug> nrf_ble_gatt: max_tx_octets: 251
00> <debug> nrf_ble_gatt: max_rx_time: 2120
00> <debug> nrf_ble_gatt: max_tx_time: 2120
00> [1634809204.405] BLE: Unhandled PeerManager event 1 (PM_EVT_CONN_SEC_START)
00> [1634809204.409] BLE: Unhandled PeerManager event 5 (PM_EVT_CONN_SEC_PARAMS_REQ)
00> [1634809204.410] FDS: File found
00> [1634809204.410] FDS: File read successfully
00> [1634809204.410] Whitelist: check Whitelist file found. peer_id=0
00> [1634809204.410] BLE: Allow repairing: 1
00> <info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 0, procedure: Bonding
00> [1634809206.511] BLE: Unhandled PeerManager event 8 (PM_EVT_PEER_DATA_UPDATE_SUCCEEDED)
00> [1634809206.511] BLE: Unhandled PeerManager event 2 (PM_EVT_CONN_SEC_SUCCEEDED)
00> [1634809206.515] BLE: Unhandled PeerManager event 8 (PM_EVT_PEER_DATA_UPDATE_SUCCEEDED)
00> [1634809206.519] BLE: Unhandled PeerManager event 8 (PM_EVT_PEER_DATA_UPDATE_SUCCEEDED)
00> <debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes.
00> <debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
00> <debug> nrf_ble_gatt: Data length updated to 251 on connection 0x0.
00> <debug> nrf_ble_gatt: max_rx_octets: 251
00> <debug> nrf_ble_gatt: max_tx_octets: 251
00> <debug> nrf_ble_gatt: max_rx_time: 2120
00> <debug> nrf_ble_gatt: max_tx_time: 2120
00> [1634809207.347] BLE: Unhandled PeerManager event 8
00> [1634809211.634] Play Sound 13, 0xD
00> [1634809216.951] Whitelist: Applied whitelist with addr_cnt=1 irk_cnt=1
00> [1634809216.952] BLE: Peer disconnected

RE: Android asking for pairing after DFU

Edvin — Mon, 04 Jul 2022 08:31:51 GMT

[quote user="Randy Lee"] I don't know what the second one is, but it's possible it's the same device as Android phones can apparently change MAC addresses from time to time[/quote]

Yes they do, but they shouldn't take up more than one peer. There are mechanisms to recognize peers that have changed addresses using an IRK (Identity resolving key).

When you connect to the bonded device after the DFU is performed, do you get the event (on the nRF) PM_EVT_BONDED_PEER_CONNECTED?

BR,

Edvin

RE: Android asking for pairing after DFU

Randy Lee — Mon, 27 Jun 2022 21:01:52 GMT

so we got that code to work... I've annotated the output from that code with "bounds: " so as to note it specifically from the other things that are logging... You'll find it towards the back. This output here is right after the thing is booting after a DFU:

00> [1634810895.013] POR Vbat: (2.41V)
00> <debug> nrf_sdh_freertos: Creating a SoftDevice task.
00> <debug> ble_scan: Adding filter on RWStudentID name
00> <debug> nrf_sdh_freertos: Enter softdevice_task.
00> [1634810895.253] FDS: File found
00> [1634810895.253] FDS: File read successfully
00> [1634810895.253] Whitelist: Whitelist file found. peer_id=0
00> [1634810895.255] FDS: File found. Writing data into it
00> [1634810895.255] FDS: Write succeeded.
00> [1634810895.260] Baby service: Version=0.8.4.9, Family=91, ProgramChecksum=87778671
00> [1634810895.263] BLE: bounds: peer_count: 2
00> [1634810895.263] BLE: bounds: peer id 0 is valid
00> [1634810895.263] BLE: bounds: peer address: f0:5c:77:f5:2f:63
00> [1634810895.263] BLE: bounds: peer id 1 is valid
00> [1634810895.263] BLE: bounds: peer address: 94:be:46:11:e2:5b
00> [1634810895.265] FDS: File found
00> [1634810895.265] FDS: File read successfully
00> [1634810895.265] BLE: Whitelist contains a peer. Start advertising.
00> [1634810895.265] Whitelist: Applied whitelist with addr_cnt=1 irk_cnt=1

The first one (peer ID 0) is the current MAC address of the device talking to it.. I don't know what the second one is, but it's possible it's the same device as Android phones can apparently change MAC addresses from time to time (this one is a Pixel 4 running Android 11

RE: Android asking for pairing after DFU

Randy Lee — Fri, 24 Jun 2022 18:37:20 GMT

Our app uses the Nordic buttonless bootloader as the base for the bootloader portion and is called by the application to get it started..

The version we're running has those parameters set:

    add_char_params.cccd_write_access = SEC_OPEN;
    add_char_params.write_access      = SEC_OPEN;
    add_char_params.read_access       = SEC_OPEN;

since we can't get there but by a bonded thing that is explicitly whitelisted.

I'm still attempting to get the number of peers seen. For some interesting reason that particular piece of code is being an issue in situ. It gives me an output using SES directly but not if I'm using RTT viewer. Curiously all the stuff around it gives me output so I'm having some experiments done to figure out just why that it... I hope to have some usable data early next week.

RE: Android asking for pairing after DFU

Edvin — Tue, 21 Jun 2022 09:02:05 GMT

As it is mentioned in that ticket, you need to enable the SERVICE_CHANGED in sdk_config.h of your application. Ironically, adding it later wouldn't help, but if you add it in your initial application, that should solve that. So for the phones that have already cached the services, First forget the device from the iPhone's bluetooth menu, then turn off bluetooth from the phone's settings (Settings menu, not the "drag up from bottom menu"). Wait for about 15 seconds, and turn bluetooth back on. Then it should be forgotten. Then, if you have the service changed service enabled, then the peer manager will use this to tell the phone to do a new service discovery if it has new services.

Now, regarding our issue:

I need you to check the number of peers in the peer manager (using the snippets in my answer from 13th of june.

Does this also happen if you use the "normal" bootloader and e.g. the ble_app_buttonless_dfu example to perform the update? Did you test this? If you test this with ble_app_buttonless_dfu, there is a setting in sdk_config.h called NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS. Leave this set to 0, because this does a couple of things. Then try to open ble_dfu_unbonded.c, and set:

    add_char_params.cccd_write_access = SEC_JUST_WORKS;
    add_char_params.write_access      = SEC_JUST_WORKS;
    add_char_params.read_access       = SEC_OPEN;

in ble_dfu_buttonless_char_add(). That should trigger the pairing/bonding in the app, and then you can perform a DFU and try to connect again. Does that trigger the issue where you need to bond again?

NB: This example already have the NRF_SDH_BLE_SERVICE_CHANGED set to 1.

Best regards,

Edvin

RE: Android asking for pairing after DFU

Randy Lee — Mon, 20 Jun 2022 13:51:15 GMT

iOS: my engineers are reporting that iOS does not have this problem..

They did run into a services cache problem on that platform, but that's another problem (see https://developer.apple.com/forums/thread/76339)

RE: Android asking for pairing after DFU

Edvin — Mon, 20 Jun 2022 08:03:46 GMT

I understand.

Well, sometimes a custom log can give some insight in whats going on, but it is not always conclusive.

For the iOS part, if you are using the standard bootloader from the nRF5 SDK (without too much modifications), you should be able to use the nRF Connect for iOS app to perform the update, and then try to connect to it afterwards, to see if it also requires to re-bond. This is just for debugging purposes, to see whether this issue is limited to Android, or on all platforms. Perhaps it can narrow down possible reasons for this behavior.

Best regards,

Edvin

RE: Android asking for pairing after DFU

Randy Lee — Fri, 17 Jun 2022 14:19:34 GMT

This is full custom hardware; I rarely use a dev kit from anyone as they are so limiting to what I do. Reproducing it on the DK would be difficult as there is so much code there that assumes custom hardware. Also we've seen this over 5 or 6 products all with the same basic code base.

As to Android version, We've seen it on 10 and 11 (these logs were produced with an 11 connection). Never tried it on iOS as we don't have the app we use with it on iOS and it's rather difficult to get the connection to begin with without the app. We can try it at some point here tho as that would be something instructive I think.

Line 52 is saying that, when it comes back from POR, that there whitelist is still intact in flash storage. That implies to me that any bonding information kept in the same basic storage place would be still intact. I will have to verify that with your code suggestion the next time I get a chance.

Line 54 has what I assume is step 3 pairing requests and whatnot coming through. Ignore anything labeled "RFID:" It's about 5 seconds later (line around 188) where we see the bonding completion....

The upshot is that these logs aren't as informative as they could possibly be. I don't have an air sniffer at present to see the traffic here, which would be far more informative, and for that I apologize.

RE: Android asking for pairing after DFU

Edvin — Fri, 17 Jun 2022 06:59:27 GMT

Are you reproducing this on a DK or custom HW? If custom, can you try to reproduce it on a DK? And does it only happen on a certain Android version (10) or on any android version? And have you tried iOS? Is there some way for me to replicate this issue on a DK with a phone? Preferably iOS, but I can try to get hold of an Android if I need to.

From the logs, you are saying that on line 52, when it says "applied whitelist with addr_cnt=1 irk_cnt=1", it will still go through the pairing process? Is there anything in the logs saying when you need to pair or not?

BR,
Edvin

RE: Android asking for pairing after DFU

Randy Lee — Thu, 16 Jun 2022 14:17:39 GMT

Sorry, I forgot to say what we did exactly here... This is using Android 11 as the initiator

Set DFU mode
- Set promiscuous mode on device (put it into a reception state where it is ready for bonding)
- Connect
- Pair
- Join (this is our special thing that tells it to whitelist the thing that bonded)
- Send BOOTLOADER command (line 38)
- Disconnect
DFU (this wouldn't be in the logs because the bootloader doesn't have that kind of instrumentation)
- Connect with nRFconnect
- Do DFU
- Disconnect
Restore bonding
- Connect with nRFconnect (line 53)
- Pair
- Disconnect

Search the document for POR; That the Power On Reset points so those are the points where the application running is regaining control from the bootloader.

Special note: the lines tagged with e.g. [1634809205.873] are part of the logging from the application itself. Things tagged e.g. <debug> are Nordic code logs... you can ignore most of the lines from the application I think.

Note that the whitelist is still populated coming back so I have problems thinking that the bonding information is gone too...

Line 245: This is in response to PM_EVT_CONN_SEC_CONFIG_REQ on a pm event

I'll be able to focus back on this next week and get your code implanted and a log back to you on it.

RE: Android asking for pairing after DFU

Edvin — Thu, 16 Jun 2022 12:31:10 GMT

So in this log (baby_logs.txt), is this from after the DFU, or is it the first time you turn it on (before ever bonding with the phone)?

If that is the case, then it doesn't have any devices in the whitelist, and I would assume that it doesn't have any devices in the peer manager either, since the whitelist typically uses the peer manager to load the addresses for the whitelist.

If that is not the case, then can you please describe to me what I am looking at in the baby_logs.txt log?

RE: Android asking for pairing after DFU

Randy Lee — Tue, 14 Jun 2022 12:45:33 GMT

One of my other engineers managed to grab the following logs (before I had time to get your suggested code in them) which might shed some light on things. On the Baby Logs, you can ignore the RFID: lines as those are the application itself and have nothing to do with BLE..

devzone.nordicsemi.com/.../baby-logs.txt devzone.nordicsemi.com/.../Android-logs.txt

RE: Android asking for pairing after DFU

Edvin — Mon, 13 Jun 2022 08:47:44 GMT

Hello,

[quote user="Edvin Holmseth"]And also, what does the log from your application say? Please copy paste the log from before you DFU, i.e. when you don't have to pair again and when you do have to pair again. Do they look the same?[/quote]

I was actually thinking of the log from the nRF chip, if you have any.

I see from the log 6.txt that it receives a pairing request. The address of the nRF chip is the same before and after the DFU (I 13:14:35.703 Connected to DF:A0:E4:ED:42:5C), so that should not be the issue. Perhaps the the nRF doesn't have the bonding data after the DFU process.

Please check that delete_bonds() is not called after the DFU. Try setting a breakpoint or add some logging in the delete_bonds() function to see whether this is triggered.

Also, you can add this before you start advertising:

static void check_bonds(void)
{
    ret_code_t err_code;
    uint32_t peer_count;
    pm_peer_id_t peer_id = PM_PEER_ID_INVALID;
    pm_peer_data_bonding_t peer_data;
    
    peer_count = pm_peer_count();
    NRF_LOG_INFO("peer_count: %d", peer_count);
    
    peer_id = pm_next_peer_id_get(PM_PEER_ID_INVALID);
    if (peer_id != PM_PEER_ID_INVALID)
    {
        while (peer_id != PM_PEER_ID_INVALID)
        {
            NRF_LOG_INFO("peer id %d is valid", peer_id);
            err_code = pm_peer_data_bonding_load(peer_id, &peer_data);
            APP_ERROR_CHECK(err_code);
            NRF_LOG_INFO("peer address: %02x:%02x:%02x:%02x:%02x:%02x", peer_data.peer_ble_id.id_addr_info.addr[5],
                                                                        peer_data.peer_ble_id.id_addr_info.addr[4],
                                                                        peer_data.peer_ble_id.id_addr_info.addr[3],
                                                                        peer_data.peer_ble_id.id_addr_info.addr[2],
                                                                        peer_data.peer_ble_id.id_addr_info.addr[1],
                                                                        peer_data.peer_ble_id.id_addr_info.addr[0]);
            
            peer_id = pm_next_peer_id_get(peer_id);
        }
    }
    else 
    {
        NRF_LOG_INFO("no valid peers");
    }
}

It will print the address of all the peers that are bonded with the nRF. Add it right before you start advertising.

BR,
Edvin

RE: Android asking for pairing after DFU

Randy Lee — Thu, 09 Jun 2022 19:48:10 GMT

[quote userid="26071" url="~/f/nordic-q-a/88457/android-asking-for-pairing-after-dfu/370792#370792"]And also, what does the log from your application say?[/quote]

Attached is the log from nRFconnect on Android. This has a complicated connection scheme so I have not attempted this on iOS to see if there is a difference in it.

Once the device is paired and bonded through our application, close the application and then connect back up with nRFconnect (this bypasses all the oddities of our application
Then put the device into DFU mode via struct command 0x0000000007 in nRF Connect (line 53). This causes the device to change to bootloader mode. In this mode, we aren't using the whitelists and such...
run DFU
Allow reconnect of nRFconnect when done (line 985- ~994)
Android asks pairing again (starting at line 995 or so)...

I'll be looking at the embedded side to answer some questions a bit later (this is going to take awhile to do here so you'll have to bear with me please)

Thank you for your help so far in this.

devzone.nordicsemi.com/.../Log-6.txt

RE: Android asking for pairing after DFU

Edvin — Fri, 03 Jun 2022 06:24:34 GMT

Ok. Then you need to start investigating the other things that I have mentioned:

[quote user="Edvin Holmseth"]Do you see whether the peripheral device has changed anything? Or did you try to debug the applciation? Is the bonding data still present on the peripheral? Does the peripheral use the same Bluetooth LE address as before the DFU update took place?[/quote]

[quote user="Edvin Holmseth"]You can also make your application to tell you how many peers that are stored in the beginning of your application, to verify that it is in fact the nRF that has lost the bonding data. What does it say?[/quote]

And also, what does the log from your application say? Please copy paste the log from before you DFU, i.e. when you don't have to pair again and when you do have to pair again. Do they look the same?

Does this only happen on Android? Did you try with iOS?

BR,

Edvin