3
0
mirror of https://git.kernel.org/pub/scm/network/wireless/iwd.git synced 2024-11-22 23:09:34 +01:00
Commit Graph

62 Commits

Author SHA1 Message Date
Denis Kenzior
3a91efd3a8 manager: Refine filtered dumps
When we detect a new phy being added, we schedule a filtered dump of
the newly detected WIPHY and associated INTERFACEs.  This code path and
related processing of the dumps was mostly shared with the un-filtered
dump of all WIPHYs and INTERFACEs which is performed when iwd starts.
This normally worked fine as long as a single WIPHY was created at a
time.  However, if multiphy new phys were detected in a short amount of
time, the logic would get confused and try to process phys that have not
been probed yet.  This resulted in iwd trying to create devices or not
detecting devices properly.

Fix this by only processing the target WIPHY and related INTERFACEs
when the filtered dump is performed, and not any additional ones that
might still be pending.

While here, remove a misleading comment:
manager_wiphy_check_setup_done() would succeed only if iwd decided to
keep the default interfaces created by the kernel.
2022-02-14 16:02:23 -06:00
Denis Kenzior
fe95cbe077 treewide: Various style fixups
- Mostly problems with whitespace:
	- Use of spaces instead of tabs
	- Stray spaces before closing ')
	- Missing spaces

- Missing 'void' from function declarations & definitions that
  take no arguments.

- Wrong indentation level
2022-01-11 11:07:05 -06:00
Denis Kenzior
a001740506 manager: Initialize all default interfaces
When UseDefaultInterface is set, iwd doesn't attempt to destroy and
recreate any default interfaces it detects.  However, only a single
default interface was ever remembered & initialized.  This is fine for
most cases since the kernel would typically only create a single netdev
by default.

However, some drivers can create multiple netdevs by default, if
configured to do so.  Other usecases, such as tethering, can also
benefit if iwd initialized & managed all default netdevs that were
detected at iwd start time or device hotplug.
2021-10-08 13:23:36 -05:00
Denis Kenzior
6f925c4dae manager/wiphy: Move default if determination
Move the driver database into wiphy.c so it can be extended with other
potential driver quirks.
2021-10-01 09:28:56 -05:00
Denis Kenzior
b9304eaf20 manager: Do not check deprecated use_default_interface 2021-06-01 10:29:42 -05:00
Marcel Holtmann
25ec652423 manager: If driver is not provided, then use default interfaces 2021-02-18 21:43:56 +01:00
Denis Kenzior
6db352a82d manager: UseDefaultInterface for bcmsdh_sdmmc
This driver is used on some ARM based devices
2021-01-27 09:58:34 -06:00
James Prestwood
d6a3798078 manager: move debug print in dump callback
This callback gets called way to many times to have a debug print
in the location that it was. Instead only print if a NEW wiphy is
found, and also print the name/id.
2020-05-01 19:54:37 -05:00
Andrew Zaborowski
358d0ca201 manager: Create/destroy P2P devices
Create a P2P device interface along with the station interface when
setting up a wiphy and handle the interface being removed.
2020-04-10 06:39:48 -05:00
James Prestwood
f96f8ba4a0 manager: remove warning for AddressRandomization option
Since the 'network' value is handled inside netdev we don't want this warning
being printed.
2020-03-18 13:10:41 -05:00
Denis Kenzior
4f745ff930 manager: Fix initialization for blacklisted drivers
The pending wiphy state 'use_default' variable was not set early enough
in some circumstances resulting in weird behavior for blacklisted
drivers.  Fix this by adding a manager_wiphy_dump_done callback which
will properly initialize the use_default value.

Fixes: c4b2f10483 ("manager: Handle missing NEW_WIPHY events")
2020-02-05 14:27:05 -06:00
Denis Kenzior
360f66f71c manager: Also set retry when using default interfaces 2020-02-05 09:14:47 -06:00
Denis Kenzior
8530396fb3 manager: Add brcmfmac to the blacklist
brcmfmac does not allow the removal of the default / primary interface.
So there isn't much point in having iwd attempt this.

Another issue is that brcmfmac _does_ allow the deletion of non-default
interfaces.  So starting iwd on a system with a station & ap interface
active can result in iwd attempting to delete all the interfaces.  Given
the above, it succeeds in deleting the ap interface but not the station
one.  In strange circumstances it might end up thinking that the ap
interface is the 'default' and trying to use it, whereas it was just
successfully removed.
2020-02-04 16:00:46 -06:00
Denis Kenzior
f168fb2e16 manager: Fix valgrind complaint
==192== Conditional jump or move depends on uninitialised value(s)
==192==    at 0x4531D3: l_queue_find (queue.c:346)
==192==    by 0x42F1F8: manager_config_notify (manager.c:667)
==192==    by 0x45A895: process_multicast (genl.c:970)
==192==    by 0x45A895: received_data (genl.c:1037)
==192==    by 0x4577B2: io_callback (io.c:126)
==192==    by 0x456B0D: l_main_iterate (main.c:473)
==192==    by 0x456BCB: l_main_run (main.c:520)
==192==    by 0x456DDA: l_main_run_with_signal (main.c:642)
==192==    by 0x4034B0: main (main.c:497)
2020-02-04 11:05:10 -06:00
Denis Kenzior
c4b2f10483 manager: Handle missing NEW_WIPHY events
The kernel emits NEW_WIPHY events whenever a new wiphy is registered.
Unfortunately these events are emitted under the 'legacy' semantics and
have a hard size limit of 4096 bytes.  Unfortunately, it is possible for
a NEW_WIPHY message to exceed this limit (ath10k cards seem to be
affected in particular), which results in the kernel never sending these
messages out.  This can lead to NEW_INTERFACE events being emitted with
a wiphy_id that had no corresponding NEW_WIPHY event emitted.  Such a
sequence can confuse iwd's hardware detection logic, particularly during
hot-plug or system boot.

Fix this by re-dumping the wiphy if such a condition is detected.  This
has some interaction with blacklisted wiphys, so the wiphy objects are
now always tracked and marked as blacklisted.  Before, the blacklisted
wiphys were simply not added to the iwd list of tracked wiphys.
2020-02-04 10:42:07 -06:00
Andrew Zaborowski
55f9639ee3 manager: Retry the interface setup if we get an EBUSY
Sometimes, at least with brcmfmac, the default interface apparently
takes a moment to get created after the NEW_WIPHY event.  We didn't
really consider this case in the NEW_WIPHY handler and we've got a race
condition.  It fixes the following bug for me:
https://bugs.archlinux.org/task/63912 -- tested by removing and
re-modprobing the brcmfmac module rather than rebooting.

To work around this wait for the NEW_INTERFACE event and then retry the
setup.  We still do the initial attempt directly after NEW_WIPHY to
handle cases like wiphys with no default interfaces and pre-existing
wiphys.
2020-01-28 15:10:10 -06:00
Andrew Zaborowski
aec7c0f39c manager: Make sure all interface are processed after dump
In manager_interface_dump_done use l_queue_foreach_remove instead of
l_queue_remove_if to make sure we process all of the interfaces.
2020-01-27 15:00:23 -06:00
Torstein Husebø
759dbdd37f treewide: fix typos 2020-01-21 16:03:28 -06:00
Andrew Zaborowski
a716f46573 netdev: Replace bool randomize_mac with specific address
Allow netdev_create_from_genl callers to draw a random or non-random MAC
and pass it in the parameter instead of a bool to tell us to generating
the MAC locally.  In P2P we are generating the MAC some time before
creating the netdev in order to pass it to the peer during negotiation.
2020-01-06 11:27:38 -06:00
Marcel Holtmann
ab5742bb32 module: Move declarations into separate header file 2019-11-07 23:40:13 +01:00
Denis Kenzior
7db8cf92fe manager: Switch to CamelCase for mac_randomize 2019-10-25 11:21:04 -05:00
Denis Kenzior
b3c08da45b manager: Use CamelCase for use_default_interface 2019-10-25 09:20:42 -05:00
Denis Kenzior
cc2d4f97e2 manager: Make sure pending_wiphys remains NULL on error 2019-10-11 15:41:16 -05:00
James Prestwood
2d8d47c9dd manager: utilize IWD_MODULE
Converts manager into an IWD module.
2019-10-11 15:38:25 -05:00
James Prestwood
87c42bccf1 manager: remove white/black list from argument
Instead we add getters for these lists that manager_init can use.
2019-10-11 15:37:58 -05:00
Denis Kenzior
91784425ec wiphy: Remove wiphy_parse_id_and_name
in favor of using nl80211_parse_attrs
2019-09-19 22:55:07 -05:00
Denis Kenzior
bf7e62fafb manager: Simplify parsing using nl80211_parse_attrs 2019-09-19 22:42:25 -05:00
Denis Kenzior
d400c7f303 manager: Simplify manager_parse_wiphy_id
using nl80211_get_attrs
2019-09-19 22:42:02 -05:00
Denis Kenzior
2772845a7b manager: Simplify manager_parse_ifindex
using nl80211_parse_attrs
2019-09-19 22:42:02 -05:00
Denis Kenzior
1fc480c007 manager: Remove stale comment
setup_timeout was removed by the previous patch, so this comment no
longer applies.
2019-09-19 21:05:57 -05:00
James Prestwood
95f1fb1663 manager: dump wiphy/iface on NEW_WIPHY
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.
2019-09-19 20:49:41 -05:00
Will Dietz
690c9c2045 manager: Fix build
Attached, but basically replace 2-argument call to l_genl_msg_new
with what seems rather likely was intended instead: l_genl_msg_new_sized.
2019-08-21 12:29:22 -05:00
Denis Kenzior
9f1875fd3d manager: Use split wiphy dumps 2019-08-20 18:04:27 -05:00
Marcel Holtmann
deee526b98 manager: Make default_if_driver_list static 2019-08-04 00:35:14 +02:00
Denis Kenzior
f557c7e6cd treewide: Use nl80211cmd_to_string
Using integer ids for event notifications received was hard to debug.
Use the nl80211cmd_to_string function to prettify these.
2019-07-15 14:06:26 -05:00
Denis Kenzior
bd4446070f manager: Create interfaces with a random mac
If supported by the driver, we can create an interface directly with a
random MAC if configured to do so.  If the driver does not have this
capability, then tell netdev to perform the necessary logic as part of
the interface initialization procedure.
2019-07-02 15:47:05 -05:00
Denis Kenzior
397699c9c5 manager: Fix memory leak 2019-06-21 12:22:48 -05:00
Andrew Zaborowski
08ec88671a manager: Also delete interfaces without an ifindex, cleanup 2019-05-13 14:10:49 -05:00
Andrew Zaborowski
36c08b9508 manager: Disable touching interfaces for some drivers
Blacklist some drivers known to crash when interfaces are deleted or
created so that we don't even attempt that before falling back to using
the default interface.
2019-05-08 11:52:52 -05:00
Andrew Zaborowski
7ce8d9d8b6 manager: Fix iteration over wiphy setup states
manager_interface_dump_done would use manager_create_interfaces() at the
end of the loop iterating over pending_wiphys.  To prevent it from
crashing make sure manager_create_interfaces never frees the pending
wiphy state and instead make the caller check whether it needs to be
freed so it can be done safely inside loops.
2019-05-08 11:52:14 -05:00
Andrew Zaborowski
7bc553e470 manager: Add use_default_if setting
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.
2019-05-02 10:47:45 -05:00
Andrew Zaborowski
06eb3bbf6a manager: Set state->use_default in manager_rx_cmd_new_wiphy
Make sure this gets set both when we discover a wiphy through a netlink
event in runtime, and when we dump all wiphys on startup.
2019-05-02 10:47:45 -05:00
Andrew Zaborowski
14d69873b0 wiphy: Add wiphy_create_complete
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.
2019-04-22 16:34:51 -05:00
Denis Kenzior
02b3ab6793 manager: Run an interface dump on startup
Instead of handling NEW_WIPHY events and WIHPY_DUMP events in a similar
fashion, split up the paths to optimize iwd startup time.  There's
fundamentally no reason to wait a second (and eat up file-descriptor
resources for timers unnecessarily) when we can simply start an
interface dump right after the wiphy dump.

In case a new wiphy is added in the middle of a wiphy dump, we will
likely get a new wiphy event anyway, in which case a setup_timeout will
be created and we will ignore this phy during the interface dump
processing.

This also optimizes the case of iwd being re-started, in which case
there are no interfaces present.
2019-04-16 17:51:00 -05:00
Denis Kenzior
d99242846c manager: Split up new_wiphy dumps & events
Separate out the two types of NEW_WIPHY handlers into separate paths and
factor out the common code into a utility function.

Dumps of CMD_NEW_WIPHY can be split up over several messages, while
CMD_NEW_WIPHY events (generated when a new card is plugged in) are
stuffed into a single message.

This also prepares ground for follow-on commits where we will handle the
two types of events differently.
2019-04-16 17:51:00 -05:00
Denis Kenzior
1b08602727 manager: Make sure to not leak msg on failure:wq 2019-04-16 17:51:00 -05:00
Denis Kenzior
d85e6eedff manager: Don't try to create pending_state more than once 2019-04-16 17:51:00 -05:00
Andrew Zaborowski
467b6341d8 manager: Handle interface white/blacklists
Mirror netdev.c white/blacklist logic.  If either or both the whitelist
and the blacklist are given also fall back to not touching the existing
interface setup on the wiphy.
2019-04-16 17:51:00 -05:00
Andrew Zaborowski
9e079ba4fc manager: Fallback to old logic for some drivers
If we get an error during DEL_INTERFACE or NEW_INTERFACE we may be
dealing with a driver that doesn't implement virtual interfaces or
doesn't implement deleting the default interface.  In this case fall
back to using the first usable interface that we've detected on this
wiphy.

There's at least one full-mac driver that doesn't implement the cfg80211
.del_virtual_intf and .add_virtual_intf methods and at least one that
only allows P2P interfaces to be manipulated.  mac80211 drivers seem to
at least implement those methods but I didn't check to see if there are
driver where they'd eventually return EOPNOTSUPP.
2019-04-16 17:51:00 -05:00
Andrew Zaborowski
d907593c08 manager: Create an interface on each wiphy and register netdevs
This is probably the trickiest part in this patchset.  I'm introducing a
new logic where instead of using the interfaces that we find present
when a wiphy is detected, which would normally be the one default
interface per wiphy but could be 0 or more than one, we create one
ourselves with the socket owner attribute and use exactly one for
Station, AP and Ad-Hoc modes.  When IWD starts we delete all the
interfaces on existing wiphys that we're going to use (as determined by
the wiphy white/blacklists) or freshly hotplugged ones, and only then we
register the interface we're going to use meaning that the wiphy's
limits on the number of concurrent interfaces of each type should be at
0.  Otherwise we'd be unlikely to be abe to create the station interface
as most adapters only allow one.  After that we ignore any interfaces
that may be created by other processes as we have no use for multiple
station interfaces.

At this point manager.c only keeps local state for wiphys during
the interface setup although when we start adding P2P code we will be
creating and removing interfaces multiple times during the wiphy's
runtime and may need to track it here or in wiphy.c.  We do not
specifically check the interface number limits received during the wiphy
dump, if we need to create any interfaces and we're over the driver's
maximum for that specific iftype we'll still attempt it and report error
if it fails.

I tested this and it seems to work with my laptop's intel card and some
USB hotplug adapters.
2019-04-16 17:51:00 -05:00