USB tethering not working after updating to latest kernel

BEST8OY · 2025-04-14 16:56:48

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)

seth · 2025-04-14 19:15:24

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 ?

BEST8OY · 2025-04-14 21:05:50

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!

https://0x0.st/8f1O.txt

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.

seth · 2025-04-15 06:44:56

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

seth wrote:

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

Xx_RiK_xX · 2025-04-15 12:40:21

did you found any solution?
just checked that even the lts kernel has this bug.

seth · 2025-04-15 13:52:23

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.

Xx_RiK_xX · 2025-04-15 14:13:21

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

gromit · 2025-04-15 14:43:11

Is this already debugged (i.e. bisected) and reported upstream?

seth · 2025-04-15 14:44:20

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

gromit · 2025-04-16 14:21:02

Now posted on the Mailing list: https://lore.kernel.org/all/e0df2d85-12 … heusel.eu/

vekidev · 2025-04-23 11:58:56

So, wait wait wait, just because some guy needed a "wInDoWs-OnLY dOnGLe" to work, now USB tethering is just forever disabled? I thought the community was filtering old pieces of code that were only there for compatibility for one or two ancient devices, to make the kernel more lightweight AND to enable more modern features(such as USB tethering, 2010 tech people), but it's just this? Oh my god.

I spent like 6 hours straight checking the same configuration files, doing everything i can, and it seems like it just doesn't work because of some obscure "minor rename". Classic programming mistake, when a "minor tweak" breaks everything. But, it seems like there are "nO reGreSsIons!", so thousands of people either:
a) have to wait for a fix
b) have to wait for a regression(not possible)
c) just go back to Windows or macOS, as it works there

Such BS. I feel sorry for the maintainers maintaining this sort of crap.

seth · 2025-04-23 14:39:27

Has anyone tested to simply blacklist rndis_host ?

Xx_RiK_xX · 2025-04-23 16:30:07

fixed in 6.14.3?

seth · 2025-04-23 16:36:22

Question or report?
https://github.com/archlinux/linux/rele … 14.3-arch1 doesn't seem to apply such patch and upstream hasn't responded to the bug reports on any channel.
Get used to it, use dhcpcd or even systemd-networkd and drop NM.

Oh, and one last time: has anyone already tried to simply blacklist rndis_host?

idoybh2 · 2025-04-24 09:50:59

Xx_RiK_xX wrote:

fixed in 6.14.3?

nope.

seth wrote:

Oh, and one last time: has anyone already tried to simply blacklist rndis_host?

Yea. It doesn't work.
Just added

modprobe.blacklist=rndis_host

and rebooted ofc.

dmesg just shows:

[  352.956616] usb 8-2: USB disconnect, device number 6
[  353.284273] usb 8-2: new SuperSpeed USB device number 7 using xhci_hcd
[  353.298248] usb 8-2: New USB device found, idVendor=2a70, idProduct=9024, bcdDevice= 4.14
[  353.298251] usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  353.298253] usb 8-2: Product: SM8150-MTP _SN:F4456609
[  353.298255] usb 8-2: Manufacturer: OnePlus
[  353.298259] usb 8-2: SerialNumber: [REDACTED]

and nothing after it

normal dmesg on 6.14.1-arch1-1 for reference:

[  144.330432] usb 8-2: new SuperSpeed USB device number 4 using xhci_hcd
[  144.343546] usb 8-2: New USB device found, idVendor=2a70, idProduct=9024, bcdDevice= 4.14
[  144.343549] usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  144.343551] usb 8-2: Product: SM8150-MTP _SN:F4456609
[  144.343552] usb 8-2: Manufacturer: OnePlus
[  144.343554] usb 8-2: SerialNumber: [REDACTED]
[  144.364220] rndis_host 8-2:1.0 usb0: register 'rndis_host' at usb-0000:7b:00.0-2, RNDIS device, [MAC REDACTED]
[  144.382097] rndis_host 8-2:1.0 enp123s0u2: renamed from usb0

Last edited by idoybh2 (2025-04-24 10:00:30)

playbahn · 2025-04-24 13:08:42

Adding to this, I'm using `linux-lts 6.12.24-1` and I'm experiencing the same issue.

seth · 2025-04-24 13:46:28

Yes, this has infected *every* maintained kernel: https://bbs.archlinux.org/viewtopic.php … 3#p2236883 - and apprently cdc_ether won't operate the device by itself…
Android 11+ seems to support CDC Ethernet, but you may still have to actively select that, but it seems w/ older androids like 9.0 you're simply fucked (well, this breaks NM/MM, connecting w/ dhcpcd shall likely still work you in doubt just have to adjust teh device name?)

gromit · 2025-04-24 14:03:45

I have just sent out a revert for the change that causes this issue, so hopefully it will be fixed soon upstream

https://lore.kernel.org/all/20250424-us … @heusel.eu

seth · 2025-04-24 19:12:27

So the gist of https://chaos.social/@gromit/114377862699921553

do these people insist on relying on broken behavior, and prefer their setup falls apart with newer networkmanager instead

is that this is/was supposed to work with an *upcoming* userspace patch (for NM/MM)?

mmy8x · 2025-04-25 09:31:42

Not sure, maybe it's already implemented.

I'm not familiar with rndis and I don't know exactly how the modem mode is supposed to work (PPPoE?), but the devices that broke pretend to be ordinary NICs with DHCP and a router behind them. The patch modified some flag which as far as I see changes nothing besides the interface name (usb0 -> wwan0) and the dumb userspace apparently trusts this name to indicate that now it should be looking for a PPP modem behind the NIC. Looks like the author found some device of the "modem" variety and optimistically assumed that all devices implementing the same USB device class are also like that.

fn1701 · 2025-04-25 17:09:49

seth wrote:

Has anyone tested to simply blacklist rndis_host ?

As mentioned before sadly this doesn't work, because rndis_host is in principle the correct Kernel Module. It should connect the USB-Tethered-Phone as an "RNDIS device", but instead it connects it as "Mobile Broadband RNDIS device".
The device on which it breaks is a Fairphone 5, with the Stock ROM and Build-Number FP5.UT2M.B.113.20250319

on 6.12.22-1-lts and 6.14.1-arch1-1

$ sudo dmesg --since '1 min ago'
[  448.578371] usb 3-4: new high-speed USB device number 5 using xhci_hcd
[  448.765132] usb 3-4: New USB device found, idVendor=05c6, idProduct=9024, bcdDevice= 5.04
[  448.765145] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  448.765149] usb 3-4: Product: Fairphone 5 5G
[  448.765152] usb 3-4: Manufacturer: Fairphone
[  448.765154] usb 3-4: SerialNumber: [redacted]
[  448.787081] rndis_host 3-4:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-4, RNDIS device, e6:e9:d7:ad:78:a1
[  448.828706] rndis_host 3-4:1.0 enp0s20f0u4: renamed from usb0

on 6.12.24-1-lts and 6.14.3-arch1-1

$ sudo dmesg --since '1 min ago'
[  397.061726] usb 3-4: new high-speed USB device number 4 using xhci_hcd
[  397.457032] usb 3-4: New USB device found, idVendor=05c6, idProduct=9024, bcdDevice= 5.04
[  397.457041] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  397.457044] usb 3-4: Product: Fairphone 5 5G
[  397.457046] usb 3-4: Manufacturer: Fairphone
[  397.457048] usb 3-4: SerialNumber: [redacted]
[  397.470571] rndis_host 3-4:1.0 wwan0: register 'rndis_host' at usb-0000:00:14.0-4, Mobile Broadband RNDIS device, 86:3b:79:82:49:95
[  397.507101] rndis_host 3-4:1.0 wwp0s20f0u4: renamed from wwan0

Interestingly enough the Problem seems somewhat device specific. Maybe it could be helpful for the devs, if all of you could post on which of your devices it doesn't work and on which it does.
For me for example it works on an old Samsung Galaxy S8, with Android 14 and LineageOS 21-20240820-UNOFFICIAL-dreamlite:

on 6.12.24-1-lts and 6.14.3-arch1-1

$ sudo dmesg --since '1 min ago'
[  974.663935] usb 3-4: new high-speed USB device number 5 using xhci_hcd
[  975.054053] usb 3-4: New USB device found, idVendor=04e8, idProduct=6864, bcdDevice= 4.04
[  975.054066] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  975.054070] usb 3-4: Product: SM-G950F
[  975.054073] usb 3-4: Manufacturer: samsung
[  975.054075] usb 3-4: SerialNumber: [redacted]
[  975.061568] rndis_host 3-4:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-4, RNDIS device, 02:0a:50:50:30:67
[  975.108884] rndis_host 3-4:1.0 enp0s20f0u4: renamed from usb0

As a temporary fix I have in the end simply downgraded to 6.12.22-1-lts and 6.14.1-arch1-1

$ yay -S downgrade
$ sudo downgrade linux-lts=6.12.22
$ sudo downgrade linux=6.14.1.arch1

Last edited by fn1701 (2025-04-25 17:18:24)

Xx_RiK_xX · 2025-04-30 06:27:52

is it fixed now in 6.14.4-2?

gromit · 2025-04-30 06:41:52

@Xx_RiK_xX no the revert is still on it's way to linux and will afterwards be picked up by the stable team.

seth · 2025-04-30 06:47:00

Also linux 6.14.4.arch1-2 is a gcc 15 rebuild currently only in the testing repos…
https://gitlab.archlinux.org/archlinux/ … fbdaffa2dc

Instead of being the kid in the coach, asking whether we'll be there soon every 5 seconds, track https://github.com/archlinux/linux/comm … dis_host.c resp. https://github.com/archlinux/linux/comm … dis_host.c for any specific kernel.

Arch Linux

#26 2025-04-14 16:56:48

Re: USB tethering not working after updating to latest kernel

#27 2025-04-14 19:15:24

Re: USB tethering not working after updating to latest kernel

#28 2025-04-14 21:05:50

Re: USB tethering not working after updating to latest kernel

#29 2025-04-15 06:44:56

Re: USB tethering not working after updating to latest kernel

#30 2025-04-15 12:40:21

Re: USB tethering not working after updating to latest kernel

#31 2025-04-15 13:52:23

Re: USB tethering not working after updating to latest kernel

#32 2025-04-15 14:13:21

Re: USB tethering not working after updating to latest kernel

#33 2025-04-15 14:43:11

Re: USB tethering not working after updating to latest kernel

#34 2025-04-15 14:44:20

Re: USB tethering not working after updating to latest kernel

#35 2025-04-16 14:21:02

Re: USB tethering not working after updating to latest kernel

#36 2025-04-23 11:58:56

Re: USB tethering not working after updating to latest kernel

#37 2025-04-23 14:39:27

Re: USB tethering not working after updating to latest kernel

#38 2025-04-23 16:30:07

Re: USB tethering not working after updating to latest kernel

#39 2025-04-23 16:36:22

Re: USB tethering not working after updating to latest kernel

#40 2025-04-24 09:50:59

Re: USB tethering not working after updating to latest kernel

#41 2025-04-24 13:08:42

Re: USB tethering not working after updating to latest kernel

#42 2025-04-24 13:46:28

Re: USB tethering not working after updating to latest kernel

#43 2025-04-24 14:03:45

Re: USB tethering not working after updating to latest kernel

#44 2025-04-24 19:12:27

Re: USB tethering not working after updating to latest kernel

#45 2025-04-25 09:31:42

Re: USB tethering not working after updating to latest kernel

#46 2025-04-25 17:09:49

Re: USB tethering not working after updating to latest kernel

#47 2025-04-30 06:27:52

Re: USB tethering not working after updating to latest kernel

#48 2025-04-30 06:41:52

Re: USB tethering not working after updating to latest kernel

#49 2025-04-30 06:47:00

Re: USB tethering not working after updating to latest kernel

Board footer