Actually run hwsim in the daemon mode to work as the wireless medium now
that hwsim supports it. The current test-runner code, which assumed a
different command line syntax, wasn't functional but it didn't affect
test-runner in any way.
Don't require the full length of a Management MPDU as a condition to
forward the frame, only require data up to the three addresses we need
to know where to forward the frame.
This check was failing with some frames during a deauthentication. We
could possibly forward shorter frames too if needed (send to all
possible recipients.)
Don't handle the hwsim netlink events we use to track radios and
interfaces if we're not in daemon mode. This quiets dbus errors when
using hwsim through the command line.
The name attribute in the NEW RADIO command needs at least 4 bytes for
the attribute header (struct nlattr), all the characters of the name
string and a NUL byte, and up to 3 bytes of alignment padding.
Otherwise, depending on the name length and whether the NO_VIF attribute
was the last, that attribute could end up being dropped and we were
ending up with too many interfaces inside test-runner.
If the current request is not freed when we receive the
NL80211_CMD_SCAN_ABORTED event, device.c will keep thinking that
we're still scanning and the scan.c logic also gets confused and may
resend the current request at some point and call sr->trigger again
causing a segfault in device.c.
I pass an empty bss_list to the callback, another possibility would be
to pass NULL to let the callback know not to replace old results yet.
The callbacks would need to handle a NULL first.
Implement a hwsim wireless medium inside hwsim.c. This doesn't do
anything to the frames it moves around yet, only tries to implement
the same logic that the kernel medium contains.
In daemon mode start a basic passive DBus interface to expose the
information on radios attached to mac80211_hwsim. In this version
interfaces have objects of their own. It might be simpler to only
show them as an array property on the radio object (array of pairs of
string, one string for address, one for name).
Handle the changes of interface address in RTNL New Link messages
similarly to the name changes, emit a NETDEV_WATCH_EVENT_ADDRESS_CHANGE
event and a propety change on dbus.
Note this can only happen when the interface is down so it doesn't
break anything but we need to handle it anyway.
DBus has certain rules on what constitutes a valid path. Since the
wiphy name is freeform, it is possible to set it such that the contents
do not contain a valid path.
We fall back to simply using the wiphy index as the path.
DBus strings must be valid utf8. The kernel only enforces that the
wiphy name is null terminated string. It does not validate or otherwise
check the contents in any way. Thus it is possible to have
non-printable or non-utf8 characters inside.
NL80211_CMD_SET_WIPHY can be used to set various attributes on the wiphy
object in the kernel. This includes ATTR_WIPHY_NAME among others. iwd
currently does not parse or store any of the other attributes, so we
react to changes in WIPHY_NAME only.
The wiphy attribute should never be repeated by the kernel, so this
check is ultimately not needed. This condition can also be easily
checked by looking at the iwmon output in case things do go terribly
wrong.
Read wiphy addresses from sysfs and perform the wiphy name to wiphy idx
mapping using sysfs. Do this directly on a new radio notification and
stop using new wiphy notifications except for updating the radio names.
Having the wiphy index available synchronously when parsing a new radio
event we store the wiphy index in the radio_info_rec struct directly and
drop struct wiphy_info_rec as there was a 1:1 mapping. With this, and
knowing that all radio_info data is available when new interface
notifications are received, the tracking is simplified because dbus
objects can be created and destroyed within the notification handlers.
We also now store both the wiphy hardware address data and separately
the interface MAC addresses and can use them more appropriately in the
medium implementation.
The kernel expects the radio name attribute to include the string's zero
byte. Things may still work without this if there is padding after the
attribute.
This has been now patched and the zero byte will be optional when that
patch makes its way through different trees.
Fix 1a64c4b771 by setting use_eapol_start
by default only when 8021x authentication is configured. Otherwise we'd
be sending EAPOL-Start even for WPA2 Personal possibly after the 4-Way
Handshake success.
Add a daemon mode that is entered when no action was specified on the
command line. In this mode hwsim tracks information on radios through
the netlink events. The interface to make use of the information is
added in the next patch.
This implements very initial support of WPS PIN based connections. The
scanning logic attempts to find an AP in PIN mode and tries to connect
to that AP. We currently do not try multiple APs if available or
implement the WSC 1.0 connection logic.
Right now the code checks for is_rsn to wait for the 4-way handshake and
sends the NETDEV_EVENT_4WAY_HANDSHAKE. However, is_rsn condition is not
true for WSC connections since they do not set an RSN field. Still,
they are EAP based handshakes and should be treated in the same manner.
We relax the is_rsn check to instead check for netdev->sm. Currently
netdev->sm is only non-NULL if handshake->own_ie field is not NULL or in
the case of eap-wsc connections.
Define minimum delay between roam attempts and add automatic retries.
This handles a few situations:
* roam attempt failing, then RSSI going above the threshold and below
again -- in that case we don't want to reattempt too soon, we'll only
reattempt after 60s.
* roam attempt failing then RSSI staying low for longer than 60 -- in
that case we want to reattempt after 60s too.
* signal being low from the moment we connected -- in that case we also
want to attempt a roam every some time.
