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.
Previously, command_option_get used to return NULL in the following
two scenarios: when command-line option with a such name didn’t exists
or its argument was not provided. This worked great for the cmd-line
options with the required arguments. With introduction of the cmd-line
options with no or optional arguments the function was changed to return
a boolean value indicating the existence of a such option and then, if
it had an argument - value_out variable would have been set.
Thereafter, this patch modifies the current usages of command_option_get.
Note, in these particular applications of command_option_get there is no
need to check the returned value from command_option_get, since these
options have the required arguments and we can only check if the value_out
parameter has been set or not.
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.
Instead of returning the mode of execution, command_init now
returns whether we are done and need to exit.
Thereafter, the mode of execution is now obtain though the command
module’s API.
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.
The test-runner hostapd section continues to grow with various
options to enable. The wording for each of the options was such
that it appeared optional (for test X uncomment Y). Since anyone
running test-runner will likely want the ability to run all
tests it made sense for us to just host our own hostapd config
file that can be copied into the hostapd tree.
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.
This autotest was manually creating the .known_network.freq file so
the UUID needed to be manually generated and updated for the test
to function correctly.
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.
