++++++++ backtrace ++++++++
0 0x7fc0b20ca370 in /lib64/libc.so.6
1 0x4497d5 in l_dbus_message_new_error_valist() at /home/denkenz/iwd/ell/dbus-message.c:372
2 0x44994d in l_dbus_message_new_error() at /home/denkenz/iwd/ell/dbus-message.c:394
3 0x41369b in dbus_error_not_supported() at /home/denkenz/iwd/src/dbus.c:148
4 0x40eaf5 in device_connect_network() at /home/denkenz/iwd/src/device.c:1282
5 0x41f61c in network_autoconnect() at /home/denkenz/iwd/src/network.c:424
6 0x40c1c1 in device_autoconnect_next() at /home/denkenz/iwd/src/device.c:172
7 0x40cabf in device_set_scan_results() at /home/denkenz/iwd/src/device.c:368
8 0x40cb06 in new_scan_results() at /home/denkenz/iwd/src/device.c:376
9 0x41be8a in scan_finished() at /home/denkenz/iwd/src/scan.c:1021
10 0x41bf9e in get_scan_done() at /home/denkenz/iwd/src/scan.c:1048
11 0x43d5ce in destroy_request() at /home/denkenz/iwd/ell/genl.c:136
12 0x43ded1 in process_unicast() at /home/denkenz/iwd/ell/genl.c:395
13 0x43e295 in received_data() at /home/denkenz/iwd/ell/genl.c:502
14 0x43aa62 in io_callback() at /home/denkenz/iwd/ell/io.c:120
15 0x439632 in l_main_run() at /home/denkenz/iwd/ell/main.c:375 (discriminator 2)
16 0x403074 in main() at /home/denkenz/iwd/src/main.c:261
17 0x7fc0b20b7620 in /lib64/libc.so.6
The phy creation logic was a bit complex, using a hashmap to map between
phy names in the config file (e.g. rad0, rad2, etc) and interface names
created for that phy.
We take advantage of the fact that hwsim can create a radio with a given
name to simply assign the radio name from the autotest config file
directly. Then we name any interfaces created in order of phy creation.
A few extra sanity checks are also added.
Also handle the case of a periodic scan when handling a
NL80211_CMD_SCAN_ABORTED. The goal is to make sure the supplied callback
is always called if .trigger was called before, but this should also fix
some other corner cases.
* I add a sp.triggered field for periodic scans since sc->state doesn't
tell us whether the scan in progress was triggered by ourselved o
someone else (in that case .trigger has not been called)
* Since the NL80211_CMD_SCAN_ABORTED becomes similar to get_scan_done I
move the common code to scan_finished
* I believe this fixes a situation where we weren't updating sc->state
if we'd not triggered the scan, because both get_scan_done and the
NL80211_CMD_SCAN_ABORTED would return directly.
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.
