The parameter structs for advertising and scanning contain many
members that may not get explicitly set when enabling these states. Do
a memset to zero on them to make sure we don't operate on
uninitialized memory.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
A value of 20ms means it's possible the LPN will end up doing
simultaneous advertising & scanning, which increases the risk of lost
packets. Use a default of 100ms to keep these separate.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Handling Friend Clear messages and sending the Friend Clear
Confirmation responses wasn't so far properly implemented. One of the
requirements is to keep sending the reponses even though we no-longer
have a friendship. This means that we need to keep the net_idx, frnd
and lpn_counter values valid, which in turn requires the introduction
of a separate "valid" boolean value.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The PTS tests for the Friend node expect a minimum of 16 queued
messages and the ability to have two LPNs. Set these as defaults.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When sending PDUs from Friend to LPN we should adhere to the
configured network transmit count & interval to get better
reliability for the PDUs to be received by the LPN.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When a Friend Node receives a Friend Request with a unicast
PreviousAddress that's not an element on the Friend Node, it needs to
start the Friend Clear procedure. This procedure involves sending
periodic Friend Clear messages to the old Friend of the LPN.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The only messages that should be encrypted using the friendship
credentials are those coming through the Friend Queue on the Friend
node, most request-response pairs between LPN & Friend (exceptions are
Friend Request - Friend Offer, and Friend Clear - Friend Clear
Confirm), as well as Model Publication messages when the Friendship
Credentials Flag has been enabled in the model publication.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When the node is in LPN node, the LPN-Friend messages has its own
retries, so doing this on the advertising level (i.e. following the
network transmit state) is sub-optimal.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This makes it possible (in a subsequent patch) to fine-tune some
special cases, like the LPN poll messages.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Update the advertising callback to include the exact duration that we
will be sending out the packet. This is useful since sometimes we want
to use the end point of the advertising as the reference time to count
when some other action should take place.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Lower the attempts and make sure we track the old Friend address for
subsequent Friend Requests, in case we never receive a Clear
Confirmation.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add some automated policies for starting LPN establishment and make it
possible to perform the establishment in a "low power" way, i.e.
switching to low duty-cycle already when starting to send Friend
Requests.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
According to the Mesh Spec value 0x00 of ReceiveWindow parameter is
prohibited. This is needed to pass MESH/NODE/FRND/LPN/BI-03-C.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The intention of the code was to access client->conn and not
clients->conn (which would always access the first client struct).
Fixes#4738
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The function return type was declared incorrectly. Also, the magic
checking for i after exiting the loop could cause some false positive
compiler warnings. Instead, return directly from the loop (with the
downside of duplicating a few lines of code).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
It's in practice impossible for the time between two beacons to be
more than 50 hours (the approximate wrap-around time for a 32-bit
millisecond timer), so we can use a 32-bit timestamp instead of a
64-bit one for the beacon tracking.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The LE scanning and advertising implementations were allocating and
holding buffers (the scan & advertising parameters respectively) while
at the same time potentially sending other commands (such as setting
the local private address). If these APIs would end up being called
simultaneously from different contexts, this could lead to a deadlock
in trying to allocate HCI command buffers, especially considering that
the default HCI command buffer count is 2.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Introducing CMake is an important step in a larger effort to make
Zephyr easy to use for application developers working on different
platforms with different development environment needs.
Simplified, this change retains Kconfig as-is, and replaces all
Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild
offers is replaced by a set of CMake extentions. These extentions have
either provided simple one-to-one translations of KBuild features or
introduced new concepts that replace KBuild concepts.
This is a breaking change for existing test infrastructure and build
scripts that are maintained out-of-tree. But for FW itself, no porting
should be necessary.
For users that just want to continue their work with minimal
disruption the following should suffice:
Install CMake 3.8.2+
Port any out-of-tree Makefiles to CMake.
Learn the absolute minimum about the new command line interface:
$ cd samples/hello_world
$ mkdir build && cd build
$ cmake -DBOARD=nrf52_pca10040 ..
$ cd build
$ make
PR: zephyrproject-rtos#4692
docs: http://docs.zephyrproject.org/getting_started/getting_started.html
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
If we are a Friend node with multiple LPNs, we need to iterate through
all available Friendship credentials to find the right keys.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Mesh spec expects us to fall back to master credentials if
friendship ones are not available. Also remove an unnecessary branch
with the help of a new 'idx' variable.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The friend_cred and new_key information is common for all segments of
a segmented transaction, so it makes sense to store them as part of
struct seg_tx instead of each buffer's user data.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The friend_cred hint needs to be set already at the point of
segmenting, i.e. doing it in bt_mesh_net_send() is too late. Move the
setting to bt_mesh_trans_send() and bt_mesh_ctl_send().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
MESH/NODE/FRND/LPN/BI-02-C requires us to ignore unknown Transport
OpCodes instead of treating them as valid responses to a Friend Poll.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Mesh Specification recommends retrying up to 6 times the Friend
Poll when establishing Friendship as LPN.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
We should not have any valid key material in key slot 0 if the KR flag
is set, since then the new key/old key information will be incorrect
when network PDUs get decrypted.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
According to the Mesh Profile Specification: "The acknowledgment timer
shall be set to a minimum of 150 + 50 * TTL milliseconds".
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Mesh Profile Specification states that replay protection must be
done for all control and access messages. Furthermore, the replay
protection list must be updated with the sequence from the last
segment of a segmented message (the code was only updating based on
SeqZero).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Now that Friend support is complete we can create a full
implementation of the LPN PollTimeout Get message.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Even with the privacy feature disabled, the stack has so far defaulted
to using an NRPA for active scanning, in order to protect privacy.
This is mainly because it is not always clear that scanning for other
devices may risk revealing the local identity.
There may however be use cases where such revealing is actively
desired, so introduce a new option for this (which defaults to
disabled).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add support for loading IRKs into the controller as well as the LE
Enhanced Connection Complete HCI event. To simplify things, the old LE
Connection Complete handler translates its event into the new enhanced
one which is then the single place of processing new connection
events.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
MESH/NODE/CFG/HBS/BV-02-C expects it to be possible to do a Set with
the existing src & dst addresses but with a zero period in order to
"cancel" the current subscription. In such a case the addresses should
remain set but the period be set to zero, similar to what would happen
if the period would expire.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The heartbeat subscription Count, MinHops & MaxHops should only be
reset when enabling heartbeat subscription. Any other actions should
keep it unchanged.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The heartbeat should only be sent in case the relay state actually
changes. This fixes MESH/NODE/CFG/HBP/BV-03-C.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
"4.1.2 Log field transformation
In order to compress two-octet values into one-octet fields, the
following logarithmic transformation is used: any two-octet value is
mapped onto a one-octet field value representing the largest integer
n, where 2^(n-1) is less than or equal to the two-octet value."
Log field transformation table:
Log Field Value 2-octet Value
0x01 0x0001
0x02 0x0002 through 0x0003
0x03 0x0004 through 0x0007
0x04 0x0008 through 0x000F
0x05 0x0010 through 0x001F
0x06 0x0020 through 0x003F
0x07 0x0040 through 0x007F
0x08 0x0080 through 0x00FF
0x09 0x0100 through 0x01FF
0x0A 0x0200 through 0x03FF
0x0B 0x0400 through 0x07FF
0x0C 0x0800 through 0x0FFF
0x0D 0x1000 through 0x1FFF
0x0E 0x2000 through 0x3FFF
0x0F 0x4000 through 0x7FFF
0x10 0x8000 through 0xFFFF
"4.2.17.2 Heartbeat Publication Count Log
The Heartbeat Publication Count Log value between 0x01 and 0x11 shall
represent that smallest integer n where 2^(n-1) is greater than or
equal to the Heartbeat Publication Count value. For example, if the
Heartbeat Publication Count value is 0x0579, then the Heartbeat
Publication Count Log value would be 0x0C."
According to this definition 2^(n-1) is an upper bound for n log
value.
Proposed Publication Count Log transformation table:
Pub Count Log Value 2-octet Value
0x01 0x0001
0x02 0x0002
0x03 0x0003 through 0x0004
0x04 0x0005 through 0x0008
0x05 0x0009 through 0x0010
0x06 0x0011 through 0x0020
0x07 0x0021 through 0x0040
0x08 0x0041 through 0x0080
0x09 0x0081 through 0x0100
0x0A 0x0101 through 0x0200
0x0B 0x0201 through 0x0400
0x0C 0x0401 through 0x0800
0x0D 0x0801 through 0x1000
0x0E 0x1001 through 0x2000
0x0F 0x2001 through 0x4000
0x10 0x4001 through 0x8000
0x11 0x8001 through 0x10000
According to Log field transformation table 0x0579 would be
transformed to 0x0B and should be to transformed to 0x0C.
This is required to pass MESH/NODE/CFG/HBP/BV-01-C.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Section 4.2.18.2 in the Mesh Profile Specification states:
"The Heartbeat Subscription Destination shall be the unassigned address,
the primary unicast address of the node, or a group address, all other
values are Prohibited."
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch fixes issue when receiving iv index greater than current
index + 42 in update mode. According to Specification when node is in
update state it should only accept iv index equal to the current iv
index. When node is in normal mode it should ignore index that is
greater than current index + 42.
This allows to pass MESH/NODE/IVU/BI-02-C.
Also this patch cleans up the iv update procedure, to make it easier
to read.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
