When do you get the "peer removed pairing information" error?

[applesan]

I got this error during development.

I think it is caused by the BLE device erasing the connection information with iOS,

I don't know under what circumstances the BLE device will erase the connection information.

If you know the patterns that occur frequently, please let me know.

For example, when updating iOS

I would like to know the situation that has occurred so far.

[Karl Ylvisaker]

Hello,

If one side of the BLE link deletes the stored bonding information (Long Term Key, LTK) then there is no way to recover the bond, and so you must delete the stored bonding information on the other side as well, and re-do the bonding.

I do not know of any particular pattern for iOS to be deleting stored bonding information, but it could perhaps happen when an OS upgrade takes place as you mention. Which sides of the link is outputting the error message?
It would be helpful if you could describe the method you are using to provoke this behavior in greater detail, if possible.

Best regards,
Karl

[applesan]

Hello,

The error message was acquired on iOS (swift), and "peer removed pairing information" was output as the disconnect error message.

I am logging the error as a function of the app, but since this error was recorded at that time, I do not know exactly when the error occurred. I found an article that could occur when updating iOS, but I don't know any other cases that may occur, so please let me know if you know.

Best regards,

Kuma

[Karl Ylvisaker]

Hello again, Kuma

applesan said:

The error message was acquired on iOS (swift), and "peer removed pairing information" was output as the disconnect error message.

Thank you for clarifying.

applesan said:

I am logging the error as a function of the app, but since this error was recorded at that time, I do not know exactly when the error occurred. I found an article that could occur when updating iOS, but I don't know any other cases that may occur, so please let me know if you know.

I see that iOS developers in other forums have mentioned that they would get this error message if the BLE connection is initiated by the phone's Bluetooth settings (the OS native app) instead of the application itself. Could this be the issue in your case?
I also do not see any reason why it should happen when you update your OS, unless the process of updating the OS removes all user data from the phone. Which OS did you upgrade from, and to, when this happened?

Best regards,
Karl

[applesan]

Karl Ylvisaker said:

Could this be the issue in your case?

Probably not. Because there was no error when pairing with "connect" from iphone. However, although it can occur in certain situations, we do not know the specific situation.

Karl Ylvisaker said:

Which OS did you upgrade from, and to, when this happened?

This was in the user's log, so I'm not sure if the os was actually updated. I also don't know the updated version. We want to know in what cases this error has occurred in the past.

Also, if there is a development bug on iOS (swift), it needs to be fixed. If it's a BLE device issue, you need to tell the user about it.

Best regards,

Kuma

[Karl Ylvisaker]

Hello again, Kuma

applesan said:

This was in the user's log, so I'm not sure if the os was actually updated. I also don't know the updated version. We want to know in what cases this error has occurred in the past.

It is hard to conclude on this without knowing exactly how the behavior was provoked.
From what I have seen in the forums earlier, this disconnection reason is most prominent when the device has been paired with the native OS BLE application rather than the custom application, as far as I can tell.

applesan said:

Also, if there is a development bug on iOS (swift), it needs to be fixed. If it's a BLE device issue, you need to tell the user about it.

I am not sure what you are suggesting might be the BLE issue here - the BLE device will use the same key until a request to update it is provided (LTK case) or until the connection is terminated.
If one of the devices deletes their pairing/bonding information then the other one needs to do so as well, and a new pairing must take place for the communication to resume, as mentioned earlier. This information will not be deleted or changed on the nRF side unless you do so intentionally in your application, so I suspect that something has gone wrong on the central side of the link.
If this is not a persisting issue then I suggest that you delete the bond information on both sides ('forget device') and re-do the pairing/bonding procedure.

A sniffer trace of the scenario would be of great help if we are to debug this more closely.

Best regards,
Karl

[applesan]

Hello,

Karl Ylvisaker said:

this disconnection reason is most prominent when the device has been paired with the native OS BLE application rather than the custom application, as far as I can tell.

thank you. I will check it.

Karl Ylvisaker said:

A sniffer trace of the scenario would be of great help if we are to debug this more closely.

thank you. Let's check using this.

Best regards,

Kuma

[Karl Ylvisaker]

applesan said:

thank you. I will check it.

Good, I look forward to hearing what you find.
To elaborate a little further I suspect that the issue here could be that the OS native app is keeping the key and not sharing it with the custom application.
From the peripheral's standpoint the device will be known, so it will use the stored information, while the custom app will not be able to decrypt the incomming packages without the key (which is stored in the OS native app, and not provided to the custom app), prompting the 'peer removed pairing information' error, or something along these lines.
If this is the case, I would expect it to be solved by initiating the pairing/bonding from the custom app, rather than the OS native app.

applesan said:

thank you. Let's check using this.

Great, please do not hesitate to let me know if you encounter any issues or questions while using the sniffer tool to capture the trace.

Best regards,
Karl