Bluetooth Server Pairing crash

[axa88]

Library/API/IoT binding

nanoFramework.Device.Bluetooth

Visual Studio version

18.4.3

.NET nanoFramework extension version

2022.14.1.5

Target name(s)

ESP32_PSRAM_BLE_GenericGraphic_REV3

Firmware version

1.15.0.361

Device capabilities

No response

Description

There seems to be malfunction in device pairing.
In summary when configured with a BLE server, when 2 consecutive pairing attempts are canceled by a initiating client, the server crashes.

Minimal Repo here if need be, but the configuration doesn't seem to matter.
In this example the ble server is configured with Pairing.IOCapabilities = DevicePairingIOCapabilities.NoInputNoOutput; and Pairing.ProtectionLevel = DevicePairingProtectionLevel.None for simplicity but the malfunction seems to happen regardless of config.

How to reproduce

1. Load example
2. Initiate Bluetooth pair from any cancelable client (android works well)
3. cancel
4. repeat step 2/3
5. observe server crash.

Expected behaviour

It would be expected that a pairing initiator can be canceled

Screenshots

No information can be gathered while debugging.

Sample project or code

https://github.com/axa88/NfIssueTracker/tree/master/RePairingCrash

Aditional information

On a related note, while this should be more transparent, it appears in NF both LE Secure Connections and Man In the Middle flags are hard coded as enabled. Therefore, with the example configuration, it's expected any paring request negotiation gets 'downgraded' to DevicePairingKinds.ConfirmOnly

So, while i've not seen another implementation of NimBLE do it, i might expect the server would trigger Pairing.PairingRequested in this scenario if possible, so that programming could be informed of a pair request even if user interaction isn't expected, so that programmatic rejection can be made if conditions call for it.

It should be irrelevant here but fwiw I've initiated pairing from both Android, and custom pairing from windows SDK where various PairingKinds could be configured, and they both will induce the crash. I expect they all negotiated as ConfirmOnly but as there is PairingRequested trigger i can't confirm.

[alberk8]

@axa88 , Comment out the _primaryProvider?.StartAdvertising();. After BLE session is disconnected and if you do not stop the advertisement manually, internally nF does the auto start advertisement. So starting the advertisement is not necessary but the system panic is another thing that needs fixing if StartAdvertising is called twice.

[axa88]

@axa88 , Comment out the _primaryProvider?.StartAdvertising();.

Yes, that that silences the crash thanks

After BLE session is disconnected and if you do not stop the advertisement manually, internally nF does the auto start advertisement.

Then this makes the process of disabling advertising more complex if possible, at all.

ie for example your device has a button with the intention to make your device discoverable/connectable for a limited time... if then there is a connection or pair attempt, you don't get the opportunity to make sure advertising doesn't restart automatically. Or at the least, require the need to insert logic to do it after disconnect or even failure, seems brittle. Especially as you don't really know when it restarts where you might attempt to stop before it automatically restarts. (which Ive tested, which fails and an arbitrary delay is needed)

And this all necessary to enable LE Limited Discoverable Mode rather than LE General Discoverable Mode.

9.2.3.1. Description
Devices configured in the limited discoverable mode are discoverable for a limited period of time by other devices performing the limited or general device discovery procedure. Devices typically enter the limited discoverable mode when a user performs a specific action.

There are two common reasons to use limited discoverable mode:

Limited discoverable mode can be used to allow remote devices using the general discovery procedure to prioritize or otherwise identify devices in limited discoverable mode when presenting discovered devices to the end user because, typically, the user is interacting with them.

Limited discoverable mode can also be used to allow remote devices using the limited discovery procedure to filter out devices using the general discoverable mode.

A more robust implementation would allow starting advertisements explicitly, with a call back when they actually start and stop.
In a perfect world this would be decoupled completely and multiple advertisements allowed to be instantiated allowing various payloads.

So starting the advertisement is not necessary but the system panic is another thing that needs fixing if StartAdvertising is called twice.

Ya ill leave the bug here for some exposure to the issue.

[alberk8]

Well you can declare the StopAdvertising in your BluetoothManager as static. You will be able to be accessed from any where. If you want it to have limited time for Advertising then you can add a Thread when you StartAdvertising() and stop the advertisement. BTW, internally the advertisement will start immediately after the connection is disconnected (there is also some latency in the native side to start the advertisement). Of cause the native to manage marshalling of statuses and data also introduces latency so there would be a lag in the update of the status.

public void StartAdvertising()
	{
		_advertisingParams = new()
		{
			IsConnectable = true,
			IsDiscoverable = true,
			CustomAdvertisement = true,
			Advertisement =
			{
				Flags = BluetoothLEAdvertisementFlags.ClassicNotSupported | BluetoothLEAdvertisementFlags.GeneralDiscoverableMode,
				LocalName = "nfAdv"
			},
			ServiceData = new([1, 2, 3, 4])
		};

		_primaryProvider?.StartAdvertising(_advertisingParams);
                _ = new Thread(RunOneMin).Start();
		Debug.WriteLine($"{nameof(_primaryProvider.AdvertisementStatus)}:{_primaryProvider?.AdvertisementStatus.ToName()}");
	}

private void RunOneMin()
{
       // This sample does not check for if there is a connection is active
       Thread.Sleep(60_000);
       _primaryProvider.StopAdvertising()

}

[axa88]

@alberk8

ok thanks for the idea. Ya ill need to figure out how to work around this to support the limited advertising spec. Though, consider if during that sleep, a device connects, you need to cancel or at least deal with what happens on thread expiration. As well as mark and maintain a flag stating you want to stop advertising after disconnection automatically restarts it. Now its stateful and brittle, that's what i was trying to get at.
It's not that I don't think the issue can't possibly be mitigated, it's just needs to be considered then developed, which i think is better done in the library.