systemd specifies a special passive target unit 'network-pre.target' which may be pulled in by services that want to run before any network interface is brought up or configured. Correspondingly, network management services such as iwd and ead should specify After=network-pre.target to ensure a proper ordering with respect to this special target. For more information, see systemd.special(7) and [1]. [1] https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

Hi Marcel,

and replaced it with:     Before=network-pre.target

Hi Alvin, >>> systemd specifies a special passive target unit 'network-pre.target' >>> which may be pulled in by services that want to run before any network >>> interface is brought up or configured. Correspondingly, network >>> management services such as iwd and ead should specify >>> After=network-pre.target to ensure a proper ordering with respect to >>> this special target. >>> >>> For more information, see systemd.special(7) and [1]. >>> >>> [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fre... >> >> so what does this really do in practice. Both daemons are fully hotplug aware and it makes no difference when they are started. > > I can give two examples. > > The first is practical and we encountered it in our embedded system. The > second is hypothetical, but perhaps a little more convincing. > > 1. We have a oneshot service which must run to perform some platform > specific configuration of our wireless network interface before it is > ready to be used. One such thing is does is set the MAC address > according to some data in an EEPROM. While restructuring the service > file for this oneshot service I removed the line: > > Before=iwd.service systemd-networkd.service > > and replaced it with: > > Before=network-pre.target > > ... as is suggested in systemd's documentation. This seemed good to me > because it is more generic. > > I then noticed that during boot, iwd would run before this service and > connect to an AP. The AP was then kicking us off during the MAC address > change. This is how I noticed that iwd was not respecting the > network-pre.target order. > > FYI we are using a driver (brcmfmac) which doesn't allow > creating/destroying the primary interface. > > 2. Since iwd (and ead? never used it) can also do IP network > configuration, it's possible that it runs and does this stuff before > certain firewall rules are applied. This is the rationale given in the > systemd documentation. fair points. Please put them into the commit message so that when we ever git blame this change, we know why it made sense.

Just to note, I always hate that if you have to delay a service from starting up as early as possible and get the hardware ready to be used. Nobody worried about these things until we made it so blazing fast that WiFi will be ready and connected before you need it. They way how it should have been from the start.

Dear Alvin, Am 22.01.21 um 15:30 schrieb Alvin Šipraga: > On 1/22/21 3:23 PM, Marcel Holtmann wrote: >>>>> systemd specifies a special passive target unit 'network-pre.target' >>>>> which may be pulled in by services that want to run before any >>>>> network >>>>> interface is brought up or configured. Correspondingly, network >>>>> management services such as iwd and ead should specify >>>>> After=network-pre.target to ensure a proper ordering with respect to >>>>> this special target. >>>>> >>>>> For more information, see systemd.special(7) and [1]. >>>>> >>>>> [1] >>>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fre... >>>>> Good job Outlook. ;-)

>>>> so what does this really do in practice. Both daemons are fully >>>> hotplug aware and it makes no difference when they are started. >>> >>> I can give two examples. >>> >>> The first is practical and we encountered it in our embedded system. >>> The >>> second is hypothetical, but perhaps a little more convincing. >>> >>> 1. We have a oneshot service which must run to perform some platform >>> specific configuration of our wireless network interface before it is >>> ready to be used. One such thing is does is set the MAC address >>> according to some data in an EEPROM. While restructuring the service >>> file for this oneshot service I removed the line: >>> >>>     Before=iwd.service systemd-networkd.service >>> >>> and replaced it with: >>> >>>     Before=network-pre.target >>> >>> ... as is suggested in systemd's documentation. This seemed good to me >>> because it is more generic. >>> >>> I then noticed that during boot, iwd would run before this service and >>> connect to an AP. The AP was then kicking us off during the MAC address >>> change. This is how I noticed that iwd was not respecting the >>> network-pre.target order. >>> >>> FYI we are using a driver (brcmfmac) which doesn't allow >>> creating/destroying the primary interface. >>> >>> 2. Since iwd (and ead? never used it) can also do IP network >>> configuration, it's possible that it runs and does this stuff before >>> certain firewall rules are applied. This is the rationale given in the >>> systemd documentation. >> >> fair points. Please put them into the commit message so that when >> we ever git blame this change, we know why it made sense. > > Sure, I'll send a v2 patch in a moment. > >> Just to note, I always hate that if you have to delay a service from >> starting up as early as possible and get the hardware ready to >> be used. Nobody worried about these things until we made it so >> blazing fast that WiFi will be ready and connected before you need >> it. They way how it should have been from the start. Marcel, do you have a suggestion for the firewall rules issue? Should iwd check it itself, though that wouldn’t be as general? > Yeah I am also not a fan. The real truth is that the oneshot service I > described is an ugly hack that we have to put up with, which is why I > thought the firewall argument is rather more convincing. I am not sure, but shouldn’t udev provide a way to only mark a device as activated, if certain conditions are met, in this case your hack was run?

> If it makes you feel any better, this change only has an effect if the > system administrator has actually configured such a service which > specifies Before=network-pre.target and Wants=network-pre.target. The > network-pre.target on its own is passive and doesn't get pulled in just > because iwd says it should start After=network-pre.target. So the ideal > world you describe is hopefully not affected by this change. Yes, good to point that out again. Also, maybe note, that systemd-networkd and NetworkManager do the same ordering.