9c5b8d46e5
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. |
||
---|---|---|
.clusterfuzzlite | ||
.github | ||
.semaphore | ||
catalog | ||
coccinelle | ||
docs | ||
factory | ||
hwdb.d | ||
LICENSES | ||
man | ||
mkosi.conf.d | ||
modprobe.d | ||
network | ||
po | ||
presets | ||
rules.d | ||
shell-completion | ||
src | ||
sysctl.d | ||
sysusers.d | ||
test | ||
tmpfiles.d | ||
tools | ||
units | ||
xorg | ||
.clang-format | ||
.ctags | ||
.dir-locals.el | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.mailmap | ||
.packit.yml | ||
.vimrc | ||
.ycm_extra_conf.py | ||
configure | ||
LICENSE.GPL2 | ||
LICENSE.LGPL2.1 | ||
Makefile | ||
meson.build | ||
meson_options.txt | ||
mkosi.build | ||
mkosi.kernel.config | ||
mkosi.postinst | ||
NEWS | ||
README | ||
README.md | ||
TODO |
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.