This fixes unexpected MIC failure when retransmission happens during
encryption start procedure as follows:
- peripheral sends LL_START_ENC_REQ unencrypted, central acks
- central sends LL_START_ENC_RSP encrypted, peripheral acks
- central retransmits LL_START_ENC_RSP for whatever reason
The problem is that peripheral increments rx packet counter after 1st
LL_START_ENC_RSP is received, so retransmission is decrypted with
different rx packet counter and thus is not valid. We properly ignore
MIC failure for retransmission, but then code checks if received PDU is
valid in currect state, i.e. encryption start procedure. Since it was
not properly decrypted, the PDU type is likely garbage and thus
considered as not allowed so we terminate connection with MIC failure.
The "ultimate" fix for such issues is to simply ignore any retransmitted
PDU with MIC failure since basically contents of such PDUs are garbage
and not really useful for any checks.
We should not allow to free aux_data from pkt_in if there was
AUX_SCAN_REQ sent for that pdu as this will result in use-after-free of
aux_data when AUX_SCAN_RSP is received.
This can happen if we send AUX_SCAN_REQ from isr and then in pkt_in
figure out this is a duplicate so we don't want to scan this chain
anymore. We should just wait for AUX_SCAN_RSP and stop there.
We should update backoff after receiving scan response PDU instead of
waiting for complete chain to be received.
This also fixes problem where we try to update backoff in an invalid
state, i.e. backoff_count is non-zero. It happens if we start to scan
response chain with backoff_count=0 and before complete chain is scanned
we scan another pdu which fails. This updates backoff_count to non-zero
value so when we finish scanning chain and try to update backoff, the
backoff_count value is non-zero which is considered an invalid state.
[Core 5.3, Vol 6, Part B, 4.4.3.2]
We should always send assert vs event if enabled, regardless if we'll
break due to attached debugger or not. This is useful when using monitor
over RTT since using RTT means debugger is attached even though we may
not actually have sw debugger running.
If CRC does not match on AUX_CONNECT_RSP, we should cancel already
scheduled connection as otherwise there will be spurious connection
timeout as scheduler will run uninitialized connection.
This is follow up on 8447ec2969. We allow peer RPA to be used in the
same way as identity address if we do not have peer IRK, so we also need
to update checks for AUX_CONNECT_RSP.
Since chain pdus are scheduled from LL while previous aux/chain pdu is
already in scheduler, it's possible that previous pdu will be already
processed before LL can schedule chain. In such case previous pdu will
be sent with AuxPtr offset=0 and we should simply drop subseqent pdus.
This adds proper support for FEM turn on time. Max supported turn on
time is 90us due to some optimizations in code, but that should be
enough - we can change it later if needed.
This moves most of code specific to nRF52 series to separate file and
creates private phy APIs to call that code.
The moved code is anything related to PPI: FEM, GPIO debug and PPI
itself.
This is starting point for common phy for nRF52 and nRF53 which will
make maintaining both much easier. For now this is just c&p of nrf52
phy to make changes easier to follow.
Note that nrf5x phy will not support nRF51 since, apart from other
differences, it does not support hardware tifs which is required for
nRF51.
We schedule consecutive PDUs in advertising event at "now" timestamp,
but to make sure we do not miss the slow we should account for an extra
tick that can happen during processing.
This enables APIs to support variable T_ifs in PHY. By default 150us is
used but this value can be changed before each transition. After
transition value is reset to default so LL does not need to care about
setting T_ifs everywhere.
This may be useful for scheduling of related events with tight timings.
Disabled by default since it allows for compile-time optimizations.
Andrzej Kaczmarek