Since iwd_modules_init is now defered until nl80211_appeared, we can
assume the nl80211 object is available. This removes the need for
netdev_set_nl80211 completely.
In preparation for integrating IWD_MODULE into modules which require
nl80211 we move the module init into the nl80211_appeared callback.
This will guarentee that the nl80211 is available during module init
and allow modules to get their own copy of nl80211 rather than needing
a set function (e.g. netdev_set_nl80211).
Since the dbus name request callback happens before this as well any
dbus module can also use IWD_MODULE and simply assume the dbus object
is ready.
plugin_init was also deferred to nl80211_appeared since some plugins
depend on modules being initialized.
Converts agent into an IWD module. This removes the dbus dependency
on agent. Since dbus is initialized very early we can assume
dbus_get_bus is going to return a valid object.
Previously, station state 'connected' used to identify an interface associated
with AP. With the introduction of netconfig, an interface is assumed to be
connected after the IP addresses have been assigned to it. If netconfig is
disabled, the behavior remains unchanged.
Refactoring was required to allow for embedded certs. The existing
eap_tls_state object was changed to hold the cert types (l_queue,
l_certchain, l_key) rather than the file path, since there may not
actually be separate PEM files.
Care was taken to properly manage the memory of these objects.
Since the TLS object takes ownership when setting auth data or the
CA certs all error cases must be handled properly to free these
objects after they are loaded and in addition they must be set to
NULL so that the cleanup doesn't double free them.
If everything goes to plan, we load all the PEMs in settings_load,
provide these objects to the TLS APIs, and then NULL out the
pointers (TLS now owns this memory). If anything fails between
settings_load and l_tls_start we must free these objects.
A special format must be used to indicate that a PEM is embedded
inside the settings file. First, the l_settings format should be
followed for the PEM itself, e.g.
[@pem@my_ca_cert]
<CA Cert data>
This PEM can then be referenced by "embed:my_ca_cert", e.g.
EAP-TLS-CACert=embed:my_ca_cert
Any other value not starting with "embed:" will be treated as a file
path.
The IPv6 default route needs to be explicitly revoked. Unlike in IPv4,
there is no SRC address associated with the route and it will not be
removed on address removal.
The network configuration options for IPv6 are grouped under [IPv6]
and include the following:
ip= ADDRESS/PREFIX
gateway=ADDRESS
dns=ADDRESS
The placeholders for DHCPv6 are placed along the way and marked
as TODO items.
Previously, netconfig_ipv4_select_and_install was used to install
addresses on initial connection to a network and after we have roamed.
Now for the after roaming connection scenario we have
netconfig_reconfigure. Remove roaming related code from
netconfig_ipv4_select_and_install
As part of the de-coupling from station object, switch all of
the network settings inquiries to use active_settings. active_settings
are set with netconfig_configure by the owner of netconfig object
and removed with netconfig_reset once network disconnects.
Instead of relying on station state changed signal, netconfig
introduces three new API calls to configure, re-configure and
reset the network configurations. The owner of netconfig object
is responsible for initiating the re-configuration of the device
depending on its state.
As a first step to enable the usage of netconfig in ead and
prospective transition to be a part of ell, the public API for
creation and destruction of the netconfig objects has been
renamed and changed. Instead of hiding the netconfig objects inside
of netconfig module, the object is now passed back to the caller.
The internal queue of netconfig objects remains untouched, due
to limitations in ell’s implementation of rtnl. After the proper
changes are done to ell, netconfig_list is expected to be removed
from netconfig module.
A NEW_WIPHY event may not always contain all the information about a
given phy, but GET_WIPHY will. In order to get everything we must
mimic the behavior done during initalization and dump both wiphy
and interfaces when a NEW_WIPHY comes in.
Now, any NEW_WIPHY event will initialize a wiphy, but then do a
GET_WIPHY/GET_INTERFACE to obtain all the information. Because of
this we can ignore any NEW_INTERFACE notifications since we are
dumping the interface anyways.
Once some kernel changes get merged we wont need to do this anymore
so long as the 'full' NEW_WIPHY feature is supported.
If the AP sent us the plain passphrase we can now store that rather
than generating the PSK. This will allow WPA3 to work properly when
WPA3 + WSC is implemented.
This lets other modules (like WSC) to set a plain text passphrase
as opposed to only allowing a PSK to be set. network_get_psk was
also updated to generate a PSK on-the-fly if required. Since WPA3
requires the raw passphrase to work, it makes sense to just store
the passphrase if we have it.
If neighbor reports are unavailable, or the report yielded no
results we can quickly scan for only known frequencies. This
changes the original behavior where we would do a full scan
in this case.
This password key was deprecated in favor of the common EAP-Password
key. Its been about a year so we are now removing support entirely
for EAP-PWD-Password.
Gets a newly created scan_freq_set containing the most recent
frequencies for the network. The currently connected BSS frequency
(passed as a parameters) will not be included in the set.
Since the UUID was being generated purely on the file path, it
would never change for a given network (unless the SSID/name changed).
In the future we would like to use this unique UUID to generate a
MAC per-SSID, and if that network is forgotten we also want the UUID
to change next time the network is connected to.
Rather than only using the file path, the mtime can also be fed into
the UUID generation. Since the mtime would be changed after forgetting
and re-adding a known network we will get a new UUID.
Now, whenever a known network is removed, we lookup the UUID we have
in network_info and remove that entry in the settings file and
sync the frequency file.
The UUID was being generated every time we synced which is wasteful.
Instead we can track the UUID inside network_info and only generate
it once when needed.
Two new network_info APIs were added:
network_info_set_uuid
network_info_get_uuid
The setter is used when the frequency file is loaded. If a valid UUID
is found in the frequency file this UUID is set and used.
network_info_get_uuid will not just get the UUID, but actually generate
it if one has not been set yet. This will allow other modules to
get/generate the UUID if one has no been loaded from the frequency
file.
The QoS Map can come in either as a management frame or via the
Associate Response. In either case this IE simply needs to be
forwarded back to the kernel.
The extended capability bits were not being set properly inside
wiphy. Since we build the IE after the wiphy dump the first 2
bytes are the IE type and length. The way we were setting the bits
did not take this into account and were actually setting the
completely wrong bits.
The known frequency file was being loaded at the end of the known
networks initialization routine. This allowed all known networks
to be properly loaded, but since hotspot depends on known networks,
its initalization would be run afterwards meaning the frequency
loading would not have been finding any hotspot networks.
To fix this a new module was added inside known networks which
depends on hotspot. This means that first known networks will
initialize, then hotspot, then the frequency file would be loaded.
The current format for the .known_networks.freq file had a hidden
limitation of not being able to handle SSID's with some special
characters. Since the provisioning file path was used as the
group name the filename was limited to only characters supported
by l_settings groups, which conflicted with allowable SSID
characters.
Instead we can generate a unique UUID for each network and use
this as the group. For this particular case the group does not
really matter, so long as its unique. But we can utilize this unique
UUID for other purposes, including using it as a seed for changing
the MAC address per-connection in the future.
The .known_networks.freq file will now have the following format:
[<UUID>]
name=/path/to/provisioning/file
list= XXXX YYYY ZZZZ
The existing frequency syncing was done when IWD closes. Instead we
can sync as networks are connected to or promoted to known which
will keep the FS more up to date. This also allows hotspot networks
to use the known frequency file.
This API will sync the known frequencies of a network_info object
to disk. This will allow network to sync known frequencies as
known networks are added, rather that when IWD closes.
Since this will result in more frequent syncing that before, the
known_freqs settings pointer was moved globally in knownnetworks.c
as to only parse the file one time rather than on every sync.
Some of the EAP-PEAP server implementations seem to require a
cleartext ACK for the tunneled EAP-Success message similar to EAP-TLS
specification, instead of simply shutting down the tunnel like
EAP-PEAPv1 requires.
ACKing the tunneled EAP-Success seems also to work for implementations
which were relying on the tunnel close event.
create_dirs was dependent on the path ending in '/' to create the
full path. The hotspot code did not include a '/' at the end so
it was not getting created, which prevented the hotspot module
from initializing.
Station was building up the HS20 elements manually. Now we can
use this new API and let network take care of the complexity
of building network specific vendor IEs.
This op builds up the vendor IEs required for hotspot 2.0. The
version, and optionally the RC are provided in order to correctly
build the HS20 Indication Element and RC Selection element.
The HS20 module had its own getter for returning the matched roaming
consortium. Since we already have the network_info op for matching
we might as well return the matched RC rather than just a bool. This
allows the RC to be included in (Re)Association without the need for
a specific getter.
Denis Kenzior