This module takes care of radio measurements which an AP can request.
There are many types of requests, and for now only beacon requests
are supported.
IWD will filter certain types of beacon requests that are NOT
supported:
- AP channel reports. Only single channel requests will be supported
- Autonomous measurements. Only direct requests will be supported.
IWD will not accept requets to trigger reports under certain
conditions (SNR/RSSI thresholds, etc.)
- Timed measurements. Only immediate measurements will be performed.
The accuracy for timed measurements cannot be reliably guaranteed
due to kernel scheduling/queues.
- Full reporting detail. The AP can request the STA return the full
set of IEs in a beacon. IWD does not currently save all IEs, plus
there is quite a bit of complexity involved as certain IEs get
truncated, and there are other length limitations.
There are other limitations not specific to beacon requests:
- IWD will support single measurement requests per report. Multiple
measurement request IEs can be included, but the reports will be
sent out separately.
- IWD will limit the number of requests it responds to in a given
amount of time. As it stands now this is hard coded to 2 requests
per second maximum. This will prevent DoS attacks.
- IWD will not accept any measurement requests from APs it is not
connected to, and will not accept any requests until connected.
To test embedded certs we need a settings file containing the same
PEMs that we generate during build time. In the same fashion generate
tls-settings.8021x file using the previously generated PEMs.
It seems that setting unit_test_eapol_DEPENDENCIES prevents test-eapol
from depending on some ell .c files, like other unit tests do that have
no explicit _DEPENDENCIES variable set in Makefile.am. Using
EXTRA_unit_test_eapol_DEPENDENCIES instead also seems to fix this.
Upon initial install iwd fails to start because the service file
says ReadWritePaths=/var/lib/iwd while that directory doesn't
(yet) exist. (This commit also fixes the same problem for ead.)
Addresses: https://bugs.debian.org/934194
Reported-by: Stephen Gelman <ssgelm@debian.org>
Simply prints the ANQP ID (human readable) and the length. Once
the ANQP dependency on netdev is removed the full ANQP parser
can be used, but for now its done manually. Once this is done it
will be much easier to print the actual ANQP ID data.
The module is responsible for the configuration of the address
resolution services. It will consist of the multiple service
specific plugins such as: systemd-resolved plugin, dnsmasq
plugin, etc.
This module will be in charge of managing Hotspot provisioning files
stored under the .hotspot/ directory. This includes a dir watch to
handle file changes/removal as well as an API to match a network
object to a hotspot provisioning file.
netconfig module will be responsible for the orchestration
of the network configuration with the IP addresses.
iwd creates one netconfig structure per interface index.
The purpose of this struct is to hold all of the interface
related addressing states such as: assigned dhcp
clients, known addresses, routes, etc.
Currently these are geared to support the WiFi Alliance Hotspot 2.0
ANQP elements, which all fall under the vendor specific ANQP element.
anqp_iter_next behaves similar to the genl parsers, where the id, length
and data will be returned as out parameters. Currently there is only
vendor support for Hotspot 2.0. anqp_iter_is_hs20 can be used to setup
the subtype, length, and data pointer to parse any Hotspot 2.0 ANQP
elements. From here the subtype can be checked and a vendor specific
parser for that subtype can be used to parse the data, e.g.
hs20_parse_osu_provider_nai.
Now the 'ft' module, previously ftutil, will be used to drive FT via
the auth-proto virtual class. This renaming is in preparation as
ftutil will become obsolete since all the IE building/processing is
going to be moved out of netdev. The new ft.c module will utilize
the existing ftutil functionality, but since this is now a full blown
auth protocol naming it 'ft' is better suited.
The SAE unit test needed to be updated to use the handshake_driver,
but in addition all the packet building needed a major overhaul. SAE
was changed to behave more like OWE/FILS, in that netdev passes the
raw mpdu frame into the RX callbacks. Before, only the authentication
data was passed. This requires the unit tests to now build up the
entire authentication frame, and in some cases append the header
to the data coming from the TX functions.
FILS (Fast Initial Link Setup) allows a station to negotiate a PTK during
authentication and association. This allows for a faster connection as
opposed to doing full EAP and the 4-way. FILS uses ERP (EAP Reauth Protocol)
to achieve this, but encapsulates the ERP data into an IE inside
authenticate frames. Association is then used to verify both sides have
valid keys, as well as delivering the GTK/IGTK.
FILS will work similar to SAE/OWE/FT where netdev registers a fils_sm, and
then forwards all Auth/Assoc frame data to and from the FILS module.
This reverts commit 1e337259ce.
Using util_get_username was wrong in this context. MSCHAPv2 expects us
to only strip the domain name from identities of the form
domain\identity. util_get_username would also strip identities of the
form username@domain.com.
ERP (EAP Reauthentication Protocol) allows a station to quickly
reauthenticate using keys from a previous EAP authentication.
This change both implements ERP as well as moves the key cache into
the ERP module.
ERP in its current form is here to only support FILS. ERP is likely not
widespread and there is no easy way to determine if an AP supports ERP
without trying it. Attempting ERP with a non-ERP enabled AP will actually
result in longer connection times since ERP must fail and then full EAP
is done afterwards. For this reason ERP was separated from EAP and a
separate ERP state machine must be created. As it stands now, ERP cannot
be used on its own, only with FILS.
