No DHKey exchange when communicating with device in ncs 2.8.0

[GalBrandwine]

Hey,

We have a library (rust) responcible for communicating with the BLE peripheral Using btmgmt dbus messages to bluez.

We have never initiated a dedicated `aagent` in our gateway.

When communicating with BLE device running ncs 270 - we pass pairing phase, and everything works.

But when communicating with device running ncs 280 - the pairing failed, and communication dropped ungracefully.

In the picture, we see the SMP pairing phase

Left - client communicating with BLE running ncs270 (we can see DHKey exchange)

right - client communicating with BLE running ncs280 (No DHKey exchange, why?)

To make things work I need to manually select a `agent DisplayYesNo`.
1. What was changed between 280 and 270?
2. Why there's no DHKey exchange with v280 when using default-agent?
3. How can I make it work without triggering dedicated agent?

Thanks

[GalBrandwine]

After playing with it more, I have some more information about what is going on
Im failing to pair the device (running ncs280:

I've turned on many DEBUG logs to tyr and understand what is going on on the device:
```
CONFIG_BT_KEYS_LOG_LEVEL_DBG=y
CONFIG_BT_CRYPTO_LOG_LEVEL_DBG=y
CONFIG_BT_SETTINGS_LOG_LEVEL_DBG=y
CONFIG_BT_SMP_LOG_LEVEL_DBG=y
CONFIG_BT_SECURITY_ERR_TO_STR=y
CONFIG_BT_SMP_ERR_TO_STR=y
```

when trying to pair, heres the logs from the BLE device:
```
D: F4:26:79:20:76:A9 (public)
D: Encoded path bt/sc/f426792076a90
I: halo_char_ccc_cfg_write: value=1
I: ****************** TRAP:retry_counter = 0
I: send_trap: trap was sent, payload_size = 24
D: F4:26:79:20:76:A9 (public)
D: Received SMP code 0x01 len 6
D: req: io_capability 0x03, oob_flag 0x00, auth_req 0x29, max_key_size 0x10, init_key_dist 0x0D, resp_key_dist 0x0F
D: F4:26:79:20:76:A9 (public)
D: prnd 5730925b34c1387349d104f1de30d6e5
D: rsp: io_capability 0x03, oob_flag 0x00, auth_req 0x09, max_key_size 0x10, init_key_dist 0x00, resp_key_dist 0x00
D: Received SMP code 0x0c len 64
D:
D: u bc00ca97f3772734a904d3c4c4cf83d1d3c3d11cb548e9498af346484cec4480
D: v 15ffd52949209f9a27f9316c7a6eff235717b5c19bd4aa3ce48c18f522252555
D: x 5730925b34c1387349d104f1de30d6e5 z 0x0
D: res d1573ffdf6d5a1293b3ab3bd5851344e
D: 0x2000e5ad
D: Received SMP code 0x04 len 16
D:
D: Received SMP code 0x05 len 1
E: pairing failed (peer reason 0xc)
D: got status 0xc
D: chan 0x200032dc conn 0x20003078 handle 41 encrypt 0x00 hci status 0x05
E: le_security_changed err = 1
W: Pairing failed conn: F4:26:79:20:76:A9 (public), reason 1

D: chan 0x200032dc cid 0x0006
D: F4:26:79:20:76:A9 (public)
D: F4:26:79:20:76:A9 (public)
D: F4:26:79:20:76:A9 (public)
D: F4:26:79:20:76:A9 (public)
I: con_event log: naks 70, crc ok 0, crc err 0,timeouts 1, events 66, Rssi 0
I: Disconnected (reason 0x16), connection duration: 2972
```

From looking at wiresharks loggings, I asked for a `No Input, No Output` binding.
```Bluetooth Security Manager Protocol
Opcode: Pairing Request (0x01)
IO Capability: No Input, No Output (0x03)
OOB Data Flags: OOB Auth. Data Not Present (0x00)
AuthReq: 0x29, Secure Connection Flag, Bonding Flags: Bonding
001. .... = Reserved: 0x1
...0 .... = Keypress Flag: False
.... 1... = Secure Connection Flag: True
.... .0.. = MITM Flag: False
.... ..01 = Bonding Flags: Bonding (0x1)
Max Encryption Key Size: 16
Initiator Key Distribution: 0x0d, Link Key, Signature Key (CSRK), Encryption Key (LTK)
Responder Key Distribution: 0x0f, Link Key, Signature Key (CSRK), Id Key (IRK), Encryption Key (LTK)
```

According to [Nordics tutorials](academy.nordicsemi.com/.../) it suppose to initiate **JUST WORKS** pairing.
But According int wireshark logs I see:
```
Bluetooth Security Manager Protocol
Opcode: Pairing Failed (0x05)
Reason: Numeric Comparison Failed (0x0c)
```

MY question is:
why does the device expect `Numerical comparison` pairing?

[tesc]

Hi,

"Numerical comparison" should only happen if both devices have either DisplayYesNo or KeyboardDisplay. If either device has NoInputNoOutput, then, as you write, you should get "Just Works". For "just works" there should be no numeric comparison, and therefore no failure due to numeric comparison failing. From the logs it looks like both devices are NoInputNoOutput, and so you should get "Just Works".

In order to reach higher security levels, just works might not be enough. However if that was the cause of the disconnect, then I would expect the error not to be pairing failed, but rather from a security procedure for increasing the security level. However there is still the possibility that the issue that you are seeing comes from some setting, in either end, requiring higher security level than what can be accommodated by just works.

What is running on the peer device, is it a custom sample or an SDK sample (and if so which one)? The changes leading to the failed connection attempt may be in that sample. I have not been able to identify general changes to the SDK or to the SoftDevice controller, which would explain the issue.

Regards,
Terje