The IWD thread

jasonwryan · 2018-05-14 07:49:44

With the announcement about IWD, I thought it would be a good idea to collect early impressions and experiences here. Relevant information can then be added to the wiki as necessary.

I noticed a couple of things:

iwctl works out of the box on the vanilla Arch kernel as advertised. It remembers networks so rebooting sees you immediately reconnected. Nice!
If you have compiled your own kernel, you need to ensure all the relevant crypto options are built in or added as modules

The only issue I encountered was that I found that removing wpa_supplicant and openssl-1.0 breaks connman. This doesn't seem right as IWD is supposed to replace wpa_supplicant, but when I removed those packages, connman failed with "Error /net/connman/technology/wifi: Not supported" - I need to dig around more with this.

amish · 2018-05-14 08:35:19

Few things to update in Wiki, (if currently possible)

1) Make is clear that wifi passwords and networks are persistent. iwctl remembers them somewhere so it does not require config file like in wpa_supplicant.
2) if iwctl remembers password somewhere - then where? how to remove the entry if needed?
3) Add a section on "How to change password / network?"
4) If I have 2 wifi networks - "How to assign priority?" OR does it always connect to "Last wifi device that it connected?"
5) what about those using systemd-networkd? (may be add note somewhere?)

Strangely there is no man page or documentation in package.

Also iwctl --help or iwctl -h do not work. (it tries to look for IWD instead)

I understand that this is a new thing and above may not be possible yet but asking just incase package maintainer knows - then same can be updated in wiki

PS: I have not tried the package yet.. but just putting up FAQ that may be included in wiki, Once I get time to test - I will try to find answers myself and update wiki if i get answers.

Last edited by amish (2018-05-14 08:41:28)

damjan · 2018-05-14 10:34:14

is there EAP-TTLS PAP support?

amish · 2018-05-14 11:55:23

amish wrote:

Few things to update in Wiki, (if currently possible)
...
PS: I have not tried the package yet.. but just putting up FAQ that may be included in wiki, Once I get time to test - I will try to find answers myself and update wiki if i get answers.

I implemented iwd on my system.

After testing few things here and there, I have updated wiki page to have answers to most of my own questions.

Please refer to wiki page.
https://wiki.archlinux.org/index.php/Iwd

Last edited by amish (2018-05-14 11:56:06)

Slithery · 2018-05-14 12:08:42

damjan wrote:

is there EAP-TTLS PAP support?

Yep. EAP-TTLS PAP support was confirmed as working as early as the 2016 systemd conference.

amish · 2018-05-14 13:04:03

It works with systemd-networkd without any changes. I would disable wpa_supplicant and test iwd for few days. If all seems fine then will make permanent switch over to it.

Trilby · 2018-05-14 13:35:36

I've not tried this out yet, but the apparent file-per-network configuration mechanism makes me skeptical whether there'd be an equivalent of this bit of wpa_supplicant.conf:

network={
        key_mgmt=NONE
}

This is great for laptops that move around as it will connect to any open network if nothing else is available. Can IWD do this (automatically like wpa_supplicant).

julesm · 2018-05-14 14:05:39

I tried iwd on one pc and it works great. However, I've got another pc with 2 wireless interfaces. I tried setting up iwd the same way - specifying which interface I wanted to use. It works fine until I have to reboot. When the pc restarts, I have to manually start the iwd.service (even though I had enabled it). And when I go into iwctl, I notice that both interfaces have connected to the network - not just the interface I specified during the configuration. Any ideas about how to limit iwd to one specific wireless interface???

amish · 2018-05-14 14:33:47

julesm wrote:

Any ideas about how to limit iwd to one specific wireless interface???

You need to modify service file.(or use systemd drop in file)

/usr/lib/iwd/iwd --help
...
        -i, --interfaces       Interfaces to manage

Probably package needs to have iwd@.service as well. Similar to wpa_supplicant@.service file

progandy · 2018-05-14 14:39:44

Trilby wrote:

I've not tried this out yet, but the apparent file-per-network configuration mechanism makes me skeptical whether there'd be an equivalent of this bit of wpa_supplicant.conf:
network={
        key_mgmt=NONE
}
This is great for laptops that move around as it will connect to any open network if nothing else is available. Can IWD do this (automatically like wpa_supplicant).

I believe you'd need an agent that does this. Automatic net selection should only connect to networks you have used before. In addition it seems like there is no way to set a preferred network if they are overlapping, you are at the mercy of the iwd logic.
https://git.kernel.org/pub/scm/network/ … ection.txt

jasonwryan wrote:

The only issue I encountered was that I found that removing wpa_supplicant and openssl-1.0 breaks connman. This doesn't seem right as IWD is supposed to replace wpa_supplicant, but when I removed those packages, connman failed with "Error /net/connman/technology/wifi: Not supported" - I need to dig around more with this.

Maybe it helps to disable the "wifi" plugin ("--noplugin=wifi"). If I read the connman code right, then the "wifi" plugin is using wpa_supplicant and the "iwd" plugin iwd.

Last edited by progandy (2018-05-14 14:44:51)

Trilby · 2018-05-14 14:42:30

Well that sounds like two deal breakers to me.

EDIT: no, make it just one deal breaker, as that prioritization logic sounds good to me. But just the same I'll stick with wpa_supplicant for as long as it is available.

Last edited by Trilby (2018-05-14 14:43:14)

julesm · 2018-05-14 14:46:33

amish wrote:

You need to modify service file.(or use systemd drop in file)
Probably package needs to have iwd@.service as well. Similar to wpa_supplicant@.service file

Cheers for this - will be interesting to see how iwd develops and matures - but so far so good!

Shibumi · 2018-05-14 14:56:24

amish wrote:

Few things to update in Wiki, (if currently possible)
1) Make is clear that wifi passwords and networks are persistent. iwctl remembers them somewhere so it does not require config file like in wpa_supplicant.
2) if iwctl remembers password somewhere - then where? how to remove the entry if needed?
3) Add a section on "How to change password / network?"
4) If I have 2 wifi networks - "How to assign priority?" OR does it always connect to "Last wifi device that it connected?"
5) what about those using systemd-networkd? (may be add note somewhere?)
Strangely there is no man page or documentation in package.

Hi,
I am the maintainer of the iwd package.

1) Yep, iwd remembers them and even prioritize them. For Priority it uses the level of encryption, the last time your client has been connected to this AP and different things. More Information can be found in the IWD documentation in their git repository: https://git.kernel.org/pub/scm/network/ … ection.txt

2) iwd stores the entries in /var/lib/iwd. For WPA2 the file is called: <your ESSID>.psk for enterprise wifi it's called <your enterprise ESSID>.8021x

3) mh No idea how to do this. But it's a good question. I will ask the devs on freenode in #iwd

4) See 1) for infos about priority

5) There is no real systemd-networkd support currently. I have opened a Feature Request for it, but I doubt that it will ever be implemented. (although it's a nice idea because IWD would fit perfectly via dbus in the systemd stack)

progandy wrote:

I believe you'd need an agent that does this

Since iwd version 0.3 there is an 'agent' inside of iwctl. So it should work without connman or networkmanager. That was one of the features that I have suggested after playing around with iwd 0.1 and 0.2.

julesm wrote:

I tried iwd on one pc and it works great. However, I've got another pc with 2 wireless interfaces. I tried setting up iwd the same way - specifying which interface I wanted to use. It works fine until I have to reboot. When the pc restarts, I have to manually start the iwd.service (even though I had enabled it). And when I go into iwctl, I notice that both interfaces have connected to the network - not just the interface I specified during the configuration. Any ideas about how to limit iwd to one specific wireless interface???

The service file is known as broken. I have reported this upstream and the devs are currently discussing this issue. They seem to wait for an own 'wireless.target' inside of systemd.. so this could take a while. Maybe I will think a bit and try to hack an own service file that will start up iwd. I will also take care about initializing the right interface.

Slithery wrote:

Yep. EAP-TTLS PAP support was confirmed as working as early as the 2016 systemd conference.

Ok this is odd. One of the iwd developers in #iwd told me that PAP is currently not supported, but maybe will be in the future (it should be easy to implement).

Trilby wrote:

network={
key_mgmt=NONE
}

No idea if this is supported. But I will ask the devs as well. Would be maybe a feature that somebody could think about, although I imagine that the devs will say this behaviour is known as insecure and they won't support it.

Thanks for testing IWD to everybody

amish · 2018-05-14 14:58:17

progandy wrote:

In addition it seems like there is no way to set a preferred network if they are overlapping, you are at the mercy of the iwd logic.
https://git.kernel.org/pub/scm/network/ … ection.txt

This is what is going to make me switch back to wpa_supplicant.

I have 2 wireless connection.

1 is cheap (unlimited) but non-portable and other is costly (pay per MB) but portable - used when on the move

Cheaper one is at some distance so signal strength is low
Costly one is nearby so signal strength is good.

I would not want it to connect to costly one unless cheaper one is out of range.

But looks like its not possible currently.

amish · 2018-05-14 15:11:19

Shibumi wrote:

amish wrote:
Few things to update in Wiki, (if currently possible)
1) Make is clear that wifi passwords and networks are persistent. iwctl remembers them somewhere so it does not require config file like in wpa_supplicant.
2) if iwctl remembers password somewhere - then where? how to remove the entry if needed?
3) Add a section on "How to change password / network?"
4) If I have 2 wifi networks - "How to assign priority?" OR does it always connect to "Last wifi device that it connected?"
5) what about those using systemd-networkd? (may be add note somewhere?)
Strangely there is no man page or documentation in package.

Shibumi wrote:

Hi,
I am the maintainer of the iwd package.
1) Yep, iwd remembers them and even prioritize them. For Priority it uses the level of encryption, the last time your client has been connected to this AP and different things. More Information can be found in the IWD documentation in their git repository: https://git.kernel.org/pub/scm/network/ … ection.txt
4) See 1) for infos about priority

See my previous post about why automatic priority may not always be desired.

Shibumi wrote:

3) mh No idea how to do this. But it's a good question. I will ask the devs on freenode in #iwd

In iwctl, first run:
[iwd]# known-networks forget testAP

then reconnect with new password!
[iwd]# device wlan0 connect testAP

Shibumi wrote:

5) There is no real systemd-networkd support currently. I have opened a Feature Request for it, but I doubt that it will ever be implemented. (although it's a nice idea because IWD would fit perfectly via dbus in the systemd stack)

systemd-networkd works without any changes. I am using it already!

Shibumi wrote:

The service file is known as broken. I have reported this upstream and the devs are currently discussing this issue. They seem to wait for an own 'wireless.target' inside of systemd.. so this could take a while. Maybe I will think a bit and try to hack an own service file that will start up iwd. I will also take care about initializing the right interface.

why not add iwd@.service file too in package? with:
ExecStart=/usr/lib/iwd/iwd -i %I

Rest would be same as current iwd.service.

pdc · 2018-05-14 15:13:05

I enabled iwd.service but it didn't start when I rebooted. The service file has WantedBy=network-pre.target, which isn't pulled in by any service I use. The systemd.special man page says

	network-pre.target
	    This passive target unit may be pulled in by services
	    that want to run before any network is set up, for
	    example for the purpose of setting up a firewall. All
	    network management software orders itself after this
	    target, but does not pull it in.

wpa_supplicant.service has WantedBy=multi-user.target

EDIT: I tried copying the service file to /etc/systemd/system/ and setting WantedBy=multi-user.target, then re-enabling it. This resulted in iwd running before udev had set the predicatble interface name.

Last edited by pdc (2018-05-14 18:15:01)

amish · 2018-05-14 15:13:55

@Shibumi - is it possible to disable debugging in package?

Its filling up systemd journal with lots of debug messages.

Thank you.

Also iwctl can be run by any NORMAL user - which is possibly security risk. (can connect / disconnect)

/usr/bin/iwctl should be set chmod 700 till upstream has some better protection.

PS: though chmod 700 is also not fool-proof as normal user can compile own iwctl.

Thank you

Last edited by amish (2018-05-14 15:21:33)

progandy · 2018-05-14 15:43:33

PS: though chmod 700 is also not fool-proof as normal user can compile own iwctl.

You should be able to roll your own DBus policy.

HalosGhost · 2018-05-14 15:47:19

Does anyone know if there are plans for iwctl commands to be passed on the cli (so the tool can be scripted)?

In the meantime, I'll be planning on sticking with wpa_supplicant for the sake of some of my tooling being dependent on scriptability.

It is really exciting to see something like this though!

All the best,

-HG

amish · 2018-05-14 16:04:21

progandy wrote:

PS: though chmod 700 is also not fool-proof as normal user can compile own iwctl.
You should be able to roll your own DBus policy.

But default should be to deny any change by normal user (even if connected to local tty). i.e. only root should be allowed.

Last edited by amish (2018-05-14 16:21:55)

jasonwryan · 2018-05-14 21:20:28

progandy wrote:

jasonwryan wrote:
The only issue I encountered was that I found that removing wpa_supplicant and openssl-1.0 breaks connman. This doesn't seem right as IWD is supposed to replace wpa_supplicant, but when I removed those packages, connman failed with "Error /net/connman/technology/wifi: Not supported" - I need to dig around more with this.
Maybe it helps to disable the "wifi" plugin ("--noplugin=wifi"). If I read the connman code right, then the "wifi" plugin is using wpa_supplicant and the "iwd" plugin iwd.

Sadly, that just disables wifi; so connman doesn't work with either iwd or wpa_supplicant

Shibumi · 2018-05-14 22:19:11

amish wrote:

@Shibumi - is it possible to disable debugging in package?
Its filling up systemd journal with lots of debug messages.
Thank you.
Also iwctl can be run by any NORMAL user - which is possibly security risk. (can connect / disconnect)
/usr/bin/iwctl should be set chmod 700 till upstream has some better protection.
PS: though chmod 700 is also not fool-proof as normal user can compile own iwctl.
Thank you

According to the IWD Developers this does only apply to physical users. IWD sets the Dbus policy at_console. This only applies for physical users with a valid user session.
Try to login via SSH remotely and try to execute iwctl... it shouldn't work.

amish · 2018-05-15 00:58:56

Yes but by default it should not allow at_console either. Because no administrator would want random user sitting on console to be able to update wifi.

For example schools, college, cyber cafe

Any random user can disconnect current wifi and make system connect to their own hotspot. And then monitor the traffic forever (till its detected)

Huge security risk.

Last edited by amish (2018-05-15 00:59:49)

amish · 2018-05-15 02:03:43

pdc wrote:

EDIT: I tried copying the service file to /etc/systemd/system/ and setting WantedBy=multi-user.target, then re-enabling it. This resulted in iwd running before udev had set the predicatble interface name.

I created a file like this:

/usr/lib/systemd/system/iwd.service.d/override.conf

[Unit]
Before=network.target
Wants=network.target

[Service]
StandardOutput=null
StandardError=null

[Install]
WantedBy=
WantedBy=multi-user.target

Then:

systemctl daemon-reload
systemctl restart iwd

PS: You may not want stdout/error to go to /dev/null

jagan605 · 2018-05-15 07:27:32

amish wrote:

Yes but by default it should not allow at_console either. Because no administrator would want random user sitting on console to be able to update wifi.
For example schools, college, cyber cafe
Any random user can disconnect current wifi and make system connect to their own hotspot. And then monitor the traffic forever (till its detected)
Huge security risk.

That usecase is specific and majority of people using wifi do it in their laptops. I use wpa_supplicant in the same way so this seems logical. People with those use cases can change the dbus policy to their liking but this seems like reasonable default for the rest of us.

Arch Linux

#1 2018-05-14 07:49:44

The IWD thread

#2 2018-05-14 08:35:19

Re: The IWD thread

#3 2018-05-14 10:34:14

Re: The IWD thread

#4 2018-05-14 11:55:23

Re: The IWD thread

#5 2018-05-14 12:08:42

Re: The IWD thread

#6 2018-05-14 13:04:03

Re: The IWD thread

#7 2018-05-14 13:35:36

Re: The IWD thread

#8 2018-05-14 14:05:39

Re: The IWD thread

#9 2018-05-14 14:33:47

Re: The IWD thread

#10 2018-05-14 14:39:44

Re: The IWD thread

#11 2018-05-14 14:42:30

Re: The IWD thread

#12 2018-05-14 14:46:33

Re: The IWD thread

#13 2018-05-14 14:56:24

Re: The IWD thread

#14 2018-05-14 14:58:17

Re: The IWD thread

#15 2018-05-14 15:11:19

Re: The IWD thread

#16 2018-05-14 15:13:05

Re: The IWD thread

#17 2018-05-14 15:13:55

Re: The IWD thread

#18 2018-05-14 15:43:33

Re: The IWD thread

#19 2018-05-14 15:47:19

Re: The IWD thread

#20 2018-05-14 16:04:21

Re: The IWD thread

#21 2018-05-14 21:20:28

Re: The IWD thread

#22 2018-05-14 22:19:11

Re: The IWD thread

#23 2018-05-15 00:58:56

Re: The IWD thread

#24 2018-05-15 02:03:43

Re: The IWD thread

#25 2018-05-15 07:27:32

Re: The IWD thread

Board footer