The existing calls to ieee802154_radio_send() and soft MAC ACK handling
were inconsistent and/or not properly integrated with more recent
radio driver capabilities as CSMA/CA and ACK in hardware.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The method ieee802154_radio_handle_ack() does not belong to the
PHY/radio layer but to the L2 layer. It is a callback called from the
radio layer into the L2 layer and to be implemented by all L2 stacks.
This is the same pattern as is used for ieee802154_init(). The
'_radio_' infix in this function is therefore confusing and
conceptually wrong.
This change fixes the naming inconsistency and extensively documents
its rationale.
It is assumed that the change can be made without prior deprecation of the
existing method as in the rare cases where users have implemented custom
radio drivers these will break in obvious ways and can easily be fixed.
Nevertheless such a rename would not be justified on its own if it were
not for an important conceptual reason:
The renamed function represents a generic "inversion-of-control" pattern
which will become important in the TSCH context: It allows for clean
separation of concerns between the PHY/radio driver layer and the
MAC/L2 layer even in situations where the radio driver needs to be
involved for performance or deterministic timing reasons. This
"inversion-of-control" pattern can be applied to negotiate timing
sensitive reception and transmission windows, it let's the L2 layer
deterministically timestamp information elements just-in-time with
internal radio timer counter values, etc.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The IEEE 802.15.4 standard clearly separates clear channel assessment
from retransmission. This separation of concern was not represented in
the current channel access vs. retransmission implementation which
resulted in considerable duplication of code and logic.
This change removes the duplication of logic and encapsulates the
resulting functions in a private API that may only be used from within
Zephyr's native L2 layer.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The CSMA/CA algorithm had multiple issues:
- Timing of backoff periods depends on the PHY's symbol rate and other
PHY-specific settings. We introduce a preliminary solution that works
with current drivers. A fully standard-compliant long-term solution
has already been conceptualized but requires further pre-conditions,
see #50336 (issuecomment-1251122582).
- We enforce the condition defined in the standard that macMinBe must be
less than or equal macMaxBe.
- According to the standard a CSMA/CA failure should lead to immediate
abortion of the transmission attempt, no matter how many
retransmissions have been configured.
- The number of retransmissions was off by one. It is now used as
defined in the standard algorithm.
- Retransmissions are only allowed when acknowledgement is requested in
the packet.
- prepare_for_ack() has side effects and must be called before each
retransmission.
We also replace variables by constants where possible.
The function was renamed as it represents unslotted CSMA/CA and does not
support other CSMA/CA modes. These may be introduced in the future.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The ALOHA algorithm had two minor implementation errors:
- The number of retransmissions was off by one.
- Retransmissions are only allowed when acknowledgement is requested
otherwise it is to be assumed that the transmission was successful.
- prepare_for_ack() has side effects and must be called before each
retransmission.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The allowable ranges of several CSMA/CA-related settings were not
conforming to the standard, see IEEE 802.15.4-2020, section
8.4.3.1, table 8-94 (MAC PIB attributes). This change fixes the ranges.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
This adds a few line use zephyr_syscall_header() to include
headers containing syscall function prototypes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
If a user tries to enable TWT too early in the connection, then we might
enter TWT sleep even before DHCP is completed, this can result in packet
loss as when we wakeup we cannot receive traffic and completing DHCP
itself can take multiple intervals. Though static ip address can be
assigned too. Reject TWT till Wi-Fi interface has
a valid IP address.
Signed-off-by: Ajay Parida <ajay.parida@nordicsemi.no>
This commit replaces the workarounds spread around the
drivers and subsystems with the updated PPP L2
interface.
Signed-off-by: Bjarki Arge Andreasen <baa@trackunit.com>
Currently, the L2 PPP subsystem is not using the network
interface subsystem appropriately. Here are the issues:
1. net_if_up hidden away internally in net L2 PPP
2. net_if_down not used at all...
3. net_if_carrier_on / off is not used, a workaround is
used instead, which results in duplicated code
4. L2 PPP does not listen for network events, instead
it needs the workaround callbacks from drivers.
5. The carrier_on workaround is delegated to a complex
and broken sys work queue item.
This commit fixes all above issues. net_if_up/down and
net_if_carrier_on/off now work as expected. workaround
for carrier_on/off has been removed.
Signed-off-by: Bjarki Arge Andreasen <baa@trackunit.com>
Fix for not getting expected event information at application.
net_mgmt_event_notify_with_info() expects the address
not the value as pointer.
Signed-off-by: Ajay Parida <ajay.parida@nordicsemi.no>
A bug was introduced in one of my earlier commits: The shell does no
longer print the full extended address. Fixes the issue.
Fixes: #59125
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
As since commit bff6a5c, params.dst.ext_addr is no longer assigned with
the ctx->coord_ext_addr pointer, but a endianness swap is included, it
should be assigned with a proper buffer before the memcpy.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
For IEEE 802.15.4 compliance, the NET_L2_IEEE802154_ACK_REPLY option must
automatically be active if the radio driver does not AUTOACK and inactive
otherwise. No user interaction is required.
Future changes will deprecate this option and replace it by a standard
compliant automatic mechanism.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The IEEE 802.15.4 standard does not specify a "Sub-GHz" option.
Therefore this option will be deprecated in the foreseeable future.
Rationale: Selecting PHYs and frequency bands is abstracted by the
concept of channel pages (see IEEE 802.15.4-2020, 10.1.3).
Radio drivers may expose additional configuration options that
specify the low level frequency band, operating mode and other
PHY-specific parameters. Such parameters should be exposed on a driver
instance level, e.g. via devicetree or as runtime options of the driver.
PHY-specific attributes derived from driver settings (e.g. available
channels) can then be announced to L2 w/o the user having to be aware of
any implementation details of the specific PHY.
Future changes will introduce the necessary infrastructure to define
channel pages and other PHY-specific configuration options to
replace this option. New drivers should therefore not rely on this
option.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Variable declarations are moved to the beginning of the block in
which they are visible to ensure consistency with the remainder
of the code base.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The encryption-only security level has been removed from the
spec, see IEEE 802.15.4-2020, 9.4.2.2 Security Level field.
The standard provides the following explanation (ibid):
"This security level is deprecated and shall not be used in
implementation compliant with this standard. Devices that
receive frames with security level 4 shall discard them, as
described in 9.2.4. The counter mode encryption and cipher
block chaining message authentication code (CCM) used allows
trivial changes to the underlaying encrypted data unless
data authenticity is provided, thus using data confidentiality
only is not useful. In the case of TSCH mode, security level 4
allows higher security level frames to be downgraded to
security level 4 frames."
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
See IEEE 802.15.4-2020, 7.2.2.11 Source Addressing Mode field and
7.2.2.9 Destination Addressing Mode field, table 7-3: The
previously deprecated "Simple addressing mode" was removed
from the spec.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Currently the insertion of an authentication tag requires a memcpy() call
and breaks encapsulation.
This change removes the need for memcpy() and improves the encapsulation
by calculating and reserving the required headspace early on while
keeping insertion where it belongs in the outgoing security procedure.
This is also a preparation for improved standard compliance of the
outgoing security procedure which is scheduled for a later commit.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The naming of variables and arguments containing the authentication
tag length was inconsistent:
* Naming inconsistency between header "length" vs. authtag "size"
in the same API calls
* "Tag" rather than "Auth[orization ]Tag" in external API calls
which is too generic from a compliance and readability viewpoint.
This is in preparation to zero-copy authentication support.
Almost all call sites will be subject to required structural changes
later on so no relevant git blame noise/history loss will be introduced
by this naming change in the long run.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Over time, some non-standard concepts and extensions were introduced
into the stack (in KConfig, in drivers, in the internal API and into the
implementation) which makes introduction of additional standard-
compliant extensions like TSCH (and others) unnecessarily difficult.
To introduce extensions like TSCH it is required for the IEEE 802.15.4
stack to become more structurally aligned with the standard again which
will be the focus of some of the upcoming preparatory changes.
One way to check and prove standard compliance is to reference the
standard from within the source code. This change therefore introduces
inline references to the IEEE 802.15.4-2020 standard wherever possible.
Deviations from the standard are documented with TODO or deprecation
labels to be addressed in future changes.
In the future, new code introduced to the IEEE 802.15.4 stack should
be documented and reviewed for standard-compliance to avoid further
divergence. Most importantly:
* MAC/PHY configuration (via net mgmt, radio API, devicetree or
KConfig) should always be directly linked to well-defined MAC/PHY
PIB attributes if visible to the MAC API or the end user.
* Net management/shell/radio API commands should have a documented
reference to the corresponding MLME action from the standard.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The current implicit MAC payload length algorithm (based on
an otherwise irrelevant footer pointer) produces invalid
(non-standard) values for beacon and command frames.
This change produces standard-conforming MAC payload length
values and simplifies access to payload length.
It would have been possible to fix the current footer pointer
based approach but there are arguments in favor of the new
approach:
- The footer pointer is used nowhere in the current code
base and makes length calculations rather non-obvious.
- The new approach does not use more memory and is easier
to understand and use.
- This change is a first step to support of IEEE 802.15.4
information element (IE) support. At a later stage the
distinction between MAC payload length and frame payload
length will be introduced and become relevant to
distinguish between header and payload IEs. At that point
the current implicit length calculation algorithm will
break down anyways.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The current IEEE 802.15.4 stack would not accept beacons
unless hardware filtering was active.
This change fixes the bug.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The shell command calling the IEEE 802.15.4 scanning procedure
did not properly release its net management event callback.
This change fixes the memory leak.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Active and passive scanning requires the channel and PAN to
be set temporarily.
This change ensures that the temporary configuration will
be reverted even when the scan is aborted due to an error.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Beacon and command frames are consumed by the IEEE 802.15.4
stack internally and should therefore be released before
returning control to the generic net stack.
This change fixes the resource leak.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This change splits the IEEE 802.15.4 test into two separate
test profiles, one with and one without sockets enabled to ensure
that both configurations work correctly.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
The current IEEE 802.15.4 stack assumes that drivers will
not provide more than one fragment in incoming packages.
This change exposes and enforces the pre-existing assumption
made by the implementation.
So far this is not a limiting restriction as MPDUs with more
than 127 bytes are not supported yet. It will probably have to
be changed as soon as larger payloads (as allowed by PHYs
introduced more recently into the spec) might want to allocate
smaller fragments.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
When changing IEEE 802.15.4 security settings or setting security
to 'none' then the previous session must be cleaned up to avoid
resource leaks.
This change introduces proper clean-up of the security session.
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
This is needed for applications that rely on WPA supplicant being
in disconnected state before issue subsequent commands (e.g., issue scan
immediately after disconnect fails, until disconnect is completed).
Signed-off-by: Krishna T <krishna.t@nordicsemi.no>
Add a trailing _ to the section iterable name. This is useful, for
example, to implement numeric sorting like this:
SORT(.z_device_LEVEL_?_)
SORT(.z_device_LEVEL_??_)
Without the trailing _ it would not be possible to use the ?? wildcard
without triggering into trigraphs issues, because linker-defs.h header
is included in C files as well.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Provide an extra struct net_if * iface parameter to
net_if_ipv*_maddr_join/leave functions, so that the corresponding
interface context, the mcast address belong to, can be locked for the
operation.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
LLDP start timer is executed when iface is up
at startup, then once more when iface up event
is received.
When iface is up before net_lldp_init call, then multiple
entries are added to the lldp_ifaces related to the
same iface.
That leads to continuous loop execution within
lldp_tx_timeout.
This commit checks if lldp tx_timer_start is set and
doesn't append new entry into the slist.
The tx_timer_start is set at startup and reset on
down event.
Signed-off-by: Georgij Cernysiov <geo.cgv@gmail.com>
'ps_wakeup_mode' is used to set the wake up interval
to either 'dtim or 'listen_interval'. By default the
sta wakes up every dtim interval.
With 'ps_wakeup_mode' set to 'listen_interval' sta
will wake up for every listen interval period configured.
Signed-off-by: Ajay Parida <ajay.parida@nordicsemi.no>
listen interval is the time periods the STAs may be in idle
without listening beacons.
By default STA wakes up for every DTIM period.
If listen interval based power save is used
STA uses configured listen interval period(default 10
beacon intervals) to wake up.
Signed-off-by: Ajay Parida <ajay.parida@nordicsemi.no>
As we are using a generic validation function for limits, due to data
type mismatch the check for TWT interval overflow and fails.
Fix the data type and accordingly the maximum value in the help.
Signed-off-by: Krishna T <krishna.t@nordicsemi.no>
TFM is not the only provider for PSA API, which means
the PSA config shouldn't depend only on it.
Signed-off-by: Piotr Jasiński <piotr.jasinski@nordicsemi.no>
OpenThread networks do not use ND or MLD as they have their own set of
protocols to cover this functionality. So far, the use of OpenThread
with Zephyr relied on disabling those protocols support statically with
Kconfig, which prevented OT interfaces from being used along with other
IPv6 interfaces.
With the new network interface flags, it's now possible to disable ND
and MLD on individual interfaces, therefore disable them for OT
specifically.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
