The IWD thread

alu1 · 2019-10-31 16:10:53

yep. iwd1.0-3 fixes it - weird.

tagenk · 2019-11-04 17:18:12

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

narutowindy · 2019-11-05 02:14:09

i have dell precison 5540 ,Intel® Wi-Fi 6 AX200 , i'm having lots of disconnection issues with iwd, or intel drivers ,or even dhcpd , connection keep getting dropped!! i used ubuntu before installing arch, there was no such disconnections. please help me thorugh the debugging this annoying issue.

thank you.

ewaller · 2019-11-05 02:50:07

narutowindy wrote:

i have dell precison 5540 ,Intel® Wi-Fi 6 AX200 , i'm having lots of disconnection issues with iwd, or intel drivers ,or even dhcpd , connection keep getting dropped!! i used ubuntu before installing arch, there was no such disconnections. please help me thorugh the debugging this annoying issue.
thank you.

Welcome to the forums. It has been pointed out that this post may not belong in this thread. I don't think this was a thread hijack attempt; but why do you feel this has to do with IWD?
I would guess this is a case of multiple things fighting for control of the wireless interface. Please search these forums for threads having to do with disconnects and multiple things that control the WiFi causing conflicts. If this is not the case, please provide an argument as to why you suspect IWD. Otherwise, it would make sense to split this post to its own thread.

glitsj16 · 2019-11-05 11:42:08

patrickmcnamarra wrote:

Since 0.20, iwd is renaming my network interfaces despite the "use_default_interface=true" option in my config. If anyone knows a fix, it would be appreciated.

There have been a few upstream changes lately related to renaming network interfaces. Here's what I observed with iwd 1.0-3. First, the arch linux package follows upstream by not providing /etc/iwd/main.conf anymore. Secondly, upstream now provides /usr/lib/systemd/network/80-iwd.link. I could only get IWD to keep my wlp2s0 interface name by removing the 80-iwd.link AND by setting UseDefaultInterface=true in /etc/iwd/main.conf. Note the changed syntax, it now uses CamelCasing instead of the underscore format: see here. Hope this helps.

patrickmcnamara · 2019-11-05 17:08:39

glitsj16 wrote:

patrickmcnamarra wrote:
Since 0.20, iwd is renaming my network interfaces despite the "use_default_interface=true" option in my config. If anyone knows a fix, it would be appreciated.
There have been a few upstream changes lately related to renaming network interfaces. Here's what I observed with iwd 1.0-3. First, the arch linux package follows upstream by not providing /etc/iwd/main.conf anymore. Secondly, upstream now provides /usr/lib/systemd/network/80-iwd.link. I could only get IWD to keep my wlp2s0 interface name by removing the 80-iwd.link AND by setting UseDefaultInterface=true in /etc/iwd/main.conf. Note the changed syntax, it now uses CamelCasing instead of the underscore format: see here. Hope this helps.

Thank you. Through your post and the wiki I finally decided to fix this today.

I don't really understand why iwd wants to rename my interfaces in the first place, especially when it clearly isn't necessary.

romstor · 2019-11-06 19:28:21

patrickmcnamara wrote:

I don't really understand why iwd wants to rename my interfaces in the first place, especially when it clearly isn't necessary.

In iwd - State of the Union on YouTube Marcel Holtmann answers this to some degree (link to the exact part when he is asked this question - 19:08). I also wish there was a blog post or a paragraph on Arch Wiki about this. I still have this issue with iwd 1.03 and systemd-networkd - i don't think it is going away any time soon. Their eventual plan is to manage wireless devices in iwd.

Last edited by romstor (2019-11-07 19:20:44)

thx1138 · 2019-11-07 18:48:26

The location that I see for this question and answer about renaming interfaces in iwd - State of the Union on YouTube is actually at 19:08 of 27:02.

romstor · 2019-11-07 19:23:23

thx1138 wrote:

The location that I see for this question and answer about renaming interfaces in iwd - State of the Union on YouTube is actually at 19:08 of 27:02.

That is correct - thank you thx1138! The link above is correct - I just assumed that "&t=1148" in YouTube URL stands for 11:48, but it is 1148 seconds from the beginning of the video. I updated the post.

Last edited by romstor (2019-11-07 19:25:08)

goether · 2019-11-16 23:30:24

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

Mortimer Houghton · 2019-11-17 15:56:59

Mortimer Houghton wrote:

Does anyone know how to get IWD to play nice with linux-5.3.*? When I use it with anything higher than 5.2.14 it fails to discover any networks. This is the error I am getting:

Oct 29 18:06:51 HP-255-G6 iwd[499]: Wireless daemon version 0.23
Oct 29 18:06:51 HP-255-G6 iwd[499]: Loaded configuration from /etc/iwd/main.conf
Oct 29 18:06:51 HP-255-G6 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=iwd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 18:06:51 HP-255-G6 kernel: audit: type=1130 audit(1572390411.625:20): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=iwd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 29 18:06:51 HP-255-G6 iwd[499]: Wiphy: 0, Name: phy0
Oct 29 18:06:51 HP-255-G6 iwd[499]:         Permanent Address: c0:b6:f9:af:47:c7
Oct 29 18:06:51 HP-255-G6 iwd[499]:         Bands: 2.4 GHz 5 GHz
Oct 29 18:06:51 HP-255-G6 iwd[499]:         Ciphers: CCMP TKIP
Oct 29 18:06:51 HP-255-G6 iwd[499]:         Supported iftypes: ad-hoc station ap p2p-client p2p-go p2p-device
Oct 29 18:06:52 HP-255-G6 audit[499]: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 pid=499 comm="iwd" exe="/usr/lib/iwd/iwd" sig=11 res=1
Oct 29 18:06:52 HP-255-G6 iwd[499]: Received error during CMD_TRIGGER_SCAN: Input/output error (5)
Oct 29 18:06:52 HP-255-G6 systemd[1]: iwd.service: Main process exited, code=dumped, status=11/SEGV
Oct 29 18:06:52 HP-255-G6 systemd[1]: iwd.service: Failed with result 'core-dump'.
Oct 29 18:06:52 HP-255-G6 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=iwd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Oct 29 18:06:52 HP-255-G6 systemd-coredump[777]: Process 499 (iwd) of user 0 dumped core.
                                                 #0  0x000055e7ad3ab733 n/a (iwd)
                                                 #1  0x000055e7ad3ac6c7 n/a (iwd)
                                                 #7  0x000055e7ad38f662 n/a (iwd)
                                                 #9  0x000055e7ad38fdce n/a (iwd)

Adapter:

Intel Dual Band Wireless-AC 3168NGW [Stone Peak]

This problem was resolved sometime after IWD-1.0 (maybe 1.0-3).

cootcraig · 2019-12-10 12:00:02

I am new to Arch installation and would like to set up my laptop wireless with iwd. I posted outside this thread, but perhaps it belongs here as I would like iwd specific help.
https://bbs.archlinux.org/viewtopic.php?id=251278
Index» Networking, Server, and Protection» Broadcom iwd systemd-networkd fail

I have made another attempt, turning on these services
systemctl start/enable systemd-networkd.service
systemctl start/enable ifplugd@eth0.service
systemctl stat/enable iwd.service
systemctl start/enable systemd-resolved.service

A similar fail where using iwctl the wireless hardware successfully scans for networks, but the connect fails.

CarbonChauvinist · 2019-12-14 17:36:05

Since updating to iwd 1.3-1 it seems that I'm no longer getting proper name resolution, downgrading back to iwd 1.2-1 resolves the issue (pun intended).

I'm using iwd + systemd-resolved (without systemd-networkd, having iwd handle the network) here's my iwd/main.conf

$ cat /etc/iwd/main.conf
[General]
EnableNetworkConfiguration=true

[Network]
NameResolvingService=systemd

and my /etc/resolv.conf

$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
...
nameserver 127.0.0.53
options edns0

Here's my enabled services in case it's relevant:

$ systemctl list-unit-files --state enabled
UNIT FILE                              STATE
autovt@.service                        enabled
dbus-org.freedesktop.resolve1.service  enabled
dbus-org.freedesktop.timesync1.service enabled
display-manager.service                enabled
getty@.service                         enabled
iwd.service                            enabled
sddm.service                           enabled
systemd-resolved.service               enabled
systemd-timesyncd.service              enabled
ufw.service                            enabled
remote-fs.target                       enabled
fstrim.timer                           enabled

12 unit files listed.

And here's the link to the journal for iwd 1.3-1, limited to iwd's PID, when I'm unable to resolve.

There's nothing obviously amiss when on 1.3-1, i.e. no errors in journal, both iwd and systemd-resolved show no errors when looking at the status etc., except for the fact name resolution is broken. I can ping 8.8.8.8, but not google.com for instance.

For even more good measure, here's an strace when trying to ping on iwd 1.3-1 and getting the failure, and here's an strace when trying to use `resolvectl query google` on iwd 1.3-1 which also fails.

I'm at a loss -- any thoughts?

Last edited by CarbonChauvinist (2019-12-14 19:56:08)

glitsj16 · 2019-12-14 19:00:52

@CarbonChauvinist Have you checked that your /etc/resolv.conf is symlinked to /run/systemd/resolve/stub-resolv.conf? According to the systemd-resolved wiki page that is the recommended way to use systemd-resolved. Also, what is the output from 'resolvectl status'?

CarbonChauvinist · 2019-12-14 19:55:17

@glitsj16 - thanks. Yes /etc/resolv.conf was symlinked correctly. Your question on resolvectl status output led me to relook, I thought they were the same between 1.2-1 and 1.3-1, but there was a difference.

With 1.3-1 looking at the local link:

...
Link 4 (wlan0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: no
...
  Current DNS Server: 192.168.1.1
         DNS Servers: 192.168.1.1
          DNS Domain: ~lan

The DefaultRoute setting is set to "no" instead of "yes" when using iwd 1.3-1 for some reason (no change from me with systemd-resolved configuration). Also the DNS Doman: ~lan was added when using iwd 1.3-1.

I've since used resolvectl to set the DefaultRoute setting to "yes":

# resolvectl default-route wlan0 1

and now dns appears to be working as expected (though it's not a permanent change).

So I wonder what in iwd changed that causes systemd-resolved to treat the link differently WRT how they handle the DefaultRoute settings (the logic of which, AFAICT, is quoted below from freedesktop)?

The "DNS default route" option is a boolean setting configurable with resolvectl or in .network files. If not set, it is implicitly determined based on the configured DNS domains for a link: if there's any route-only domain (not matching "~.") it defaults to false, otherwise to true.
Effectively this means: in order to preferably route all DNS queries not explicitly matched by search/route-only domain configuration to a specific link, configure a "~." route-only domain on it. This will ensure that other links will not be considered for the queries (unless they too carry such a route-only domain). In order to route all such DNS queries to a specific link only in case no other link is preferable, then set the "DNS default route" option for the link to true, and do not configure a "~." route-only domain on it. Finally, in order to ensure that a specific link never receives any DNS traffic not matching any of its configured search/route-only domains, set the "DNS default route" option for it to false.

Edit -- Figured out what was happening. I'm using a tomato based router and had set the "domain name" to "lan" under the router identification tab. For some reason now with iwd 1.3, that means that the dns domain ~lan is now included when looking at my resolvectl output (I assume it's this resolve: Add systemd-resolved domain name installer commit though).

And based on the quote I have above, that changes the way the DefaultRoute setting is handled causing it to default to "false". I couldn't figure out a way to override the DefaultRoute setting as I'm not using systemd-networkd so I can't add settings in a .network file ?and it doesn't appear to be a value that's accessible to change in systemd-resolved unit file or override either?.

I ended up just taking out the lan domain designation from my router setup and now when looking at resolvectl output the domain ~lan is no longer added and I have the expected behavior with the DefaultRoute value.

Last edited by CarbonChauvinist (2019-12-15 14:29:11)

mbalajew · 2019-12-15 18:09:06

Hi everyone, just wanted to chime in and report that I'm having the same issue as @CarbonChauvinist.

Just like @CarbonChauvinist, I am also running iwd + systemd-resolved (with symlink to /etc/resolv.conf) with a vanilla iwd configuration; i.e. only adding EnableNetworkConfiguration=true.

However, unlike @CarbonChauvinist, the output of resolvectl on my system is slightly different:

    ---
    Link 4 (wlan0)
        Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
        DefaultRoute setting: no
    ----
    Current DNS Server: 75.75.75.75
        DNS Servers: 75.75.75.75
                              75.75.76.76
        DNS Domain: ~hsd1.co.comcast.net

But, just like @CarbonChauvinist, setting DefaultRoute to "yes" seems to fix everything:

 # resolvectl default-route wlan0 1

So, in conclusion, does anyone have idea what this could be? a bug? should we submit a bug report?

CarbonChauvinist · 2019-12-15 21:12:39

@mbalajew IWD has made a change and now appends any dns domains assigned from your dhcp server to the link.

Appending the domain, in your case ~hsd1.co.comcast.net in my case ~lan, changes the way systemd-resolved assigns the DefaultRoute value to the link -- it's no longer true but false.

if there's any route-only domain (not matching "~.") [DefaultRoute] defaults to false, otherwise to true

If there's no default route assigned to any link then none of the dns queries will actually go out. Manually changing the DefaultRoute value using resolvectl is only a temporary change and will not survive reboots and/or suspend cycles.

I don't know the way to override the DefaultRoute value permanently per iwd link. So I opted to instead remove the domain designation in my router/dhcp configuration for now.

Last edited by CarbonChauvinist (2019-12-15 22:44:35)

mbalajew · 2019-12-16 02:35:52

@CarbonChauvinist, thanks for the reply. So, is this a bug that we should report upstream?

CarbonChauvinist · 2019-12-16 17:53:19

IDK -- to me, I wouldn't really describe it as a "bug". Both systems (systemd-resolved and iwd) are behaving as expected AFAICT. It just seems that there needs to be some further coordination between systemd and iwd. I know that both iwd and systemd are moving targets, and that iwd is basically adding features that are duplicating some of systemd's functionality (for instance with networkd managing the interface etc.).

Others with more insight may chime in, but in my mind the way to address this is to be able to permanently override the DefaultRoute value per iwd link as needed -- forcing it to true. If I was using systemd-networkd to manage the .network I'd be able to do that (see below):

As you can see from the [Network] section of man 5 systemd.network for both DNSDefaultRoute and Domains below:

DNSDefaultRoute=
Takes a boolean argument. If true, this link's configured DNS servers are used for resolving domain names that do not match any link's configured Domains= setting. If false, this link's configured DNS servers are never used for such domains, and are exclusively used for resolving names that match at least one of the domains configured on this link. If not specified defaults to an automatic mode: queries not matching any link's configured domains will be routed to this link if it has no routing-only domains configured.

Domains=
A list of domains which should be resolved using the DNS servers on this link. Each item in the list should be a domain name, optionally prefixed with a tilde ("~"). The domains with the prefix are called "routing-only domains". The domains without the prefix are called "search domains" and are first used as search suffixes for extending single-label host names (host names containing no dots) to become fully qualified domain names (FQDNs). If a single-label host name is resolved on this interface, each of the specified search domains are appended to it in turn, converting it into a fully qualified domain name, until one of them may be successfully resolved.
Both "search" and "routing-only" domains are used for routing of DNS queries: look-ups for host names ending in those domains (hence also single label names, if any "search domains" are listed), are routed to the DNS servers configured for this interface. The domain routing logic is particularly useful on multi-homed hosts with DNS servers serving particular private DNS zones on each interface.
The "routing-only" domain "~." (the tilde indicating definition of a routing domain, the dot referring to the DNS root domain which is the implied suffix of all valid DNS names) has special effect. It causes all DNS traffic which does not match another configured domain routing entry to be routed to DNS servers specified for this interface. This setting is useful to prefer a certain set of DNS servers if a link on which they are connected is available.
This setting is read by systemd-resolved.service(8). "Search domains" correspond to the domain and search entries in resolv.conf(5). Domain name routing has no equivalent in the traditional glibc API, which has no concept of domain name servers limited to a specific link

But, as it is, since I'm using only iwd, I'm a little more limited. Hope to hear thoughts from others.

Edit -- Actually, the more I think about it, maybe there is something that needs to be changed on iwd's side. I don't know why they default to appending domains as "routing-only domains" (i.e. prefixed with the tide ("~"), instead of "search domains". They seem to presume any appended domain should be "routing-only" - which doesn't make sense to me (but there may be a valid reason for it). For instance my domain on my router simply listed "lan" - yet they prepended the tilde ("~") making it ~lan. I'd assume the same happened with yours (they pre-pended the tilde).

Last edited by CarbonChauvinist (2019-12-16 18:54:15)

mbalajew · 2019-12-16 21:35:39

Yes, the same is happening to me. In my case, I have:

 DNS Domain: ~hsd1.co.comcast.net

while you have

 DNS Domain: ~lan

What do you think? Maybe this is something we could bring up on the IWD IRC channel?

CarbonChauvinist · 2019-12-16 21:55:16

IWD Mailing List report and arch bug tracker

verto6 · 2019-12-18 16:38:42

Hello! This is my first post here - usually reading the arch wiki is sufficient, but today I had to give in and register here to reach out for help.

Sorry to bring up eduroam again, but this is driving me nuts!
This is basically the same issue @SRSR333 had, but the proposed solution from @Stellarator doesn't work for me apparently.

/var/lib/iwd/eduroam.8021x :

[Security]
EAP-Method=PEAP
EAP-Identity=eduroam@stud.uni-stuttgart.de  
EAP-PEAP-CACert=/etc/iwd/ca.pem 
EAP-PEAP-Phase2-Method=MSCHAPV2
EAP-PEAP-Phase2-Identity=...@stud.uni-stuttgart.de
EAP-PEAP-Phase2-Password=...

The ca.pem certificate file resides in /etc/iwd/ as specified.
So far I have tried to replace PEAP by TTLS or TLS and used various values for identity to no avail.

journalctl :

Dec 18 17:29:28 T440s kernel: wlan0: authenticate with f8:c2:88:47:72:7e
Dec 18 17:29:28 T440s kernel: wlan0: send auth to f8:c2:88:47:72:7e (try 1/3)
Dec 18 17:29:28 T440s kernel: wlan0: authenticated
Dec 18 17:29:28 T440s kernel: wlan0: associate with f8:c2:88:47:72:7e (try 1/3)
Dec 18 17:29:28 T440s kernel: wlan0: RX AssocResp from f8:c2:88:47:72:7e (capab=0x101 status=0 aid=1)
Dec 18 17:29:28 T440s kernel: wlan0: associated
Dec 18 17:29:28 T440s kernel: wlan0: Limiting TX power to 17 dBm as advertised by f8:c2:88:47:72:7e
Dec 18 17:29:33 T440s iwd[15742]: 4-Way handshake failed for ifindex: 2, reason: 15
Dec 18 17:29:33 T440s kernel: wlan0: deauthenticating from f8:c2:88:47:72:7e by local choice (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
Dec 18 17:29:33 T440s iwd[15742]: resolve-systemd: Failed to remove DNS entries. Is 'systemd-resolved' service running?

(I don't use systemd-resolved, so far I only have a static nameserver in /etc/resolv.conf. Shouldn't be the issue.)

iwd version 1.3.1

Has anybody a working solution or a hint for me?
Thank you very much in advance!

Last edited by verto6 (2019-12-18 16:42:41)

CarbonChauvinist · 2019-12-18 20:11:21

@verto6, not sure what your issue is exactly but, assuming you have the specifics on the network set up correctly for your use case, there does appear to be an issue iwd upstream is currently investigating, described as

Denis Kenzior wrote:

We're investigating a different issue (with PEAP + MSCHAPv2) reported against 1.3."

That seems to match your setup so maybe try checking on freenode #iwd and/or the ML? (i.e. This thread, or maybe this one (though the second has an actual core dump, so maybe not exactly what you're seeing)). Also did this work on 1.2 but not on 1.3?

verto6 wrote:

Dec 18 17:29:33 T440s iwd[15742]: resolve-systemd: Failed to remove DNS entries. Is 'systemd-resolved' service running?

If you're not using systemd-resolved then maybe trying changing the NameResolvingService to resolvconf in your main.conf? If not specified it defaults to systemd (though I thought this was only relevant if you're having iwd manage the network -- i.e. EnableNetworkConfiguration set to true under [General] in main.conf -- so it may not apply in your case).

The group [Network] contains network configuration related settings.
NameResolvingService Values: resolvconf, systemd
Configures a DNS resolution method used by the system.
This configuration option must be used in conjunction with EnableNetworkConfiguration and provides the choice of system resolver integration.
If not specified, systemd is used as default

Kniyl · 2019-12-20 10:03:26

Hi all,

I’ve been using IWD for a couple of month now and been quite happy with it. The wiki was really helpful and I got it working seamlessly with systemd-networkd, systemd-resolved and even OpenVPN.

There is just this one thing that keep bothering me: I can't figure out how to get autoconnect to work. It seems that IWD forgets known networks at each reboot; even though the proper files are present in /var/lib/iwd/:

# ls -la /var/lib/iwd/
total 32
drwx------  3 root root 4096 20 déc.   2019 .
drwxr-xr-x 24 root root 4096  9 déc.  11:19 ..
drwx------  2 root root    1 20 sept. 14:20 hotspot
-rw-------  1 root root    0 30 oct.  08:57 IKD_LG_Muret_Auto.open
-rw-------  1 root root 3496 20 déc.   2019 .known_network.freq
-rw-------  1 root root  169 11 déc.  15:25 Le_terrier.psk
-rw-------  1 root root  109 23 oct.  15:38 Moto_manu.psk
-rw-------  1 root root  113 20 déc.   2019 UPC0858175.psk
-rw-------  1 root root    0 23 oct.  15:31 Visiteurs_CNES.open

But

$ iwctl known-networks list
                                 Known Networks                                
--------------------------------------------------------------------------------
  Name                            Security   Hidden   Last connected     
--------------------------------------------------------------------------------
  UPC0858175                      psk                 Dec 20, 10:04 AM

And this network is only present because this is the one I connected to so I can post this issue, upon reboot, the list is empty.

Adding a

[Settings]
AutoConnect=true

section in network files does not help either…

Did I miss anything for this to work?

verto6 · 2019-12-20 17:04:50

@Kniyl, since you mentioned you use systemd-networkd, maybe that overrides the network files of iwd in a different directory? (I have no experience with systemd-networkd though.)

The man page for systemd.network:

Network setup is performed by systemd-networkd(8).

       The main network file must have the extension .network; other extensions are ignored.
       Networks are applied to links whenever the links appear.

       The .network files are read from the files located in the system network directories
       /usr/lib/systemd/network and /usr/local/lib/systemd/network, the volatile runtime
       network directory /run/systemd/network and the local administration network directory
       /etc/systemd/network.

My /var/lib/iwd directory looks similar to yours and the known-networks in iwd work for me. I don't use systemd-networkd though.

Arch Linux

#176 2019-10-31 16:10:53

Re: The IWD thread

#177 2019-11-04 17:18:12

Re: The IWD thread

#178 2019-11-05 02:14:09

Re: The IWD thread

#179 2019-11-05 02:50:07

Re: The IWD thread

#180 2019-11-05 11:42:08

Re: The IWD thread

#181 2019-11-05 17:08:39

Re: The IWD thread

#182 2019-11-06 19:28:21

Re: The IWD thread

#183 2019-11-07 18:48:26

Re: The IWD thread

#184 2019-11-07 19:23:23

Re: The IWD thread

#185 2019-11-16 23:30:24

Re: The IWD thread

#186 2019-11-17 15:56:59

Re: The IWD thread

#187 2019-12-10 12:00:02

Re: The IWD thread

#188 2019-12-14 17:36:05

Re: The IWD thread

#189 2019-12-14 19:00:52

Re: The IWD thread

#190 2019-12-14 19:55:17

Re: The IWD thread

#191 2019-12-15 18:09:06

Re: The IWD thread

#192 2019-12-15 21:12:39

Re: The IWD thread

#193 2019-12-16 02:35:52

Re: The IWD thread

#194 2019-12-16 17:53:19

Re: The IWD thread

#195 2019-12-16 21:35:39

Re: The IWD thread

#196 2019-12-16 21:55:16

Re: The IWD thread

#197 2019-12-18 16:38:42

Re: The IWD thread

#198 2019-12-18 20:11:21

Re: The IWD thread

#199 2019-12-20 10:03:26

Re: The IWD thread

#200 2019-12-20 17:04:50

Re: The IWD thread

Board footer