The needed options to QEMU_EXTRA_FLAGS now get set from a single
central place, so applications don't need to do it anymore.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The qemu option to access the host's Bluetooth controller is now
automatically added to QEMU_EXTRA_FLAGS whenever Bluetooth support is
enabled in the application. Update the documentation to reflect this.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
After the cmake conversion, the SimpleLink WiFi host
driver would not build, and compiler flags like -Wno-strict-aliasing
were not being applied as they got spliced in before
-Wall rather than after.
This fixes those issues, using the set_source_files_properties()
method as suggeted in the CMakeLists.txt TODO comment.
Signed-off-by: Gil Pitney <gil.pitney@linaro.org>
Update the sample README with the latest changes during the
1.10 development cycle. We removed the 2 concurrent IPv4
and IPv6 connections and now the sample will make a single
connection based on whatever is configured (currently IPv6
takes precedence over IPv4).
Added instructions for how to switch the sample to IPv4.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
Rather than continuing to add build system goals, let's just trust the
user to do the right thing. The only special case is build, which is
the default goal.
Signed-off-by: Marti Bolivar <marti@opensourcefoundries.com>
Use the default values for scan latency and receive delay, and enable
useful logging, like that for LPN.
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>
The default of the stack is now to automatically enable LPN
functionality after a given timeout.
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>
Even if endpoint addresses are configurable by each platform,
it would be better to make the default configuration compatible
with a larger board range.
e.g. STM32 OTG FS device has only four endpoints (0x84 is out).
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
https://github.com/zephyrproject-rtos/zephyr/issues/4864 revealed that
calling zephyr_sources() on a directory will silently omit the
directory. This is a clear user error and should be immediately
flagged as such.
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
If we were asked to add 10KB to a packet, adding it won't help -
such packet won't be even sent by hardware on our side, and if
it is, it will be dropped by receiving side. So, make sure we
never add more data than MTU as set for the owning interface.
This actually gets a bit tricky, because we need also to account
for protocol header space. Typically, when net_pkt_append() is
called, protocol headers aren't even added to packet yet (they
are added in net_context_send() currently), so we have little
choice than to assume the standard header length, without any
extensions.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Since run is also used commonly, add it as a goal as well for those
users of the extension that want to create a sequence similar to:
$ make
$ make run
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The new :compact: option allows for a single block of code output
without additional newlines or comments.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
New arguments added:
- conf: -DCONF_FILE=<>
- gen-args: Additional arguments to pass to CMake
- build-args: Additional arguments to pass to Make or Ninja
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
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 old way of constructing FLASH_SCRIPT_ENV_VARS was corrupting the
values that were passed to the flasher. This new method is the
standard way of creating a dictionary/hashmap in CMake and does not
suffer from the same problem.
This fixes
https://github.com/zephyrproject-rtos/zephyr/issues/4844#event-1334599401
Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
The QEMU_NET_STACK is enabled automatically if building
a networking application to QEMU so no need to do it for
each networking sample.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If compiling networking application for QEMU, then serial ports
must be set properly for QEMU<->host connectivity using SLIP.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.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>
