So far we assert when being late or starting RX timer. Now we allow to
be late as it is not important for dtm code. RX is still on after it.
X-Original-Commit: dc600a051f11e3c9f31e93fdd45e63c659c3c8c4
If we are late when scheduling RX, receiver is enabled anyway since we
may just want to scan for "anything". However, current code only enables
receiver but does not configure it so the results seem unpredictable.
This patch fixes this by ensuring that radio is properly configured for
RX in both cases.
X-Original-Commit: 068c09a8da97bc62eddd5084fa1e40f910abf7e8
As per TSE 10009 the TS will enforce that a Friend ever only uses a
single transmission when sending packets to an LPN. Make sure that our
implementation follows this.
https://www.bluetooth.org/tse/errata_view.cfm?errata_id=10009
X-Original-Commit: 564a956d1a3b291234dc1351f422830b781689f1
This fixes the issue when after incomplete timer expiration
host sent ACK.
The host failed in two cases:
1. Sending ACK right after the incomplete timer expiration;
2. Sending ACK from new RX context. Now, seq_auth of cancelled
message is not cleaned on RX reset, so segments of cancelled message
will be discarded when resend.
According to the Mesh Profile v1.0
"When the incomplete timer expires, the lower transport layer
shall consider that the message being received has failed and
cancel the acknowledgment timer. Any segment of a canceled
message shall be ignored."
X-Original-Commit: 50e7d632932c4188849aee89e0d23e2207352601
In the case of an unexpected PDU we need to send the right response.
This was already taken care of for PB-ADV, but not for PB-GATT.
X-Original-Commit: 65b2467d6192e9bd943a3f898132775984d6b871
The Provisioner might have missed our earlier Link Acknowledgement, so
if we receive another one with matching Link ID and link.expect state,
simply send another acknowledgement.
X-Original-Commit: b6d823cb5131e8750d7ec1152b4d48ea60ac85c3
When sending a segmented message, the state could get stuck if the
advertising bearer fails in transmitting and we don't detect that it
happened. Add a send_start callback for all packets so we can always
know if sending fails.
X-Original-Commit: c2f6fa5baf8eab609a705347e1c1b881e48bd710
New advertising started while scanning is already enabled
would delay the first advertisement event until the end of
the current overlapping scan window in the Zephyr native BLE
controller implementation. Hence, consider this scan window
duration when calculating the advertising stop.
X-Original-Commit: 9b8e353c059d260134310e0255bce8b40b00d394
Until now the OOB info and URI fields in unprovisioned beacons were
generally ignored by the implementation. Add fields for these to
bt_mesh_prov and make sure to take them into account when encoding
advertising data, both for PB-ADV and PB-GATT. For PB-ADV the URI goes
out in a separate beacon, whereas for PB-GATT it is placed in the scan
response data.
X-Original-Commit: e6b7f42e2688c2d4102dea83bf962d2fbc74ac5e
The calculations for sending this HCI event periodically are a bit
mysterious at first glance - let's make them more obvious.
X-Original-Commit: 29d5d03fc888c414fb21ac22d6df4b970847f92f
As it turns out, spec allows appearance characteristic to be writable
so let us allow configure it this way. Also we need API to set this
from app so it can read new appearance value, store it and then restore
after reboot.
X-Original-Commit: b1b1c785b6f7968588aec68cad897711539552d5
GAP service takes care of updating characteristic value. Application
can register callback to be notified of value change and can then read
this value and store somewhere (and restore on next boot).
X-Original-Commit: 46e768f451bc4c7a0222348fee384b4d1c87aff1
Allow to configure value of "Peripherap Preferred Connection Parameters"
characteristic. Since this characteristic is optional and right now we
do not set any meaningful value there, we simply disable it by default.
X-Original-Commit: ce7276d7ea9e46e2912980d010b98ef5beadc6ee
"Peripheral Preferred Connection Parameters" is only optional in
peripheral role and excluded otherwise - so make it register only
if we're configured for peripheral role.
X-Original-Commit: 3b1e9855a8dcf0450a21f1bc18102601701d3f60
This characteristics is mandatory for LE Central role if LL Privacy is
supported.
We could be smarter in registering it by checking controller features,
but this is quite complex to implement due to the way everything is set
up so let's leave proper configuration for user :)
X-Original-Commit: 4934ddf4afc889c0aaa932734d5bf361eb4dc042
"Peripheal Privacy Flag" and "Reconnection Address" are not included in
GAP spec since 4.1, so let's remove them. And they were not properly
configured anyway...
X-Original-Commit: 3e2a7295ab2a6be2e46319677ba0d19f4d36224b
The vendor variants of the model publication client messages were not
passing onward the CID, rather passing CID_NVAL which is clearly not
right.
X-Original-Commit: 398fd57f82a407a343ff04e445aed6de9e990e8e
The code which calculates earliest connection event start does not take
BLE_LL_CONN_INIT_MIN_WIN_OFFSET into account, but we still update tx
windows offset in state machine with its value. As a result when this
setting is set to non-zero value we schedule first connection event
earlier than what slave calculates from CONNECT_IND PDU so connection
cannot be established.
X-Original-Commit: cf8ca1b0a6fab4e5d1c579fe37ee2adc4e3a1e07
CSC profile specific ATT error added.
Custom endianness handling functions replaced with system functions.
Device appearance moved to syscfg.
X-Original-Commit: 6cb978b99b2014a9589b1d59ea40e17a9e531dfd
os_cputime_get32() returns value from totally different range, than
os_time_get() and os_callout_reset() uses os_time_get(), so it should be
also used here. os_cputime_ticks_to_usecs() doesn't work well with
os_time_get(), so OS_TICKS_PER_SEC macro is used.
X-Original-Commit: 1eb0d588b403935a8451ff8d87a9b5c993282e3c