Bug 32373

Besides this issue with my main system, a laptop also will not work over wifi.
Using mcc to (try to) configure wifi, they "see' the various AP SSIDs; but won't connect.

What killed wifi?

Getting more interesting...  I have a USB wifi adapter from an old RasPi system; that works...  So, built-in devices quit working; but the issue does not affect this USB device. I REALLY need the laptop for an upcoming meeting, so I was rather irritated until I recalled the USB adapter...  it's only 2.4GHz; but it gives me access...

YIKES...  only until a reboot...  then neither adapter works...  If you're not seeing an issue yet, try rebooting...

Documenting as I go...

Checking recent changes in /etc...

/etc/modprobe.conf:
remove sdhci_pci /sbin/modprobe -r mmc_block; /sbin/modprobe --first-time -r --ignore-remove sdhci_pci
install sdhci_pci /sbin/modprobe --first-time --ignore-install sdhci_pci && { /sbin/modprobe mmc_block; /bin/true; }
remove rtsx_pci /sbin/modprobe -r mmc_block; /sbin/modprobe --first-time -r --ignore-remove rtsx_pci
install rtsx_pci /sbin/modprobe --first-time --ignore-install rtsx_pci && { /sbin/modprobe mmc_block; /bin/true; }
options snd-ac97-codec power_save=1
alias enp1s0f1 r8169
alias sound-slot-1 snd_hda_intel
alias sound-slot-0 snd_hda_intel
install sdhci /sbin/modprobe --first-time --ignore-install sdhci && { /sbin/modprobe mmc_block; /bin/true; }
remove sdhci /sbin/modprobe -r mmc_block; /sbin/modprobe --first-time -r --ignore-remove sdhci
install usb-interface /sbin/modprobe ehci_hcd; /sbin/modprobe ehci_pci; /sbin/modprobe xhci_hcd; /sbin/modprobe xhci_pci_renesas; /sbin/modprobe xhci_pci; /bin/true
alias wlp2s0 ath9k
alias pci:v0000168Cd00000036sv000011ADsd00000642bc02sc80i00 ath9k
alias wlp0s16u1 rt2800usb

Commented out the last 3 lines and rebooted. WiFi still didn't come up.

Last 3 lines of /etc/modprobe.conf are now
#alias pci:v0000168Cd00000036sv000011ADsd00000642bc02sc80i00 ath9k
#alias wlp0s16u1 rt2800usb
alias wlp0s16u1 rt2800usb   # got uncommented

Tryin again to setup wifi, getting this on konsole:
Selected interface 'wlp0s16u1'
OK
WARN      : [ifdown] You are using 'ifdown' script provided by 'network-scripts', which are now deprecated.
WARN      : [ifdown] 'network-scripts' will be removed from distribution in near future.
WARN      : [ifdown] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well.
WARN      : [ifup] You are using 'ifup' script provided by 'network-scripts', which are now deprecated.
WARN      : [ifup] 'network-scripts' will be removed from distribution in near future.
WARN      : [ifup] It is advised to switch to 'NetworkManager' instead - it provides 'ifup/ifdown' scripts as well.
Error for wireless request "Set Encode" (8B2A) :
    SET failed on device wlp0s16u1 ; Invalid argument.
Successfully initialized wpa_supplicant
Line 2079: unknown network field 'wep_key0'.      <--- say WHAT??
Line 2079: unsupported WEP parameter              <--- it's ALWAYS been 
Line 2081: unknown network field 'wep_tx_keyidx'. <--- WPA/WPA2 Pre-shared key
Line 2081: unsupported WEP parameter              <---
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument
Selected interface 'wlp0s16u1'
OK

Created attachment 14057 [details]
jounal output while configureing wifi via mcc

With a clue from laptop testing; tried configuring wifi on main system.  wifi adapter "sees" SSIDs but won't connect..

Checking journal, it recommends switching to NetworkManager...

Following procedure at https://wiki.mageia.org/en/Switching_to_networkmanager shows all NM packages were already installed. Everything seemed to work as specified.
However, the final step: systemctl mask network.service; systemctl mask network-up
returned:
Created symlink /etc/systemd/system/multi-user.target.wants/NetworkManager.service → /usr/lib/systemd/system/NetworkManager.service.
Created symlink /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service → /usr/lib/systemd/system/NetworkManager-dispatcher.service.
Created symlink /etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service → /usr/lib/systemd/system/NetworkManager-wait-online.service.

[Command not returning...]

^Z
[11]+  Stopped                 systemctl enable --now NetworkManager.service

# top | grep Network
 197330 root      20   0  369640  52100  17540 R 100.0   0.0   1:34.45 NetworkManager                                                                                                                                           
 197330 root      20   0  370640  53060  17540 R 100.0   0.0   1:37.46 NetworkManager  
q
                                                                                                                                         
# ps aux | grep NetworkManager
root      197330 99.8  0.0 442396 124420 ?       RLsl 11:19   5:00 /usr/sbin/NetworkManager --no-daemon
# kill -9 197330
[ it just restarts at 100% ]
# ps aux | grep NetworkManager
root      198454  104  0.0 337180 20628 ?        RLsl 11:24   0:01 /usr/sbin/NetworkManager --no-daemon

This doesn't seem right...

Will reboot to see if NM still eats CPU...

Yes, NM still runs 100% after reboot; AND has killed ALL but "lo" interfaces. To add insult to injury, NM takes 10+ minutes to startup.

Starting mcc to setup networking, mcc just hangs on "Loading...Please wait"...

I was able to restore at least ethernet with:
Changing .net_applet back to TRUE
systemctl unmask network.service

I can't comment on the mixture of packages, since I always run full cauldron, but I've never had a problem with NM and ethernet on one desktop or NM and WiFi on a succession of laptops over the years.

There are some blips.  Originally, NM had two states for an SSID: enable for all users, in which case connection would be made at NM initialization, or enable for a specific user, in which case connection would be made when that user logged in.  That seems to be gone now, because NM only connects now under Plasma when a user logs in.

After a clean installation, I generally have to enable and start NM because we still don't do this by default.  Then, before I start a DE, I use nmtui from a virtual console to activate the interfaces I want before starting the DE.  For Plasma, you need to have installed the Plasma NM applet.  GNOME includes NM support by default.

Either NM or the applet used to cache SSID passwords, but now Plasma appears to want to use kdewallet, and if you decline it wants you to re-authenticate every time the DE starts, but the connection always succeeds.

This behavior has persisted across several laptops with different Wifi chipsets.  My cauldron installs use custom desktops with all options enabled.

CC: (none) => ftg

Found what may be cause for slow boot...

/etc/sysconfig/network-scripts  contained 75,296 files, named ifcfg-veth*, such as: ifcfg-veth22166f4, ifcfg-veth75397e9, ifcfg-veth68086ae, etc...
All containing:
DEVICE=veth68086ae  <- matches file name
BOOTPROTO=dhcp
ONBOOT=yes

The file dates are Sep 29 thru Oct 11 which fall between these reboots:
Fri Sep 29 11:35:01 PM EDT 2023
Mageia release 10 (Cauldron) for x86_64
Kernel 6.5.3-server-1.mga10 on a 20-processor x86_64 / \l
Linux pf.pfortin.com 6.5.3-server-1.mga10 #1 SMP PREEMPT_DYNAMIC Sat Sep 16 00:04:28 UTC 2023 x86_64 GNU/Linux

Wed Oct 11 02:34:24 AM EDT 2023
Mageia release 10 (Cauldron) for x86_64
Kernel 6.5.3-server-1.mga10 on a 20-processor x86_64 / \l
Linux pf.pfortin.com 6.5.3-server-1.mga10 #1 SMP PREEMPT_DYNAMIC Sat Sep 16 00:04:28 UTC 2023 x86_64 GNU/Linux

For the most part, they were created at _random_ times; though on average about 4 per minute most of the time; some repeated within one second -- no repeating time pattern that I could see. 

I have not rebooted since Sat Oct 28 09:02:59 AM EDT 2023 and I won't have time to do anything with this before Tue Nov 7.

This last information is good - well done for spotting it.
Given the change in the direction of this bug from comments 3 to 4, from then on it looks like its newer related bug  32409.

CC: (none) => lewyssmith