Handle NewLink events to detect interface mac address changes. In my
current testing I don't see nl80211 events on address change so it's
best to react to both types of events.
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.
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).
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.
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.
Add a new option to the hwsim binary to fetch all or a given hwsim radio.
Print out radio information which is currently returned in the reply to
user space.
Add new hwsim attributes to the enum and tweak getopt to behave properly
with or without giving the radio id on the command line.
If the MAC80211_HWSIM netlink family disappears, exit hwsim. This can
happen already at startup, for example if MAC80211_HWSIM functionality is
not compiled in the kernel or respective module loaded.
Kernel sends HWSIM_CMD_NEW_RADIO and HWSIM_CMD_DEL_RADIO multicast
events when new radio have been created and when existing one has
been deleted. The events are sent to "config" netlink multicast group.
The hwsim catches these events and uses the information to monitor
what simulated radios are created and deleted in the system.
The new attribute causes the radio to be removed if the hwsim process
dies. This is the default behaviour. If user calls the binary with -k
option, then the radio is kept after hwsim quits.
This requires kernel support for HWSIM_ATTR_DESTROY_RADIO_ON_CLOSE
attribute.
When a new radio is created, the kernel returns the new radio id
in the error code. If the error < 0, then that means a real error
and other values are used as a radio id.
When a radio is destroyed, the error code 0 means a success and
other values indicate an error.
