Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] IWD support for systemd-networkd #8157

Closed
shibumi opened this issue Feb 10, 2018 · 10 comments · Fixed by #13142
Closed

[RFE] IWD support for systemd-networkd #8157

shibumi opened this issue Feb 10, 2018 · 10 comments · Fixed by #13142
Labels
network RFE 🎁 Request for Enhancement, i.e. a feature request

Comments

@shibumi
Copy link
Contributor

shibumi commented Feb 10, 2018

Submission type

  • Request for enhancement (RFE)

Description

IWD, the new Intel Wireless daemon got its first release now[1].
It has full dbus support and other neat features.
I would like to suggest IWD support in systemd-networkd.

[1] https://www.kernel.org/pub/linux/network/wireless/

@poettering poettering added RFE 🎁 Request for Enhancement, i.e. a feature request network labels Feb 12, 2018
@cosmojg
Copy link

cosmojg commented Sep 12, 2018

Is IWD support complete? What remains to be done?

@shibumi
Copy link
Contributor Author

shibumi commented Sep 12, 2018

@cosmojg I guess it hasn't been touched yet. PRs are welcome. Although I have still no idea how this support would look like. The best idea I have is to have a relationship between wireless networks/ESSIDs and the systemd-networkd configuration for the wireless device. So I thought about a new segment for the Match command.

Something like this:
/etc/systemd/network/wlp3s0-home.network

[Match]
Name=wlp3s0
ESSID=HOME

[Network]
DHCP=ipv4
DNS=1.1.1.1

[DHCP]
UseDNS=no

/etc/systend/network/wlp3s0-corp.network

[Match]
Name=wlp3s0
ESSID=CORPORATION_WIFI

[Network]
Address=<my fancy static IP at corporation XY>
Gateway=<my fancy gateway for corporation XY>

I strongly disregard just implementing iwd core features into systemd-networkd. It should form a healthy relationship, but configuring iwd over systemd-networkd is something that should be discussed.

Maybe @poettering himself has some neat ideas for this. The IWD dbus API is still not fixed yet.. so I would propose waiting for a stable iwd release.

@amishmm
Copy link

amishmm commented Sep 12, 2018

I have already opened an RFE for this:
#9466

Probably valid not just for IWD but wpa_supplicant too?

@shibumi
Copy link
Contributor Author

shibumi commented Sep 12, 2018

@amishxda should be possible via IWD dbus API. But we would need a new wireless target for this, I guess. Because you need to wait for wireless connection until you do all the network stuff.

@yuwata
Copy link
Member

yuwata commented Jun 22, 2019

I've created #12842 for this RFE.

@johannbg
Copy link
Contributor

@yuwata wont any systemd networkd integraton with iwd conflict with iwd upstream decision of handling iwd configuration on it's own as in the iwd will manage the DHCP/Static IP assignment? Is it not best to be in contact with iwd upstream @holtmann @denkenz etc to ensure that we dont end up with conflicting implementation which ends up misconfiguration the network and or confuse end users and or incorrect network implementations ( which seems to be the case here with BSSID based on Denis responses upstream )?

This all boils down with what's the end game here with WIFI support I mean wpa_supplicant is on it's way out in the linux eco system as in it's being replaced with iwd and iwd seems to be intent on being island in the core/baseOS ( read as not part of consolidated core/baseOS platform thus not part of the system/service management framework thou arguably it belongs there ) and wants to manage it's own network configuration so why should there be an implementation of wpa_supplicant/iwd support in any shape or form to begin with, what purpose does it serve and or problem does it solve?

@zabbal
Copy link

zabbal commented Jul 23, 2019

I think that having all network configuration (wired and wireless) in a single place is plain convenient. Besides it enables things like setting "Metric=" in a coherent way as well as "[Bridge]" without race-condition.

I don't think we would differ much from other iwd users like NetworkManager which got their own separate configuration as well.

Having said that, it's definitely nice to get in touch with iwd devs to get their input but it shouldn't discourage us from using it the way which is convenient to us regardless of core/baseOS use case.

@shibumi
Copy link
Contributor Author

shibumi commented Jul 23, 2019

I have discussed this whole issue with one of the iwd devs. According to him, there should be no issue. Both ways can co-exist, but it's preferred to let iwd do the ip management, because systemd-networkd has not enough information about roaming etc. systemd-networkd would simply re-do DHCP at reconnect, with ip management in iwd the connection will be more stable (at least from the user point of view). On the other hand the feature is very appreciated for QoS, routing, etc.

@johannbg
Copy link
Contributor

Why was it preferred to let iwd do the ip management?

I would think one would probably want to add a switch on either side or both which configures which one is doing the ip management right? ( such "ControlledBy=" configuration switch is needed for more like keepalived etc )

@shibumi
Copy link
Contributor Author

shibumi commented Jul 23, 2019

it's preferred to let iwd do ip management mostly because of roaming and standards like 802.1ai. Systemd-networkd has not enough information to do roaming of wifi networks and for stuff like 802.1ai systemd-network is completely the wrong thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
network RFE 🎁 Request for Enhancement, i.e. a feature request
7 participants