how to activate my wireless card? nmtui only shows wireless connections . . .

[Albretch Mueller]

$ sudo lspci | grep --ignore-case Wireless
02:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless
Network Adapter (rev 31)
$

$ sudo lshw -class network
*-network DISABLED
description: Ethernet interface
product: RTL810xE PCI Express Fast Ethernet controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:01:00.0
logical name: enp1s0
version: 07
serial: c0:3e:ba:26:aa:93
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix vpd cap_list ethernet physical
configuration: broadcast=yes driver=r8169
driverversion=5.10.0-18-amd64 latency=0 link=no multicast=yes
resources: irq:16 ioport:3000(size=256)
memory:91400000-91400fff memory:91200000-91203fff
*-network
description: Network controller
product: QCA9377 802.11ac Wireless Network Adapter
vendor: Qualcomm Atheros
physical id: 0
bus info: pci@0000:02:00.0
version: 31
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list
configuration: driver=ath10k_pci latency=0
resources: irq:127 memory:91000000-911fffff
$

The difference between the wired Ethernet controller and the Wireless
Network Adapter are obvious, but what is the "logical name" of the
internal wireless card, which as I read:

https://forums.debian.net/viewtopic.php?t=136212

is supported in the kernel since version 4.4?

How can you go: "ip link set dev <logical name for wireless adapter>
up" when I don't even see what the logical name is?

[Timothy M Butterworth]

Just run `ip link` or `ip address` and it will show you the name.

 

 https://forums.debian.net/viewtopic.php?t=136212

 is supported in the kernel since version 4.4?

 How can you go: "ip link set dev <logical name for wireless adapter>
up" when I don't even see what the logical name is?

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

[Albretch Mueller]

On 3/3/23, Timothy M Butterworth <timothy.m....@gmail.com> wrote:
> Just run `ip link` or `ip address` and it will show you the name.

I had already done so, but I don't see the "logical name" or the IP
of the wireless interface on my very "temperamental" DELL Inspiron
which seems to have a mind of its own. I only see the loopback
interface, the interface for for the wired network and USB connection
through which I tether my cell phone to the WiFi network:

$ sudo ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN
mode DEFAULT group default qlen 1000
link/ether c0:3e:ba:26:aa:93 brd ff:ff:ff:ff:ff:ff
6: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 02:0b:37:c4:ef:fc brd ff:ff:ff:ff:ff:ff
$

when I removed my phone I still didn't see anything.

[Timothy M Butterworth]

Do you have the drivers installed:

firmware-atheros/testing,testing 20230210-1 all
 Binary firmware for Qualcomm Atheros wireless cards

Tim

[Christoph Brinkhaus]

Am Fri, Mar 03, 2023 at 05:01:49PM +0000 schrieb Albretch Mueller:
> On 3/3/23, Timothy M Butterworth <timothy.m....@gmail.com> wrote:
> > Just run `ip link` or `ip address` and it will show you the name.

In addition what Tim suggests:

You could run dmesg and search for ath, wifi, wlan, wlp or so.
In my case the output with a different driver is as below.

# dmesg|grep iwlwifi
[ 2.635994] iwlwifi 0000:04:00.0: enabling device (0000 -> 0002)
[ 2.648283] iwlwifi 0000:04:00.0: firmware: direct-loading firmware iwlwifi-8265-36.ucode
[ 2.649024] iwlwifi 0000:04:00.0: loaded firmware version 36.ad812ee0.0 8265-36.ucode op_mode iwlmvm
[ 2.649050] iwlwifi 0000:04:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[ 2.802163] iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8265, REV=0x230
[ 2.862957] iwlwifi 0000:04:00.0: base HW address: 00:e1:8c:eb:ce:bd
[ 3.048206] iwlwifi 0000:04:00.0 wlp4s0: renamed from wlan0

Kind regards,
Christoph
--
Ist die Katze gesund
schmeckt sie dem Hund.

[Albretch Mueller]

since it was included in the Linux kernel anyway I (apparently
wrongly) thought I didn't have to install any packages. After
downloading and installing the required firmware:

$ sudo dpkg --install firmware-atheros_20210315-3_all.deb
Selecting previously unselected package firmware-atheros.
(Reading database ... 233435 files and directories currently installed.)
Preparing to unpack firmware-atheros_20210315-3_all.deb ...
Unpacking firmware-atheros (20210315-3) ...
Setting up firmware-atheros (20210315-3) ...
$

I see:

$ sudo dmesg | grep firmware
[ 1.357329] i915 0000:00:02.0: firmware: failed to load
i915/icl_dmc_ver1_09.bin (-2)
[ 1.357334] firmware_class: See https://wiki.debian.org/Firmware
for information about missing firmware
[ 1.357338] i915 0000:00:02.0: Direct firmware load for
i915/icl_dmc_ver1_09.bin failed with error -2
[ 1.357341] i915 0000:00:02.0: [drm] Failed to load DMC firmware
i915/icl_dmc_ver1_09.bin. Disabling runtime power management.
[ 1.357342] i915 0000:00:02.0: [drm] DMC firmware homepage:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
[ 44.920667] platform regulatory.0: firmware: direct-loading
firmware regulatory.db
[ 44.920819] platform regulatory.0: firmware: direct-loading
firmware regulatory.db.p7s
[ 48.091722] ath10k_pci 0000:02:00.0: firmware: failed to load
ath10k/pre-cal-pci-0000:02:00.0.bin (-2)
[ 48.091761] ath10k_pci 0000:02:00.0: firmware: failed to load
ath10k/cal-pci-0000:02:00.0.bin (-2)
[ 48.091783] ath10k_pci 0000:02:00.0: firmware: failed to load
ath10k/QCA9377/hw1.0/firmware-6.bin (-2)
[ 48.091804] ath10k_pci 0000:02:00.0: firmware: failed to load
ath10k/QCA9377/hw1.0/firmware-5.bin (-2)
[ 48.091825] ath10k_pci 0000:02:00.0: firmware: failed to load
ath10k/QCA9377/hw1.0/firmware-4.bin (-2)
[ 48.091844] ath10k_pci 0000:02:00.0: firmware: failed to load
ath10k/QCA9377/hw1.0/firmware-3.bin (-2)
[ 48.091865] ath10k_pci 0000:02:00.0: firmware: failed to load
ath10k/QCA9377/hw1.0/firmware-2.bin (-2)
[ 48.091870] ath10k_pci 0000:02:00.0: Failed to find firmware-N.bin
(N between 2 and 6) from ath10k/QCA9377/hw1.0: -2
[ 48.091874] ath10k_pci 0000:02:00.0: could not fetch firmware files (-2)
[ 88.181411] r8169 0000:01:00.0: firmware: failed to load
rtl_nic/rtl8106e-1.fw (-2)
[ 88.181497] r8169 0000:01:00.0: Direct firmware load for
rtl_nic/rtl8106e-1.fw failed with error -2
[ 88.181513] r8169 0000:01:00.0: Unable to load firmware
rtl_nic/rtl8106e-1.fw (-2)
$

but I am not sure if those dmesgs relating to the kind of card I have
(QCA9377) were from the initial start of DL (I am running a long
process I should not stop to test that), but I am sure you will easily
make sense of it.

Why would the installation of that firmware fail and how do I fix or
troubleshoot that more in depth?

[Dan Ritter]

It probably has not been loaded at all yet -- the messages you
are seeing are from the first 88.2 seconds after boot.

-dsr-

[David Wright]

Try removing the atheros module with:

# rmmod ath10k_pci

(check its name in /proc/modules), and then reload it with

# modprobe ath10k_pci

and check dmesg again.

Cheers,
David.

[Jeffrey Walton]

On Fri, Mar 3, 2023 at 10:46 AM Albretch Mueller <lbr...@gmail.com> wrote:
>

> [...]

The "logical name" is a Consistent Name, and it is provided by
biosdevname. Also see
https://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf
.

The 'p' is a pci bus, the 's' is a slot number. Since the interface
does not move around once installed, the interface will always have
the same name like 'enp4s0'.

ifconfig will give you the names:

$ ifconfig
enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
...

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
...

wlp3s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
...

Jeff

[Greg Wooledge]

On Fri, Mar 03, 2023 at 05:45:54PM -0500, Jeffrey Walton wrote:
> The 'p' is a pci bus, the 's' is a slot number. Since the interface
> does not move around once installed, the interface will always have
> the same name like 'enp4s0'.

That's a wonderful idea, but it doesn't quite work in practice. There are
ways that a "predictable" interface name may change. A BIOS/firmware
upgrade can do it. Adding or removing devices can also do it, in
some cases. They don't even have to be network interfaces.

[Timothy M Butterworth]

An easier way to check is: sudo dmesg | grep wlan

[    9.760888] rtw_8822ce 0000:02:00.0 wlo1: renamed from wlan0

 

 but I am not sure if those dmesgs relating to the kind of card I have
(QCA9377) were from the initial start of DL (I am running a long
process I should not stop to test that), but I am sure you will easily
make sense of it.

 Why would the installation of that firmware fail and how do I fix or
troubleshoot that more in depth?

[Timothy M Butterworth]

It looks like your hardware is not supported by the firmware. If you are installing Debian 11 you can try backports, but as debian 12 will be out in the next few months I would just install Debian 12.

https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/bookworm_di_alpha1+nonfree/amd64/iso-dvd/

I am running Bookworm on two of my PC's. My notebook because it does not have working drivers for HDMI Sound or my WiFi in Debian 11 and my set top box so I can use KDE Plasma Big Screen.

Tim

 

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

[Albretch Mueller]

On 3/3/23, David Wright <deb...@lionunicorn.co.uk> wrote:
>
> Try removing the atheros module with:
>
> # rmmod ath10k_pci
>
> (check its name in /proc/modules), and then reload it with
>
> # modprobe ath10k_pci
>
> and check dmesg again.

Bingo! Those were the steps that enable me to see the wireless
network with nmtui ...

a) sudo rmmod ath10k_pci

b) cat /proc/modules | grep "ath10k_pci"

c) sudo modprobe ath10k_pci

d) sudo ip link:

$ sudo ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc

pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether c0:3e:ba:26:aa:93 brd ff:ff:ff:ff:ff:ff

4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast

state UNKNOWN mode DEFAULT group default qlen 1000

link/ether de:79:31:21:04:06 brd ff:ff:ff:ff:ff:ff
5: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN mode DORMANT group default qlen 1000
link/ether 4e:0b:ec:22:77:bc brd ff:ff:ff:ff:ff:ff permaddr
5c:3a:45:0a:fb:c1
$

e) nmtui

I will retest all the steps when I get a chance to make sure to go
through the steps from a "blank slate", new start

[Jeffrey Walton]

Yeah, that's udev and systemd screwing things up.

Jeff

[to...@tuxteam.de]

And don't get us started with USB dongles, which are enumerated across
many and diverse hubs depending on your electricity supplier, moon phase
and all.

"You're In A Maze Of Twisty Little Passages, All Alike"

Once I understood what this is doing, I decided that I have to watch
out with consistent interface names as I had to watch out with the
traditional ones: the more complex names I can't memorise don't buy
me much.

Then I decided to go back to traditional names. Luckily, that's an
option.

Cheers
--
t

[Albretch Mueller]

On 3/3/23, Dan Ritter <d...@randomstring.org> wrote:
> ... the messages you

> are seeing are from the first 88.2 seconds after boot.

Most probably and luckily no one has reported such problems, but from
the corner from which I see reality it may as well be not "after
boot". I haven't exactly timed it (I will when I get a chance, in
fact, dmesg logs should do), but booting the 16Gb RAM laptop I am
using right now with a Debian Live DVD takes definitely more than one
minute.

Something else "weird" that I noticed is that the BIOS not only kept
a connection to a wireless network around me (which I used more than a
year ago and which password I don't even remember) but was able to
connect through it. I wonder why on earth should a BIOS be WiFi
enabled?!? but, well, these days even microwaves are! I think the only
way to deal with such matters is by physically disconnecting the
wireless card if possible and/or keeping your laptop in a (optimally
grounded) Faraday cage. Unfortunately, I can't do so right now because
my cell phone is also acting up, . . . once for just writing a poem my
connection to the Internet and cell phone didn't work for 8 months!
(hsymbolicus poems "lies ..."); so, for now, I will have to keep
"hugging the Germans".

I really don't give a sh!t about Windows (I would just use it as test
based for my java code), but something I have noticed is that from the
Debian Live boot I can't access the internal SSD in my DELL Inspiron
box. Do you have experience with, would you suggest ways out of such
problems?

lbrtchx

[David Wright]

Not really. You've got plenty of choice:

net.ifnames=0, biosdevname=0 (on Dell), and
NamePolicy={kernel,database,onboard,slot,path,mac,keep}

Who could want more?

Cheers,
David.

[David Wright]

On Sat 04 Mar 2023 at 00:03:16 (+0000), Albretch Mueller wrote:
> On 3/3/23, David Wright <deb...@lionunicorn.co.uk> wrote:
> >
> > Try removing the atheros module with:
> >
> > # rmmod ath10k_pci
> >
> > (check its name in /proc/modules), and then reload it with
> >
> > # modprobe ath10k_pci
> >
> > and check dmesg again.
>
> Bingo! Those were the steps that enable me to see the wireless
> network with nmtui ...

Good to hear.

> a) sudo rmmod ath10k_pci
>
> b) cat /proc/modules | grep "ath10k_pci"
>
> c) sudo modprobe ath10k_pci
>
> d) sudo ip link
>

> e) nmtui
>
> I will retest all the steps when I get a chance to make sure to go
> through the steps from a "blank slate", new start

I'll just point out that cat /proc/modules was added as an
afterthought in case (a) failed, so if (a) succeeds, you don't
need to do (b). There's always a chance, when removing modules,
that one is busy, or another has to be removed at the same time
as the one, because it's a dependent.

Also, now that the firmware is in place, if you repeat those steps,
you're /likely/ to find that ath10k_pci is busy, because the link
will be configured automatically in the first few seconds after
booting up.

Cheers,
David.

[Jeffrey Walton]

If you are creating the problem you should not be surprised there is a problem.

Jeff

[Albretch Mueller]

On 3/4/23, David Wright <deb...@lionunicorn.co.uk> wrote:
> Also, now that the firmware is in place, if you repeat those steps,
> you're /likely/ to find that ath10k_pci is busy, because the link
> will be configured automatically in the first few seconds after
> booting up.

I would always go into exposed mode using a DL DVD that is what I
meant when I said "re start". So, I will need to run a dkpg script
whenever I boot it.

sudo iwlist wlp2s0 scan | grep ESSID

will list the wireless networks around. All I need now is a way to
somehow pass the password into the script in the command line of
through a config file so that I don't have to enter it every time. I
tried to find a way to do just that.

How do you?

[Curt]

https://wiki.debian.org/NetworkInterfaceNames

* UNPREDICTABILITY
it turns out even after all this [**an enumeration of complications and corner
cases**] there are still reported cases of interfaces changing their name on a
reboot. All that needs to happen is that some buggy BIOS (or some new, less
buggy version of a driver module, or systemd's naming policy) changes its mind
about some detail like whether or not your hardware counts as the kind that
should have an ONBOARD name. There are even multiple reports of devices
changing their PCI-port numbering due to other hardware being installed.

[Anssi Saari]

Curt <cu...@free.fr> writes:

> * UNPREDICTABILITY
> it turns out even after all this [**an enumeration of complications and corner
> cases**] there are still reported cases of interfaces changing their name on a
> reboot.

I have just this fun kind of unpredictability in my router's 4G
module. Mostly, it comes up as wwan0 but sometimes it's wwx<random>. So
I put something in my 4G management script to rename such interface if
there's no wwan0. Easier to force the interface name since I need to
know the interface in the firewall and failover script too.

[Greg Wooledge]

On Sun, Mar 05, 2023 at 09:22:10PM +0200, Anssi Saari wrote:
> I have just this fun kind of unpredictability in my router's 4G
> module. Mostly, it comes up as wwan0 but sometimes it's wwx<random>. So
> I put something in my 4G management script to rename such interface if
> there's no wwan0.

If you're running systemd, you can create a "dot link" file
(see systemd.link(5)) to assign names to interfaces based on any
criteria you can manage to grab hold of. MAC address or whatever.

[Albretch Mueller]

I thought “unpredictability” was the name of my daily drama show, but
apparently “I am not the only one”. Yes, I know javascript is the
primary vector they use to mess with whomever they choose, regardless
of if they wear a “tiny tin hat” or expensive shoes.
In my case, among many other things, they somehow inject key loggers
through the browser every time I access the Internet from wherever I
access it, but there is way more to it. Probably I am too old for that
kind of crap, but why would a BIOS need to be WiFi enabled? Is the
kernel itself doing all that name changing? Why would it do that? . .
.
As part of my work I have to do lots of text cleansing. Even
Libreoffice inserts as part of their tags lots of watermarking crap
which of course is being used to track texts, but it would just be
unnecessary noise in a text corpus. I asked them once why they were
doing that and they, expectedly, started to act like “you are
paranoid”, certainly wear a “tiny tin hat” . . .

[David Wright]

I run installed systems, so wifi passwords are either in individual
/var/lib/iwd/<ESSID>.psk files (with iwd), or collectively in
/etc/wpa_supplicant/<ifname>.conf (with wpasupplicant/systemd-networkd).

These files have go= permissions, and I don't consider them of great
enough concern to put them on an encrypted filesystem (which would
in any case need unlocking). However, you could do just that, with an
encrypted USB stick. At least you'd benefit from just one passphrase
to unlock any and all necessary secrets.

Cheers,
David.

[David Wright]

So what was wrong with using a .link file like:

[Match]
Type=wwan
[Link]
NamePolicy=keep kernel

or

[Match]
Type=wwan
[Link]
Name=my4g

Did this not work?

Cheers,
David.

[Albretch Mueller]

Is there a way to pass the password on the command to that modprobe
or whichever utility?

Apparently because I use DL I don't have that kind of directory structure:

$ cd /var/lib/iwd/
bash: cd: /var/lib/iwd/: No such file or directory

$ cd /var/lib/
$ ls -l
total 0
drwxr-xr-x 2 root root 3 Dec 7 2020 alsa
drwxr-xr-x 1 root root 60 Mar 5 06:01 apt
drwxr-xr-x 2 root root 3262 Sep 10 11:19 aspell
drwxr-xr-x 2 avahi-autoipd avahi-autoipd 3 Sep 10 11:06 avahi-autoipd
drwxr-xr-x 1 colord colord 100 Mar 4 23:57 colord
drwxr-xr-x 2 root root 33 Sep 10 11:05 dbus
drwxr-xr-x 2 root root 3 May 27 2021 dhcp
drwxr-xr-x 6 root root 75 Sep 10 10:58 dictionaries-common
drwxr-xr-x 2 root root 37 Sep 10 10:56 dkms
drwxr-xr-x 1 root root 220 Mar 5 00:13 dpkg
drwxr-xr-x 3 root root 28 Sep 10 10:57 emacsen-common
drwxr-xr-x 1 root root 60 Mar 4 23:56 exim4
drwxr-xr-x 2 geoclue geoclue 3 Mar 17 2021 geoclue
drwxr-xr-x 4 root root 40 Sep 10 10:58 ghostscript
drwxr-xr-x 3 root root 26 Sep 10 10:58 grub
drwxr-xr-x 3 root root 26 Sep 10 11:01 hardware
drwxr-xr-x 2 root root 815 Sep 10 11:19 ispell
drwxr-xr-x 3 root root 28 Sep 10 11:01 libreoffice
drwxr-x--- 1 lightdm lightdm 60 Mar 4 23:56 lightdm
drwxr-xr-x 1 root root 60 Sep 10 11:03 live
drwxr-xr-x 1 root root 60 Mar 5 00:00 logrotate
drwxr-xr-x 2 root root 34 Sep 10 11:07 man-db
drwxr-xr-x 2 root root 3 Sep 3 2022 misc
drwx------ 1 root root 140 Mar 5 20:50 NetworkManager
drwxr-xr-x 2 root root 3 Jun 28 2021 os-prober
drwxr-xr-x 2 root root 3 Dec 22 2020 PackageKit
drwxr-xr-x 2 root root 115 Sep 10 11:06 pam
drwxr-xr-x 1 root root 60 Mar 4 23:55 plymouth
drwx------ 1 root root 60 Sep 10 10:54 polkit-1
drwx------ 2 root root 40 Mar 4 23:54 private
drwxr-xr-x 2 root root 42 Sep 10 10:56 python
drwxr-xr-x 4 root root 43 Sep 10 10:54 runit
drwxr-xr-x 1 root root 100 Mar 5 19:55 smartmontools
drwxr-xr-x 2 root root 3 Aug 15 2022 snmp
drwxr-xr-x 3 root root 31 Sep 10 10:54 sudo
drwxr-xr-x 2 root root 3 Nov 16 2020 synaptic
drwxr-xr-x 1 root root 180 Mar 5 00:15 systemd
drwxr-xr-x 3 root root 348 Sep 10 11:18 ucf
drwx------ 2 root root 60 Mar 5 00:07 udisks2
drwxr-xr-x 2 root root 76 Sep 10 11:16 uim
drwxr-xr-x 1 root root 120 Mar 5 00:07 upower
drwxr-xr-x 2 root root 3 Jul 10 2020 usb_modeswitch
drwxr-xr-x 2 root root 30 Sep 10 11:05 usbutils
drwxr-xr-x 3 root root 29 Sep 10 10:54 vim
drwxr-xr-x 2 root root 39 Sep 10 11:15 xfonts
drwxr-xr-x 1 root root 40 Mar 4 23:59 xkb
$

[Anssi Saari]

David Wright <deb...@lionunicorn.co.uk> writes:

> So what was wrong with using a .link file like:
>
> [Match]
> Type=wwan
> [Link]
> NamePolicy=keep kernel
>
> or
>
> [Match]
> Type=wwan
> [Link]
> Name=my4g
>
> Did this not work?

Nothing was wrong but I just added a few lines to my management script
to do the renaming. Easy to do, easy to test.

It's not like I can have systemd-networkd manage the device, I have to
use qmi-network and udhcpc.

[David Wright]

On Sun 05 Mar 2023 at 20:57:25 (+0000), Albretch Mueller wrote:
> On 3/5/23, David Wright <deb...@lionunicorn.co.uk> wrote:
> >
> > I run installed systems, so wifi passwords are either in individual
> > /var/lib/iwd/<ESSID>.psk files (with iwd), or collectively in
> > /etc/wpa_supplicant/<ifname>.conf (with wpasupplicant/systemd-networkd).
> >
> > These files have go= permissions, and I don't consider them of great
> > enough concern to put them on an encrypted filesystem (which would
> > in any case need unlocking). However, you could do just that, with an
> > encrypted USB stick. At least you'd benefit from just one passphrase
> > to unlock any and all necessary secrets.
>
> Is there a way to pass the password on the command to that modprobe
> or whichever utility?
>
> Apparently because I use DL I don't have that kind of directory structure:
>
> $ cd /var/lib/iwd/
> bash: cd: /var/lib/iwd/: No such file or directory

You only don't have this directory because you have:

> drwx------ 1 root root 140 Mar 5 20:50 NetworkManager

running your network, not iwd. As for /etc/wpa_supplicant/, NM lists
it as a dependency. I don't whether NM is scriptable, for passing in
a password, or not: I've never used it.

Cheers,
David.