Bug 1114502 - wpa_supplicant start before network.target and ignored Link section in systemd-networkd config
wpa_supplicant start before network.target and ignored Link section in system...
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Network
All openSUSE Factory
: P5 - None : Normal (vote)
: ---
Assigned To: Karol Babioch
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2018-11-02 14:20 UTC by Илья Индиго
Modified: 2019-08-27 16:18 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Илья Индиго 2018-11-02 14:20:45 UTC
If wpa_supplicant is started before network.target, then the Link section is ignored in the systemd-networkd configuration file. For example, changing the MAC address is ignored.





In order to establish the required MAC Address and the interface received from the router the desired IP Address systemd-networkd (network.target) must start before wpa_supplicant and configure the network interface.
Now it starts after the network.target and when the system loads the MAC Address and accordingly the IP Address remains unchanged, until I manually restart wpa_supplicant.

To fix this, you need to change in wpa_supplicant@.service (in wpa_supplicant.service not necessary but desirable to be the same) from



After=dbus.service network.target

or even


If dbus starts after network.target (we don’t specify in each unit file After syslog and firewall).
Comment 1 Karol Babioch 2018-11-05 07:49:30 UTC

first of all, let me thank you for your bug report. Your reasoning makes sense, and I'm going to give this some testing.

However, I don't quite get this point:

(In reply to Илья Индиго from comment #0)
> or even
> After=network.target
> Wants=network.target
> If dbus starts after network.target (we don’t specify in each unit file
> After syslog and firewall).

1.) Why do you remove the dbus requirement completely?
2.) What do you mean by "we don’t specify in each unit file After syslog and firewall"

I'm probably also going to propose this change upstream, since they provide a template unit file with the upstream release tarball. While we ship our own, this would also fix it for a lot of other people on other distros.
Comment 2 Илья Индиго 2018-11-05 11:30:34 UTC
Thank you so much for paying attention to my problem! :-)

> 1.) Why do you remove the dbus requirement completely?
I am not familiar with the requirements for a unit Type=dbus, and when giving a suggestion to do this, I did not pay attention to the fact that it is a unit Type=dbus.
I assumed that it is possible, dbus is guaranteed to be already loaded to the network.target and it is no longer needed. (I do not insist on this, I rather consult with you, I did not do that in my configuration.)

> 2.) What do you mean by "we don’t specify in each unit file After syslog and firewall"
I will try to explain in my example.
I have services: postfix, dovecot, mariadb, apache.
In order for them to start correctly, they all need to have them run before them: rsyslog, where to write logs, firewalld, ports to be open and listened, and "network.target" for the network to work.
But not in one unit there is no "After = syslog firewall", but in all there is "After = network.target"
I assume that network.target already includes dependencies of basic services, such as rsyslog and firwalld, and therefore they are not there, but only nwtwork.target.
My guess to remove After = dbus is based on the fact that perhaps "network.target" already includes dbus.

If this helps you, I can give you full instructions on how to switch from NM to systemd-networkd that I use.

For example, I do not just change the Mac Adress only to Wi-Fi, I also change it to Ethernet on the same one, regardless of whether the server was connected via wire or without a wire, the router gave it one and the same IP Adress. (systemd-networkd allows automatic to switch network adapters without conflicts)
Comment 3 Илья Индиго 2018-11-05 12:27:48 UTC
I thought a little more and decided that "Wants=network.target" can cause problems when the network connection is nasty, for example, if you turn off the electricity, and when you turn on the network is not yet available.
In the strict guarantee that "network.target" was already running before launching "wpa_supplicant@.service" is not, and quite simple.

+After=dbus.service network.target
Comment 4 Karol Babioch 2018-11-14 15:26:09 UTC
Your arguments make a lot of sense, and I will try to test this thoroughly in the next couple of weeks. I have a couple of other things on my list, so this might take a while, so please do not think I've forgot about it ;-). We will address this eventually.
Comment 5 Илья Индиго 2018-11-14 16:06:50 UTC
Good. I understand.
Thank you.
Comment 6 Karol Babioch 2019-01-17 12:58:37 UTC
I finally managed to spend some time on this. I've bumped the version of the wpa_supplicant package to 2.7 and changed the systemd unit files in the way you suggested here. Could you give this package a go please, before I submit it to Tumbleweed and see if it works out in your case?

Comment 7 Илья Индиго 2019-01-17 17:15:12 UTC
Thank you very much! :-)
I will check the package today or tomorrow and let you know.
Comment 8 Илья Индиго 2019-01-17 18:04:17 UTC
There is something wrong.

After update to 2.7 and
sudo systemctl restart wpa_supplicant@wlo1
in log

1547747507.307970: wlo1: CTRL-EVENT-DISCONNECTED bssid=70:2e:22:6f:c7:08 reason=3 locally_generated=1
1547747507.308950: nl80211: deinit ifname=wlo1 disabled_11b_rates=0
1547747507.310618: wlo1: CTRL-EVENT-TERMINATING

And interface wlo1 always down

After downgrade to 2.6 and
sudo systemctl restart wpa_supplicant@wlo1
in log

1547747613.745890: Successfully initialized wpa_supplicant
1547747614.951308: wlo1: SME: Trying to authenticate with 70:2e:22:6f:c7:08 (SSID='ILYA' freq=2447 MHz)
1547747614.971999: wlo1: Trying to associate with 70:2e:22:6f:c7:08 (SSID='ILYA' freq=2447 MHz)
1547747614.981273: wlo1: Associated with 70:2e:22:6f:c7:08
1547747614.981341: wlo1: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
1547747614.990069: wlo1: WPA: Key negotiation completed with 70:2e:22:6f:c7:08 [PTK=CCMP GTK=CCMP]
1547747614.990158: wlo1: CTRL-EVENT-CONNECTED - Connection to 70:2e:22:6f:c7:08 completed [id=0 id_str=]

And all work fine.
Comment 9 Илья Индиго 2019-08-27 16:18:01 UTC
Fixed in SR https://build.opensuse.org/request/show/719580