network: fix race between RTM_NEWLINK and NL82011_CMD_NEW_INTERFACE

When a new wireless network interface is created by the kernel, it emits
both RTM_NEWLINK and NL80211_CMD_NEW_INTERFACE. These events can arrive
in either order and networkd must behave correctly in both cases.

The typical case is that RTM_NEWLINK is handled first, in which case
networkd creates a Link object and starts tracking it. When the
NL80211_CMD_NEW_INTERFACE message is handled, networkd then populates
the Link object with relevant wireless properties such as wireless
interface type (managed, AP, etc.).

In the event that the order is reversed however, networkd will fail to
populate these wireless properties because at the time of processing the
nl80211 message, the link is considered unknown. In that case, a debug
message is emitted:

  systemd-networkd[467]: nl80211: received new_interface(7) message for link '109' we don't know about, ignoring.

This is problematic because after the subsequent RTM_NEWLINK message,
networkd will have an incomplete view of the link. In particular, if a
.network configuration matches on some of the missing wireless
properties, such as WLANInterfaceType=, then it will never match.

The above race can be reproduced by using the mac80211_hwsim driver.
Suppose that there exists a .network configuration:

  [Match]
  WLANInterfaceType=ap
  ...

Now loop the creation/destruction of such an AP interface:

  while true
  do
    iw dev wlan0 interface add uap0 type __ap
    iw dev uap0 del
  done

The above debug message from networkd will then be observed very
quickly. And in that event, the .network file will fail to match.

To address the above race, have the nl80211 message handler store the
interface index in a set in case a Link object is not found on
NL80211_CMD_NEW_INTERFACE. The handler for RTM_NEWLINK can then query
this set, and explicitly request the wireless properties from nl80211
upon the creation of the Link object.

0 files changed, 0 insertions, 0 deletions