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.
SAE was a bit trickier than OWE/FILS because the initial implementation
for SAE did not include parsing raw authenticate frames (netdev skipped
the header and passed just the authentication data). OWE/FILS did not
do this and parse the entire frame in the RX callbacks. Because of this
it was not as simple as just setting some RX callbacks. In addition,
the TX functions include some of the authentication header/data, but
not all (thanks NL80211), so this will require an overhaul to test-sae
since the unit test passes frames from one SM to another to test the
protocol end-to-end (essentially the header needs to be prepended to
any data coming from the TX functions for the end-to-end tests).
Since ERP is only used for FILS and not behaving in the 'normal' ERP
fashion (dealing with actual EAP data, timeouts etc.) we can structure
ERP as a more synchronous protocol, removing the need for a complete
callback.
Now, erp_rx_packet returns a status, so FILS can decide how to handle
any failures. The complete callback was also removed in favor of a
getter for the RMSK (erp_get_rmsk). This allows FILS to syncronously
handle ERP, and potentially fail directly in fils_rx_authenticate.
A new eapol API was added specifically for FILS (eapol_set_started). Since
either way is special cased for FILS, its a bit cleaner to just check the
AKM inside eapol_start and, if FILS, dont start any timeouts or start the
handshake (effectively what eapol_set_started was doing).
This is a new concept applying to any protocol working over authenticate
and/or associate frames (OWE/SAE/FILS). All these protocols behave
similarly enough that they can be unified into a handshake driver
structure.
Now, each protocol will initialize this auth_proto structure inside
their own internal data. The auth_proto will be returned from
the initializer which netdev can then use to manage the protocol by
forwarding authenticate/associate frames into the individual drivers.
The auth_proto consists only of function pointers:
start - starts the protocol
free - frees the driver data
rx_authenticate - receive authenticate frame
rx_associate - receive associate frame
auth_timeout - authenticate frame timed out
assoc_timeout - associate frame timed out
If the setting is true we'll not attempt to remove or create
interfaces on any wiphys and will only use the default interface
(if it exists). If false, force us managing the interfaces. Both
values override the auto logic.
An unexpected Associate event would cause iwd to crash when accessing
netdev->handshake->mde. netdev->handshake is only set if we're
attempting to connect or connected somewhere so check netdev->connected
first.
Running autotests with native hardware will not work on tests which
depend on the hwsim python API (since hwsim will not be running).
For these tests, it will now be required that they specify:
needs_hwsim=1
This allows the test to be skipped when running with native hardware
rather than the test failing with a python exception.
This patch allows the host machine to pass through its PCI/USB network
cards into the test-runner virtual machine. By doing this we can run
nearly all the same autotests using physical/real wireless hardware.
First off, utilizing this feature requires a properly configured host
machine. There are kernel boot parameters and config files that need to
be configured before any of this will work. Unfortunately there is no
way around this, and hence this feature is not particularly aimed for
"the masses", but rather for specially configured test machines.
A new configuration file was introduced (tools/hw.conf) which is just an
example, it should be edited to work with the host machine using it. This
file merely holds the PCI addresses/USB bus of the devices you wish to pass
through to qemu.
Passing in this hardware config file with --hw <file> tells test-runner
that you are attempting to use this new feature. The tests themselves
do not need to change, its the initial test setup that required some
changes.
Since we are no longer creating radios we must discover the radios that
are present (once in the VM). This is done using borrowed code from IWD
to dump wiphys and interfaces. As the wiphys/interfaces are dumped, we
build up the wiphy list. In the hwsim case we still build this list up
when we create the radios, which hasn't changed. This does lead us to
have some special cleaup, where in the native case we just 'reset' the
list into its state pre-test (removing any hostapd flags). And as before
with the hwsim case we fully destroy and free the wiphy list, since a
new list will be created on the next test (along with new radios).
There should not need to be any changes to the tests themselves, but
potentially to some hw.conf files. A new key was introduced, 'needs_hwsim'
which need to be set on any tests that require the hwsim dbus API. This
tells test-runner to skip this test, otherwise it would fail in native
mode.
One last minor detail; the wiphy->id was changed to an unsigned int. This
is to match the type the kernel uses when dumping wiphys. Because of
this '0' is now the error case for both hwsim and native mode rather than
-1. Error checks were updated accordingly.
FILS needs to allocate an extra 16 bytes of key data for the AES-SIV
vector. Instead of leaving it up to the caller to figure this out (as
was done with the GTK builder) eapol_create_common can allocate the
extra space since it knows the MIC length.
This also updates _create_gtk_2_of_2 as it no longer needs to create
an extra data array.
Since FILS does not use a MIC, the 1/4 handler would always get called
for FILS PTK rekeys. We can use the fact that message 1/4 has no MIC as
well as no encrypted data to determine which packet it is. Both no MIC
and no encrypted data means its message 1/4. Anything else is 3/4.
For FILS rekeys, we still derive the PTK using the 4-way handshake.
And for FILS-SHA384 we need the SHA384 KDF variant when deriving.
This change adds both FILS-SHA256 and FILS-SHA384 to the checks
for determining the SHA variant.
crypto_derive_pairwise_ptk was taking a boolean to decide whether to
use SHA1 or SHA256, but for FILS SHA384 may also be required for
rekeys depending on the AKM.
crypto_derive_pairwise_ptk was changed to take l_checksum_type instead
of a boolean to allow for all 3 SHA types.
This new test was merged during the time when testutil was not working
properly, so it was never verified to work with respect to testutil
(testing for 'connected' has always worked).
Since testFILS has 2 hostapd interfaces test_interface_connected was
defaulting to the incorrect interface for the SHA384 test. Now, the
explicit interfaces are passed in when checking for connectivity.
AP still relies on the get_data/set_length semantics. Its more convenient
to still use these since it avoids the need for extra temporary buffers
when building the rates IE.
The TLV builder APIs were not very intuative, and in some (or all)
cases required access to the builder structure directly, either to
set the TLV buffer or to get the buffer at the end.
This change adds a new API, ie_tlv_builder_set_data, which both sets
the length for the current TLV and copies the TLV data in one go.
This will avoid the need for memcpy(ie_tlv_builder_get_data(...),...)
ie_tlv_builder_finalize was also changed to return a pointer to the
start of the build buffer. This will eliminate the need to access
builder.tlv after building the TLVs.
ie_tlv_builder_init was changed to take an optional buffer to hold
the TLV data. Passing NULL/0 will build the TLV in the internal
buffer. Passing in a pointer and length will build into the passed
in buffer.
Don't use del wd to dereference the IWD instance at the end of the function
where it has been defined in the first place as at this point wd is about
to have its reference count decreased anyway (the variable's scope is
ending) so it's pointless (but didn't hurt).
Relying on the __del__ destructor to kill the IWD process in those tests
it has been started in the constructor is a bit of a hack in the first
place, because the destructor is called on garbage collection and even
through CPython does this on the refcount reaching 0, this is not
documented and there's no guideline on when it should happen or if it
should happen at all. So it could be argued that we should keep the del
wd statemenets to be able to easily replace all of them with a call to a
new method. But most of them are not placed so that they're guaranteed
to happen on test success or failure. It would probably be easier to do
this and other housekeeping in a base class and make the tests its
subclasses. Also some of these tests don't really need to launch iwd
themselves, since IWD now tracks changes in the known network files I
think IWD only really needs to be killed between tests when main.conf
changes.
In the tests that only want to iterate over the hostapd interfaces,
simplify the pattern of walking through the whole wiphy_map tree by
instead using the hostapd_map variable which is already filtered to only
contain hostapd interfaces.
For the interface connectivity tests obtain the lists of interfaces in
use directly from the IWD class, which has the current list from DBus
properties.
Let manager.c signal to wiphy.c when the wiphy parsing from the genl
messages is complete. When we query for existing wiphy using the
GET_WIPHY dump command we get many genl messages per wiphy, on a
notification we only get one message. So after wiphy_create there may
be one or many calls to wiphy_update_from_genl. wiphy_create_complete
is called after all of them, so wiphy.c can be sure it's done with
parsing the wiphy attributes when in prints the new wiphy summary log
message, like it did before manager.c was added.
I had wrongly assumed that all the important wiphy attributes were in
the first message in the dump, but NL80211_ATTR_EXT_FEATURES was not and
wasn't being parsed which was breaking at least testRSSIAgent.
The hostapd_map dictionary is indexed by the interface name so there's
no point iterating over it to find that entry whose name matches, we can
look up by the name directly. Simplify code.
In the test utilties updated the wiphy_map struct built from the
TEST_WIPHY_LIST variable to parse the new format and to use a new
structure where each wiphy is a namedtuple and each interface under it
also contains a reference to that wiphy. The 'use' field is now
assigned to the wiphy instead of to the interface.
Move the interface creation code from configure_hw_radios to
configure_hostapd_instaces so as not to create unneeded interfaces on
the wiphys that IWD is going to manage. We pass a wiphy whitelist to
IWD later and IWD now creates the interfaces it needs on those managed
wiphys. Change TEST_WIPHY_LIST format to only include the interface
name for the wiphys used by hostapd.
Note that we still remove interfaces just before removing the hwsim
radios on exit, it seems like there's no point removing the interfaces
in that case.
Drop a pointless asignment of has_hw_conf to false when it's already
false, fix index when accessing radio_conf_list. Apparently the SETUP
group is not used in any of our test and wasn't tested itself so could
as well have removed the code.
The option may be present but may not parse correctly as a list in which
case has_hw_conf will be true but radio_conf_list will be NULL and we
might crash.
