The IWD thread

verto6 · 2019-12-20 17:29:15

@CarbonChauvinist, thanks for your help. I went through the mailing list and checked that issue, but it apparently only applied to iwd 1.3. I couldn't connect to eduroam in iwd 1.2 neither.

I think I tried all possible variations of the credentials in the config file, nothing worked so far. Unfortunately, the debug messages in the journal are also really sparse.
It only tells me:

iwd[1566]: 4-Way handshake failed for ifindex: 2, reason: 15

I put

export IWD_PEAP_DEBUG=1

and the other 3 debug variables into my .bash_profile (and rebooted), but that didn't change nothing at all. Am I doing it wrong?

Regarding the DNS resolution: I switched to resolvconf in the /etc/iwd/main.conf and now I at least don't get the warning about the missing systemd-resolved service anymore.
I don't have the openresolv package installed though (which iwd expects as alternative to systemd-resolved), but I am happy with a static nameserver in /etc/resolv.conf. So DNS isn't an issue for me now. Only the eduroam connection doesn't work.

I am clearly missing something as there are almost no issues/complains about iwd and eduroam on google. Or the majority of the users is using iwd with a frontend like NM or connman or systemd-netword, which I try to avoid...

Kniyl · 2019-12-21 10:49:32

@verto6 Thanks for the pointers, but unfortunately this doesn't seem to be the case.

/usr/local/lib/systemd/network

and

/run/systemd/network

does not exist. There is the default

/usr/lib/systemd/network/80-iwd.link

available; and removing it gives me the interface name from the kernel back (as previously mentioned by others on this thread). Lastly, there is my

/etc/systemd/network/25-wireless.network

config which contains:

[Match]
Type=wlan

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=20

None of these feels like it could help with IWD's known networks.

progandy · 2019-12-21 12:56:11

verto6 wrote:

I put
export IWD_PEAP_DEBUG=1
and the other 3 debug variables into my .bash_profile (and rebooted), but that didn't change nothing at all. Am I doing it wrong?

The variable should be set in the systemd service file I think.
https://wiki.archlinux.org/index.php/Sy … p-in_files
https://wiki.archlinux.org/index.php/Sy … _a_service
https://coreos.com/os/docs/latest/using … units.html

Last edited by progandy (2019-12-21 12:57:36)

Kniyl · 2019-12-21 13:10:13

Interestingly enough, looking for solving this issue yielded the fact that IWD monitors the /var/lib/iwd folder for new files. So I went for an experiment:

# systemctl stop iwd.service
# systemctl start iwd.service
$ iwctl known-networks list
                                 Known Networks                                
--------------------------------------------------------------------------------
  Name                            Security   Hidden   Last connected     
--------------------------------------------------------------------------------
# touch /var/lib/iwd/*.*
$ iwctl known-networks list
                                 Known Networks                                
--------------------------------------------------------------------------------
  Name                            Security   Hidden   Last connected     
--------------------------------------------------------------------------------
  Visiteurs_CNES                  open                Dec 21,  1:01 PM   
  UPC0858175                      psk                 Dec 21,  1:01 PM   
  Moto_manu                       psk                 Dec 21,  1:01 PM   
  Le_terrier                      psk                 Dec 21,  1:01 PM   
  IKD_LG_Muret_Auto               open                Dec 21,  1:01 PM

Before the touch, I was disconnected, after the touch, autoconnect eventually kicked in.

So this all boils down to IWD somehow not reading /var/lib/iwd upon restarts; as a quick fix I added an

ExecStartPost=/usr/bin/bash -c 'touch /var/lib/iwd/*.*'

line in an override file and this seems to do the job, but I wonder if anything better can be done.

verto6 · 2019-12-22 14:06:18

progandy wrote:

The variable should be set in the systemd service file I think.

Thank you, I didn't think of that. I get some more debug infos now.

@Kniyl: Nice find and good workaround! At least until you find the real cause.

digitalone · 2019-12-23 15:21:35

Who is successfully using iwd?

I'm trying to use it sometimes, but keep getting random disconnections.

wpa_supplicant is far more robust than iwd. I noticed that on 5 GHz where my laptop gets a bad signal, on wpa_supplicant the bandwidth is only reduced at very minimum, but the connection stays on, while on iwd it goes down. Sometimes it happens also on 2,4 GHz while never happened with wpa_supplicant.

chr0mag · 2020-01-07 05:32:20

Has anyone managed to get iwd working with a WPA3/SAE enabled AP? I've got a hostapd instance running with WPA3/SAE configured (correctly -- I can connect using WPA3/SAE from a different device) but can't get iwd to connect. I see:

iwd[4093]: Received Deauthentication event, reason: 2, from_ap: true

...in the iwd journal when I attempt to associate with the AP.

Searching iwd git for "wpa3" and "sae" return many commits and "WPA3-Personal (SAE)" is mentioned in *man 5 iwd.network* -- all of which suggested that there is some level of support for this so I'm curious if anyone else has attempted and had success.

chr0mag · 2020-01-12 20:49:58

chr0mag wrote:

Has anyone managed to get iwd working with a WPA3/SAE enabled AP? I've got a hostapd instance running with WPA3/SAE configured (correctly -- I can connect using WPA3/SAE from a different device) but can't get iwd to connect. I see:
iwd[4093]: Received Deauthentication event, reason: 2, from_ap: true
...in the iwd journal when I attempt to associate with the AP.
Searching iwd git for "wpa3" and "sae" return many commits and "WPA3-Personal (SAE)" is mentioned in *man 5 iwd.network* -- all of which suggested that there is some level of support for this so I'm curious if anyone else has attempted and had success.

After enabling more logging/debugging I see the following during the failed WPA3 connection attempt:
hostapd journal

Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 IEEE 802.11: authentication OK (open system)
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 MLME: MLME-AUTHENTICATE.indication(34:f3:9a:bc:84:e1, OPEN_SYSTEM)
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 MLME: MLME-DELETEKEYS.request(34:f3:9a:bc:84:e1)
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 IEEE 802.11: authenticated
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 IEEE 802.11: association OK (aid 2)
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 IEEE 802.11: associated (aid 2)
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 MLME: MLME-ASSOCIATE.indication(34:f3:9a:bc:84:e1)
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 MLME: MLME-DELETEKEYS.request(34:f3:9a:bc:84:e1)
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 IEEE 802.11: binding station to interface 'wifi0'
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: event 1 notification
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: start authentication
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 IEEE 802.1X: unauthorizing port
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: sending 1/4 msg of 4-Way Handshake
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: received EAPOL-Key frame (2/4 Pairwise)
Jan 11 18:44:49 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: invalid MIC in msg 2/4 of 4-Way Handshake
Jan 11 18:44:50 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: EAPOL-Key timeout
Jan 11 18:44:50 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: sending 1/4 msg of 4-Way Handshake
Jan 11 18:44:50 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: received EAPOL-Key frame (2/4 Pairwise)
Jan 11 18:44:50 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: invalid MIC in msg 2/4 of 4-Way Handshake
Jan 11 18:44:51 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: EAPOL-Key timeout
Jan 11 18:44:51 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: sending 1/4 msg of 4-Way Handshake
Jan 11 18:44:51 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: received EAPOL-Key frame (2/4 Pairwise)
Jan 11 18:44:51 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: invalid MIC in msg 2/4 of 4-Way Handshake
Jan 11 18:44:52 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: EAPOL-Key timeout
Jan 11 18:44:52 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: sending 1/4 msg of 4-Way Handshake
Jan 11 18:44:52 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: received EAPOL-Key frame (2/4 Pairwise)
Jan 11 18:44:52 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: invalid MIC in msg 2/4 of 4-Way Handshake
Jan 11 18:44:53 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: EAPOL-Key timeout
Jan 11 18:44:53 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: PTKSTART: Retry limit 4 reached
Jan 11 18:44:53 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 WPA: event 3 notification
Jan 11 18:44:53 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 IEEE 802.1X: unauthorizing port
Jan 11 18:44:53 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 MLME: MLME-DEAUTHENTICATE.indication(34:f3:9a:bc:84:e1, 2)
Jan 11 18:44:53 apu2c4 hostapd[16489]: wifi0: STA 34:f3:9a:bc:84:e1 MLME: MLME-DELETEKEYS.request(34:f3:9a:bc:84:e1)

iwd run with -d option

src/network.c:network_connect() 
src/network.c:network_connect_psk() ask_passphrase: true
src/agent.c:agent_request_passphrase() agent 0x5642e2d8eef0 owner :1.1180 path /agent/5418
src/agent.c:agent_send_next_request() send request to :1.1180 /agent/5418
src/agent.c:agent_receive_reply() agent 0x5642e2d8eef0 request id 75
src/network.c:passphrase_callback() result 0
src/station.c:station_enter_state() Old State: autoconnect_quick, new state: connecting
src/scan.c:scan_periodic_stop() Stopping periodic scan for wdev 1
src/scan.c:scan_cancel() Trying to cancel scan id 1 for wdev 1
src/netdev.c:netdev_mlme_notify() MLME notification New Station(19)
src/station.c:station_netdev_event() Associating
src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
src/netdev.c:netdev_authenticate_event() 
src/netdev.c:netdev_mlme_notify() MLME notification Associate(38)
src/netdev.c:netdev_associate_event() 
src/netdev.c:netdev_mlme_notify() MLME notification Connect(46)
src/netdev.c:netdev_connect_event() 
src/netdev.c:netdev_link_notify() event 16 on ifindex 3
src/netdev.c:netdev_link_notify() event 16 on ifindex 3
src/netdev.c:netdev_link_notify() event 16 on ifindex 3
src/netdev.c:netdev_link_notify() event 16 on ifindex 3
src/netdev.c:netdev_unicast_notify() Unicast notification 129
src/netdev.c:netdev_control_port_frame_event() 
src/eapol.c:eapol_handle_ptk_1_of_4() ifindex=3
src/netdev.c:netdev_control_port_frame_cb() 0
src/netdev.c:netdev_unicast_notify() Unicast notification 129
src/netdev.c:netdev_control_port_frame_event() 
src/eapol.c:eapol_handle_ptk_1_of_4() ifindex=3
src/netdev.c:netdev_control_port_frame_cb() 0
src/netdev.c:netdev_unicast_notify() Unicast notification 129
src/netdev.c:netdev_control_port_frame_event() 
src/eapol.c:eapol_handle_ptk_1_of_4() ifindex=3
src/netdev.c:netdev_control_port_frame_cb() 0
src/netdev.c:netdev_unicast_notify() Unicast notification 129
src/netdev.c:netdev_control_port_frame_event() 
src/eapol.c:eapol_handle_ptk_1_of_4() ifindex=3
src/netdev.c:netdev_control_port_frame_cb() 0
src/netdev.c:netdev_link_notify() event 16 on ifindex 3
src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
src/netdev.c:netdev_mlme_notify() MLME notification Deauthenticate(39)
src/netdev.c:netdev_deauthenticate_event() 
src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48)
src/netdev.c:netdev_disconnect_event() 
Received Deauthentication event, reason: 2, from_ap: true
src/station.c:station_disconnect_event() 3
src/station.c:station_connect_cb() 3, result: 3
src/station.c:station_disassociated() 3
src/station.c:station_enter_state() Old State: connecting, new state: disconnected

A bit of searching suggests that WPA: invalid MIC in msg 2/4 of 4-Way Handshake indicates an incorrect passphrase which is curious since this passphrase is WPA3/SAE specific and works successfully from my iPhone. (hostapd allows specifying an 'sae_passphrase' for WPA3-Personal that is different from the 'wpa_passphrase' used for WPA2 -- this is how I am confirming whether clients can connect using WPA3/SAE.)

dilyn · 2020-01-19 23:03:15

goether wrote:

I actually have the same problem with exact specs (Macbook pro 11,3 with broadcom-wl-dkms) I could not get iwd to work so at the moment I'm using NetworkManager
tagenk wrote:
Any update on this for anyone "in the know"? I am having this exact issue. I am running a MacBook Pro with the broadcom-wl-dkms package. I am also using the iwd 1.0 package. Thanks!
Moo-Crumpus wrote:
... and what about this? Weird.
                                
[iwd]# station wlan0 show
                                 Station: wlan0                                
--------------------------------------------------------------------------------
  Settable  Property            Value                                          
--------------------------------------------------------------------------------
            Scanning            no
            State               disconnected

[iwd]# station wlan0 scan 
Argument type is wrong             

After trying all sorts of things to try and get it to work and reading docs for everything under the sun, I shelved the endeavor and settled on systemd-networkd.
I tried iwd again yesterday to see if anything had changed, and somehow it all works quite easily now! Unsure what all changed, but very little actual setup was required to make iwd work - not much beyond enabling and starting the service.
I'm using Broadcom-wl-dkms and the latest linux-macbook kernel, running iwd 1.4-1. Have been able to connect to networks without any issues so far.

Last edited by dilyn (2020-01-19 23:03:53)

jayache80 · 2020-01-28 01:16:04

My experience has been that, if the iwd service is enabled in systemd, at boot time iwd will start up but it will not working properly; trying to list the devices won't cough up any devices, and because of that I can't connect anything. However, if I leave iwd disabled, and manually start it, it has no problem; it can list wireless devices fine, it shows networks when I scan, and I have no problem connecting.

So, I have my .xinitrc call a script that starts up iwd and connects to my wireless network, and it works great, every boot. It even goes to the next "known" network if the primary known network isn't available. That's probably a hack, and I should figure out why iwd doesn't work properly if enabled in systemd. I believe it is simply starting too early before my wireless driver(s) are initialized, and can't recover.

Anywho, maybe I'm missing something, but I can't get iwctl to tell me *which* wireless network I'm connected to.

[iwd]# station wlan0 show 
                                 Station: wlan0                               *
--------------------------------------------------------------------------------
  Settable  Property            Value                                          
--------------------------------------------------------------------------------
            Scanning            no
            State               connected

connected to what?

The only thing I know to do is this, in a regular shell:

iw dev wlan0 info

and that will spit some info out including the SSID of the network I'm connected to.

My specs:
IWD version 1.4
5.4.14-arch1-1
mid-2009 macbook pro (5,5)

Zod · 2020-01-28 02:40:47

[iwd]# station wlan0 get-networks
                               Available networks
--------------------------------------------------------------------------------
    Network name                    Security  Signal
--------------------------------------------------------------------------------
  > ATT65jGh9Q_5ghz                 psk       ****

[iwd]# station wlan0 show
                                 Station: wlan0
--------------------------------------------------------------------------------
  Settable  Property            Value
--------------------------------------------------------------------------------
            Scanning            no
            State               connected

[iwd]# station wlan0 scan


[iwd]# station wlan0 get-networks
                               Available networks                             *
--------------------------------------------------------------------------------
    Network name                    Security  Signal
--------------------------------------------------------------------------------
    ATT65jGh9Q                      psk       ****
    MotoVAP_M91348SA12BV            psk       ****
    ATT8tzy4pI 2.4                  psk       ****
  > ATT65jGh9Q_5ghz                 psk       ****

The little greater then symbol denotes the network I am connected to.

narutowindy · 2020-05-18 02:37:34

Hi everyone, i was using iwd recently, i would like to know if connection drops, it reconnects to the any wifi available??i

GeneArch · 2020-06-23 23:52:16

Anyone got ideas to help - I was happily using iwd starting way back in 2019 - all was working fine. At some point i got the following issue, which seems to be dbus related.

If i start iwd executable manually by running /usr/lib/iwd/iwd then everything works normally.

However if I start it using "systemctl start iwd" then it doesn't actually run and because it's not running, iwctl hangs waiting for dbus connection.

Ok - so when starting via systemd, i see the following in the system journal:

: Wireless daemon version 1.8
: Loaded configuration from /etc/iwd/main.conf
: station: Network configuration is disabled.
: Module hotspot failed to start: -2
: D-Bus disconnected, quitting...
: iwd.service: Succeeded.

systemd thunks all is well and yet iwd is not running.

What stumps me is this was working fine for months, sometime in march or april of this year it stopped. iwd was around version 1.5 or so maybe.
At the time I tried rolling back to earlier versions to no avail. Tried building from git to no avail. Problem remains - I assume i've managed to do "something" but no idea where to look.
All testing was done by first ensuring nothing else like wpa_supplicant or iwd or network manager is running.

Summarizing, if iwd executable run directly then everything works fine. If started via systemctl then it doesn't start up and the log shows a dbus error.
I'm running this (and have been) on fully updated kde plasma desktop.

i sure could use some help in getting it to start via systemd.

Anyone got any ideas

thanks!!

Last edited by GeneArch (2020-06-24 12:14:06)

GeneArch · 2020-07-03 15:00:07

Solved - i deleted /var/lib/iwd/hotspot - and restarted - not iwd works from systemd as well as standalone. The hotspot dir is recreated by iwd - so perhaps something was off on permissions.

gothmog123 · 2020-07-17 16:21:56

I have a weird question. When using IWD standalone without a networkmanager and with its built in dhcp client, I am getting amazing never seen before bandwidth. But when trying to use any network manager with IWD the bandwidth decreases by around 30%.

I'm guessing IWD uses some extra magic that optimizes wifi connections.

Anyone have any idea what that could be? If not I am forced to use IWD standalone forever, as the connection is so amazing.

bjo · 2020-07-17 20:14:50

Interesting observation. I connected now directly with iwd and without NetworkManager and got a 780Mbit connection, while with NM it was mostly stagnated around 370Mbit.

Trilby · 2020-07-17 21:48:48

The above posts piqued my curiosity so I finally tried iwd. First off, it annoyed the hell out of me in a couple ways. First, the service failed with no useful error output. So I tried running the iwd binary directly, and that gave a long error output saying my kernel (stock arch kernel) did not support features required by iwd. It turns out this wasn't quite true. When I realized I hadn't rebooted in a bit and my on-disk and running kernel versions were different, I rebooted and tried again.

At this point annoyance number 2: the iwd package apparently comes with something that prevents the predictable interface naming and reverts two the 'old' style wlan0. The wiki mentions that users may want to set this up themselves, there is no mention of the package doing this "for" the user without their consent (and this is just from having the package installed, not enabling a service). So that kinda' pissed me off.

But then I tested:
wpa_supplicant + dhcpcd first: 3.44 Mbps / 22.47 Mbps (down/up).
iwd (w/ it's dhcp): 140.74 Mbps / 20.38 Mbps

Holy hell - that's a 40-fold increase in download speed. Surely that has to be a fluke! So I tried testing again by disabling iwd to try to use wpa_supplicant / dhcpcd again. This is when I became really pissed at iwd. Upon disabling the service, my wireless interface was gone! I flailed around for a bit, then rebooted to run another set of tests. The numbers differed quite a bit from the first tests, but still a notable advantage of iwd:

wpa_supplicant + dhcpcd first: 4.06 Mbps / 21.15 Mbps (down/up).
iwd (w/ it's dhcp): 54.15 Mbps / 22.00 Mbps

Then when iwd was disabled, my interface was gone again. I tried modprobing my drivers - no joy. I rmmodded a few, then remodprobed, and the interface was back, so I could do a proper reversal test ... and here comes the really interesting data:

wpa_supplicant + dhcpcd first: 18.09 Mbps / 22.61 Mbps (down/up).
iwd (w/ it's dhcp): 16.24 Mbps / 21.90 Mbps

Now IWD had *no* advantage. In fact it did worse (negligibly so, certainly just noise in the data, but it definitely didn't do better). Then it occurred to me: iwd couldn't run until it loaded kernel modules that were not in use by wpa_supplicant / dhcpcd. But once those additional kernel modules were in use, wpa_supplicant /dhcpcd was just as fast as iwd.

So iwd connections are not faster than wpa_supplicant / dhcpcd connections, but a kernel module that is required by iwd does drastically boost wireless connection performance. I'd like to next track down which module that is and confirm that it is sufficient to benefit wpa_supplicant / dhcpcd in the total absence of iwd.

EDIT:
I found the modules below to be loaded only after using iwd and not on a clean boot without iwd. I also confirmed that on a fresh boot with no use of iwd, modprobing each of these was sufficient to get the massive boost in download speed even with wpa_supplicant / dhcpcd: 44.14 Mbps / 21.79 Mbps.

The modules:

af_alg
algif_aead
algif_hash
algif_skcipher
arc4
cbc
cmac
des_generic
ecb
libdes
md4

Last edited by Trilby (2020-07-17 21:56:10)

gothmog123 · 2020-07-18 07:17:10

Trilby wrote:

The above posts

Interesting. What about the difference in speed between just using iwd's own dhcp client vs network managers with iwd? Is it also caused by modules? Is it safe to just have all those modules force loaded all time?

Trilby · 2020-07-18 11:26:42

I don't use network manager - I thought it used dhcpcd, but based on it's dependencies that may not be the case.

But just the same, if my analysis is correct, then loading the modules is sufficient to get the speed boost regardless of which management/connection tools you use. Given that loading the modules and running wpa_supplicant + dhcpcd in the absence of iwd was sufficient to see the boost, I highly doubt adding iwd for the connection would reduce the benefit.

But if you have networkmanager and know how to use it, you are in a much better position to test it directly yourself.

Of course this will all also be influenced by a ceiling effect of what speed you get from your service provider. For me this was the big surprise: I never imagined the wlan connection between my computer and router would be the bandwidth limiting jump in my connection to the broader internet.

As to whether it's safe to have those modules loaded - I don't know all of what they do - but there can be no more danger in having them loaded and not using iwd that there would be in having them loaded and using iwd.

Keep in mind too, this was the list of differing modules on my hardware determined simply by comparing lsmod on two boots, one using iwd, the other not. It's possible iwd would require different modules on different hardware. So, test for yourself to see the difference in module lists on your own system.

Last edited by Trilby (2020-07-18 11:31:33)

ondoho · 2020-07-18 14:30:41

Trilby wrote:

I'd like to next track down which module that is and confirm that it is sufficient to benefit wpa_supplicant / dhcpcd in the total absence of iwd.
EDIT:
I found the modules below to be loaded only after using iwd and not on a clean boot without iwd. I also confirmed that on a fresh boot with no use of iwd, modprobing each of these was sufficient to get the massive boost in download speed even with wpa_supplicant / dhcpcd: 44.14 Mbps / 21.79 Mbps.
The modules:
af_alg
algif_aead
algif_hash
algif_skcipher
arc4
cbc
cmac
des_generic
ecb
libdes
md4

Very nice!
Are you still tracking down the module(s) responsible or is this your final list?

Trilby · 2020-07-18 15:09:00

I know that list is sufficient (at least on my hardware) so that's good enough for me even if a couple of them may not be necessary. So no - I'm done exploring.

gothmog123 · 2020-07-19 19:45:05

So if IWD is used with a networkmanager it doesn't load those modules?!

Trilby · 2020-07-19 19:56:23

Ah .. what?

IWD loads some modules. The list above are the modules it loads on my system. Period.

If IWD is used with it's own dhcp client, it loads these modules. If IWD is used with dhcpcd, it loads these modules. If IWD is used while you eat a popsicle, it loads these modules. If IWD is used on a Tuesday it loads these modules. I'm quite confident that if IWD is used with Network manager, it would certainly load the modules as well.

gothmog123 · 2020-07-19 20:02:16

Sorry I'm just thinking out loud. Why could it be slower for me then, when I'm using it with connman or networkmanager?

Trilby · 2020-07-19 20:51:11

Oh sorry, I missread your initial report that IWD+Networkmanager was slower than IWD alone. That would suggest my interpretation may be incorrect. We need more data points to make reasonable inferences - I can only say what happened on my system.

Have you tried IWD with dhcpcd or dhclient?

Arch Linux

#201 2019-12-20 17:29:15

Re: The IWD thread

#202 2019-12-21 10:49:32

Re: The IWD thread

#203 2019-12-21 12:56:11

Re: The IWD thread

#204 2019-12-21 13:10:13

Re: The IWD thread

#205 2019-12-22 14:06:18

Re: The IWD thread

#206 2019-12-23 15:21:35

Re: The IWD thread

#207 2020-01-07 05:32:20

Re: The IWD thread

#208 2020-01-12 20:49:58

Re: The IWD thread

#209 2020-01-19 23:03:15

Re: The IWD thread

#210 2020-01-28 01:16:04

Re: The IWD thread

#211 2020-01-28 02:40:47

Re: The IWD thread

#212 2020-05-18 02:37:34

Re: The IWD thread

#213 2020-06-23 23:52:16

Re: The IWD thread

#214 2020-07-03 15:00:07

Re: The IWD thread

#215 2020-07-17 16:21:56

Re: The IWD thread

#216 2020-07-17 20:14:50

Re: The IWD thread

#217 2020-07-17 21:48:48

Re: The IWD thread

#218 2020-07-18 07:17:10

Re: The IWD thread

#219 2020-07-18 11:26:42

Re: The IWD thread

#220 2020-07-18 14:30:41

Re: The IWD thread

#221 2020-07-18 15:09:00

Re: The IWD thread

#222 2020-07-19 19:45:05

Re: The IWD thread

#223 2020-07-19 19:56:23

Re: The IWD thread

#224 2020-07-19 20:02:16

Re: The IWD thread

#225 2020-07-19 20:51:11

Re: The IWD thread

Board footer