The helper method call_network_cb, actually does a lot more than calling
the callback. The method has a check that the network status supplied
for the callback is different compared to the internal one. It also sets
the class member if it is changed. This is a bit surprising, given the
name of the method. It also means that it doesn't work in this call, as
the member is already set.
Add override for the virtual method get_connection_status() inherited
from NetworkInterface. The method in the base class returns
NSAPI_STATUS_ERROR_UNSUPPORTED. The CellularContext has the member
_connection_status, which means that we could return this.
Previously, the CryptoToolbox was allocated once as part of the security manager.
This was inneficient memory wise as it is only use to prepare key at initialization
and when we need to compute shared keys.
This was also inneficient power consumption wise as the Crypto cell was kept enabled even
when it wasn't used.
This fix creates a CryptoToolbox whenever it is needed and release it once it has fulfilled its
purpose. Note that CryptoToolbox allocation happens on the heap as mbed tls data structure are huge
and there's an high risk of crushing the stack.
mbedtls performs selftest on all entropy sources.
Enable injected source without proper entropy injection causes mbedtls
selftest to fail.
Application code can still enable entropy injection by adding the macros
to mbed_app.json/mbed_lib.json
This reverts commit 8c03e3e60d46da71708c4a0e4dacf46a0179d18d.
the own_oob and peer_oob flags were not being set to 1 even though
an OOB pairing request was in progress, which therefore prevented
OOB data from being passed down to the softdevice during a OOB
pairing operation, thus causing the OOB pairing process to fail.
The function in the Nordic SDK for generating OOB data,
sd_ble_gap_lesc_oob_data_get, requires local LE Secure Connection
P256 Public Keys in {X,Y} format, but was being supplied with
the local secret key. This caused the generated OOB data to
fail to correspond to the Public Keys, which caused a mismatch
during the OOB pairing phase of the OOB confirmation value by
a remote peer when attempting to verify the OOB data against
the Public Keys, ultimately causing the OOB pairing request to
fail with a Confirm Value Failed (0x04) error.
The GenericSecurityManager tracks the most recent OOB data generated
by the PAL and the PAL function to generate OOB data is expected to
be asynchronous such that the OOB data is returned via a callback.
There was a race condition on the security manager's oob data variable
because it was cleared (set to all zeros) after calling PAL generate.
The expectation was that the clear operation would occur before the
callback executed, but this is proving to not be the case. Instead,
the callback is being executed as if it were syncronous with PAL
generate, then PAL generate returns and the oob data is cleared,
thereby losing the generated oob data that was set in the callback.
To fix the issue, clear the oob data variables before calling into
the PAL.
Alexander Zilberkant
Yossi Levy
Oscar Hellström
offirko
maclobdell
Oren Cohen
Vincent Coubard
Cruz Monrreal
Martin Kojtal
Fahim Alavi
Leszek Rusinowicz
Tymoteusz Bloch
Veijo Pesonen
Kevin Bracey
David Saada
Mahesh Mahadevan
kegilbert
Nic Costa
jeromecoutant