You are not logged in.
You've wpa_supplicant running next to iwd => pick one (make it wpa_supplicant as iwd is what starts dogging on the modem device) and set that as NM backend.
How is this possible?
Yeah, I forgot to disable iwd but I don't even have wpa_suplicant installed
~ ❯❯❯ sudo pacman -Rns wpa_supplicant
[sudo] password for best8oy:
error: target not found: wpa_supplicant
Disabled and stopped iwd restarted ModemManager and still the same errors in ModemManager logs
My problem is that MM doesn't recognizes the phone not NM
I don't get how WiFi backend is related to this issue!
Now, I only have MM enabled to see if it even recognizes the phone, but it doesn't! (The same errors I shared in previous posts)
btrfs-scrub@-.timer | timers.target.wants
dbus-org.freedesktop.ModemManager1.service | system
fstrim.timer | timers.target.wants
getty@tty1.service | getty.target.wants
gnome-keyring-daemon.socket | sockets.target.wants
ModemManager.service | multi-user.target.wants
nvidia-hibernate.service | systemd-hibernate.service.wants
nvidia-resume.service | systemd-hibernate.service.wants
nvidia-resume.service | systemd-suspend.service.wants
nvidia-resume.service | systemd-suspend-then-hibernate.service.wants
nvidia-suspend.service | systemd-suspend.service.wants
p11-kit-server.socket | sockets.target.wants
pipewire-pulse.socket | sockets.target.wants
pipewire-session-manager.service | user
pipewire.socket | sockets.target.wants
remote-fs.target | multi-user.target.wants
systemd-userdbd.socket | sockets.target.wants
wireplumber.service | pipewire.service.wants
xdg-user-dirs-update.service | default.target.wants
Last edited by BEST8OY (2025-04-14 16:58:05)
Offline
Apr 14 13:36:43 DIAMOND systemd[1]: Starting WPA supplicant...
Apr 14 13:36:43 DIAMOND systemd[1]: Started WPA supplicant.
Apr 14 13:36:43 DIAMOND wpa_supplicant[901]: Successfully initialized wpa_supplicant
Apr 14 13:36:43 DIAMOND wpa_supplicant[901]: nl80211: kernel reports: Match already configured
Apr 14 13:36:43 DIAMOND wpa_supplicant[901]: nl80211: kernel reports: Match already configured
Apr 14 13:36:43 DIAMOND wpa_supplicant[901]: nl80211: kernel reports: Match already configured
Apr 14 13:36:43 DIAMOND wpa_supplicant[901]: nl80211: kernel reports: Match already configured
Apr 14 13:36:43 DIAMOND wpa_supplicant[901]: nl80211: kernel reports: Match already configured
Apr 14 13:36:43 DIAMOND wpa_supplicant[901]: nl80211: kernel reports: Match already configured
Apr 14 13:36:43 DIAMOND wpa_supplicant[901]: nl80211: kernel reports: Match already configured
type -a wpa_supplicant
I don't get how WiFi backend is related to this issue!
ALl I can tell you is that in the previous journal iwd got to that device before MM did - is this no longer the case?
Are you https://wiki.archlinux.org/title/Networ … Fi_backend ?
Offline
I checked the pacman log and it seems wpa_supplicant is a dependency for NM and was installed with NM (I was not aware)
I got rid of all my sd-nd + iwd setup for a clean log about the situation
Here is the new log!
By the way, I have no configuration for NM, so, everything's default (no changing backend, etc.)
I don't think there is any more info here since it's just giving the same errors
-----
If anyone was able to use tethering with ModemManager + NetworkManager, please share their experience, I would appreciate it.
Offline
You're still running into https://github.com/linux-mobile-broadba … er.c#L1287 - but obviously not because of iwd now.
=> https://gitlab.freedesktop.org/mobile-b … r/-/issues
So… brilliant. There's device nature change in a minor release to cater to NM/MM specifically and allow them to not work properly.
What if you flat-out blacklist "rndis_host"?
Possibly related conspiracy-theory fodder: https://www.phoronix.com/news/Linux-RND … al-EOY2024
Offline
did you found any solution?
just checked that even the lts kernel has this bug.
Offline
As pointed out in https://bbs.archlinux.org/viewtopic.php … 3#p2236883 this affects every current kernel…
If blacklisting rndis_host doesn't help, don't use NM + MM and configure the wwan device w/ dhcpcd or systemd-networkd or whatever and file a bug against MM in case you plan to keep using that (and NM) along tethering.
Offline
I will stick to 6.14.1 at this point. lets hope that it gets fixed in next release. thats all I can do at this moment
Offline
Is this already debugged (i.e. bisected) and reported upstream?
Offline
Given how deliberate and broadly applied this patch was, I'd not hold my breath for a kernel patch to undo that.
Fwwi, here's the gentoo bug: https://bugs.gentoo.org/953555
Offline
Now posted on the Mailing list: https://lore.kernel.org/all/e0df2d85-12 … heusel.eu/
Offline