USB tethering not working after updating to latest kernel

Xx_RiK_xX · 2025-04-12 08:21:52

its not working in 6.14.2.zen1-1 but was working in 6.14.1-zen1-1-zen. its now getting detected as wwp instead of enp as in 6.14.1-zen1-1-zen

seth · 2025-04-12 14:54:02

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Run "dmesg -W |& tee /tmp/dmesg.tail" attach the tethering device and post the dmesg output generated by that (you'll also find it in /tmp/dmesg.tail)

wwp is WWAN (mobile modem) - did you test whether it's still working w/ the previous kernel or the LTS kernel (maybe somse setting in the phone changed)

Xx_RiK_xX · 2025-04-12 15:17:46

tried the command with sudo, it just hangs there for 10 minutes and then I cancelled it.
and yes the usb tethering is working in 6.14.1-zen1-1-zen but not in 6.14.2.zen1-1. the phone is getting detected and adb is also working but not tethering. so I reverted back to 6.14.1-zen1-1-zen. and nothing has changed in the phone

BEST8OY · 2025-04-12 16:17:59

I have the same problem on latest normal kernel 6.14.2
14.1

[   63.858897] usb 1-3: new high-speed USB device number 4 using xhci_hcd
[   63.989598] usb 1-3: New USB device found, idVendor=05c6, idProduct=9024, bcdDevice= 4.09
[   63.989615] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   63.989621] usb 1-3: Product: Xiaomi Mi 9 Lite
[   63.989627] usb 1-3: Manufacturer: Xiaomi
[   63.989631] usb 1-3: SerialNumber: a3bc46c5
[   64.038675] usbcore: registered new interface driver cdc_ether
[   64.048796] rndis_host 1-3:1.0 usb0: register 'rndis_host' at usb-0000:00:14.0-3, RNDIS device, f2:ea:e8:d0:c2:bc
[   64.048850] usbcore: registered new interface driver rndis_host
[   64.061210] rndis_host 1-3:1.0 enp0s20f0u3: renamed from usb0

14.2

[   38.842001] usb 1-3: new high-speed USB device number 4 using xhci_hcd
[   38.968668] usb 1-3: New USB device found, idVendor=05c6, idProduct=9024, bcdDevice= 4.09
[   38.968684] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   38.968690] usb 1-3: Product: Xiaomi Mi 9 Lite
[   38.968694] usb 1-3: Manufacturer: Xiaomi
[   38.968699] usb 1-3: SerialNumber: a3bc46c5
[   39.016260] usbcore: registered new interface driver cdc_ether
[   39.028609] rndis_host 1-3:1.0 wwan0: register 'rndis_host' at usb-0000:00:14.0-3, Mobile Broadband RNDIS device, 5a:61:05:c8:49:9c
[   39.028676] usbcore: registered new interface driver rndis_host
[   39.044046] rndis_host 1-3:1.0 wwp0s20f0u3: renamed from wwan0

cryptearth · 2025-04-12 17:14:49

if OPs result is similar to the one above I don't see any issue - just a proper renaming from ENP prefix for an ethernet connection to WWP for a mobile connection - or to put it this way: the kernel seems now to be able to correctly identify the actual mobile modem as such althogh it's tunneled thru an usb connection (as that's what usb nic tethering is in the end)
so no matter if using systemd-networkd or NetworkManager or whatever - should all work fine the same no matter what by just rename "enpXXX" to "wwpXXX"

BEST8OY · 2025-04-12 17:21:59

cryptearth wrote:

if OPs result is similar to the one above I don't see any issue - just a proper renaming from ENP prefix for an ethernet connection to WWP for a mobile connection - or to put it this way: the kernel seems now to be able to correctly identify the actual mobile modem as such althogh it's tunneled thru an usb connection (as that's what usb nic tethering is in the end)
so no matter if using systemd-networkd or NetworkManager or whatever - should all work fine the same no matter what by just rename "enpXXX" to "wwpXXX"

Well, it doesn't.
I tried both systemd-networkd and NetworkManager to no avail.
6.14.1 works just fine!

cryptearth · 2025-04-12 17:27:37

well - in the mena time I put my money where my mouth is - disabled my lan, connected my phone via usb, enabled tethring, wrote this for systemd

[Match]
Name=wwp2s0f0u2u3

[Network]
DHCP=yes

and post this reply via mobile tethering while hold the end of my network cable unplugged from my pc

TLDR: it really does seem to be just a minor rename

[21632.479324] r8169 0000:2a:00.0 enp42s0: Link is Down
[21632.479389] br0: port 1(enp42s0) entered disabled state
[21635.367654] r8169 0000:2a:00.0 enp42s0: Link is Up - 1Gbps/Full - flow control off
[21635.367687] br0: port 1(enp42s0) entered blocking state
[21635.367692] br0: port 1(enp42s0) entered forwarding state
[22758.271025] r8169 0000:2a:00.0 enp42s0: Link is Down
[22758.271097] br0: port 1(enp42s0) entered disabled state
[22761.057491] r8169 0000:2a:00.0 enp42s0: Link is Up - 1Gbps/Full - flow control off
[22761.057518] br0: port 1(enp42s0) entered blocking state
[22761.057524] br0: port 1(enp42s0) entered forwarding state
[57181.272459] usb 1-2.3: new high-speed USB device number 9 using xhci_hcd
[57181.349334] usb 1-2.3: New USB device found, idVendor=0fce, idProduct=020c, bcdDevice= 5.04
[57181.349340] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[57181.349343] usb 1-2.3: Product: XQ-DC54
[57181.349345] usb 1-2.3: Manufacturer: Sony
[57181.349347] usb 1-2.3: SerialNumber: HQ637S099A
[57200.551102] usb 1-2.3: USB disconnect, device number 9
[57200.761517] usb 1-2.3: new high-speed USB device number 10 using xhci_hcd
[57200.837662] usb 1-2.3: New USB device found, idVendor=0fce, idProduct=720c, bcdDevice= 5.04
[57200.837667] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[57200.837669] usb 1-2.3: Product: XQ-DC54
[57200.837671] usb 1-2.3: Manufacturer: Sony
[57200.837673] usb 1-2.3: SerialNumber: HQ637S099A
[57200.886199] usbcore: registered new interface driver cdc_ether
[57200.891689] rndis_host 1-2.3:1.0 wwan0: register 'rndis_host' at usb-0000:02:00.0-2.3, Mobile Broadband RNDIS device, 3e:c3:5c:5c:30:dd
[57200.891712] usbcore: registered new interface driver rndis_host
[57200.897358] rndis_host 1-2.3:1.0 wwp2s0f0u2u3: renamed from wwan0
[main@main ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp42s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 04:7c:16:19:98:71 brd ff:ff:ff:ff:ff:ff
    altname enx047c16199871
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 1e:4b:33:3b:e6:e4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.26/24 metric 1024 brd 192.168.178.255 scope global dynamic br0
       valid_lft 829506sec preferred_lft 829506sec
    inet6 2a0c:d242:3806:3800:1c4b:33ff:fe3b:e6e4/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7062sec preferred_lft 3462sec
    inet6 fd9f:c123:5b95:0:1c4b:33ff:fe3b:e6e4/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7062sec preferred_lft 3462sec
    inet6 fe80::1c4b:33ff:fe3b:e6e4/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
4: br1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 2a:20:04:0b:8f:50 brd ff:ff:ff:ff:ff:ff
5: wwp2s0f0u2u3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 3e:c3:5c:5c:30:dd brd ff:ff:ff:ff:ff:ff
    altname wwx3ec35c5c30dd
[main@main ~]$

...

[main@main network]$ sudo systemctl restart systemd-networkd systemd-resolved
[main@main network]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp42s0: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master br0 state DOWN group default qlen 1000
    link/ether 04:7c:16:19:98:71 brd ff:ff:ff:ff:ff:ff
    altname enx047c16199871
3: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 1e:4b:33:3b:e6:e4 brd ff:ff:ff:ff:ff:ff
4: br1: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 2a:20:04:0b:8f:50 brd ff:ff:ff:ff:ff:ff
5: wwp2s0f0u2u3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 3e:c3:5c:5c:30:dd brd ff:ff:ff:ff:ff:ff
    altname wwx3ec35c5c30dd
    inet 192.168.109.198/24 metric 1024 brd 192.168.109.255 scope global dynamic wwp2s0f0u2u3
       valid_lft 3598sec preferred_lft 3598sec
    inet6 fe80::3cc3:5cff:fe5c:30dd/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
[main@main network]$ ip r
default via 192.168.109.214 dev wwp2s0f0u2u3 proto dhcp src 192.168.109.198 metric 1024 
192.168.109.0/24 dev wwp2s0f0u2u3 proto kernel scope link src 192.168.109.198 metric 1024 
192.168.109.214 dev wwp2s0f0u2u3 proto dhcp scope link src 192.168.109.198 metric 1024 
[main@main network]$

yet another "works fine for me - seems to be user error on your end" topic

// even I only have a usb-a to usb-c 2.0 charging cable I'm able to push about 220mbit/s through it - so about half the theoretical max of 480mbit/s of usb 2.0
also - if this would be a 6.14 kernel regression it likely wouldn't show from a minor patch between 6.14.1 and 6.14.2 but rather between majors 6.12/6.13 and 6.14 in general - but I could be wrong

Last edited by cryptearth (2025-04-12 17:39:36)

seth · 2025-04-12 18:54:42

BEST8OY wrote:

I tried both systemd-networkd and NetworkManager to no avail.
6.14.1 works just fine!

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Post the output of

ip a; ip r

and explain how you configure your network.

@Xx_RiK_xX, "dmesg -W" will "hang" forever, it essetially tails dmesg.
You're stil expecting some output once you attach/activate the tethering device (similar to what BEST8OY posted)

@cryptearth

if this would be a 6.14 kernel regression it likely wouldn't show from a minor patch between 6.14.1 and 6.14.2 but rather between majors

Are you still on 6.14.1? Otherwise everything points to this having changed on the minor release (which kinda feels wrong, even if at the end of the day it's not that big of a deal)

tekstryder · 2025-04-12 19:25:19

This might be relevant. From the 6.14.2 changelog:
https://cdn.kernel.org/pub/linux/kernel … Log-6.14.2

commit d34963d968a6e5f5f98ceecc987fc9f221f1cac7
Author: Lubomir Rintel <lkundrak@v3.sk>
Date:   Tue Mar 25 10:58:41 2025 +0100

    rndis_host: Flag RNDIS modems as WWAN devices
    
    [ Upstream commit 67d1a8956d2d62fe6b4c13ebabb57806098511d8 ]
    
    Set FLAG_WWAN instead of FLAG_ETHERNET for RNDIS interfaces on Mobile
    Broadband Modems, as opposed to regular Ethernet adapters.
    
    Otherwise NetworkManager gets confused, misjudges the device type,
    and wouldn't know it should connect a modem to get the device to work.
    What would be the result depends on ModemManager version -- older
    ModemManager would end up disconnecting a device after an unsuccessful
    probe attempt (if it connected without needing to unlock a SIM), while
    a newer one might spawn a separate PPP connection over a tty interface
    instead, resulting in a general confusion and no end of chaos.
    
    The only way to get this work reliably is to fix the device type
    and have good enough version ModemManager (or equivalent).
    
    Fixes: 63ba395cd7a5 ("rndis_host: support Novatel Verizon USB730L")
    Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
    Link: https://patch.msgid.link/20250325095842.1567999-1-lkundrak@v3.sk
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

BEST8OY · 2025-04-12 20:57:37

First of all, I was not configuring systemd-networkd (I expected it to work out of the box) ---> So, I did what 'cryptearth' did and then

 sudo systemctl restart systemd-networkd systemd-resolved

and now I have tethering working

similar result for

ip a; ip r

like 'cryptearth'

This is the result with NetworkManager

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: wwp0s20f0u3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether e6:4a:51:db:0c:7d brd ff:ff:ff:ff:ff:ff
    altname wwxe64a51db0c7d
3: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether f8:75:a4:c5:27:21 brd ff:ff:ff:ff:ff:ff
    altname enxf875a4c52721
4: wlp0s20f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 66:1a:c1:e9:b1:3d brd ff:ff:ff:ff:ff:ff permaddr d8:3b:bf:7d:19:c3
    altname wlxd83bbf7d19c3

Should I configure NetworkManager too?? because it used to work out of the box in NM
My NM has default configuration

seth · 2025-04-12 21:00:06

You should notably not run NM and systemd-network in parallel.
Please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

W/ NM there's special behavior in that it'll just use whatever ethernet (enp) device it can get hold on (opt-out) while everything else is opt in and has to be actively configured.

BEST8OY · 2025-04-12 21:14:00

I know, I fully stopped the other when switching between the two

btrfs-scrub@-.timer                      | timers.target.wants
dbus-org.freedesktop.nm-dispatcher.service | system
fstrim.timer                             | timers.target.wants
getty@tty1.service                       | getty.target.wants
gnome-keyring-daemon.socket              | sockets.target.wants
NetworkManager.service                   | multi-user.target.wants
NetworkManager-wait-online.service       | network-online.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

So, with how things are now I have to configure NM?

seth · 2025-04-12 21:38:10

So, with how things are now I have to configure NM?

Yup. Though I'd hope that using ModemManager is only optional here…

cryptearth · 2025-04-12 23:20:08

seth wrote:

@cryptearth
if this would be a 6.14 kernel regression it likely wouldn't show from a minor patch between 6.14.1 and 6.14.2 but rather between majors
Are you still on 6.14.1? Otherwise everything points to this having changed on the minor release (which kinda feels wrong, even if at the end of the day it's not that big of a deal)

I did my test on 6.14.2 - and, as now proven by the commit, this is in fact just a more minor type change (which in the end results in a minor "name" change as I predicted in my first reply) I not bothered to revert back to 6.14.1 to cross-check - as I had no assumption this would change anything in the actual function but rather only the naming due to the different classing
why this was thrown in at a patch rather than during the major upgrad from 6.13 to 6.14 - well, guess just either someone missed some deadline or the report and change was created and worked on after 6.14 was frozen - or for whatever reason anways

point was and is: from the commit we now know its just a different classing which results in different naming - from ENxxx for ethernet to WWxxx for mobile modem - how this will affect things downstream I guess depends on how things handled from that point on
if one just still uses it as it would be yet another ethernet nic I guess neither the classing nor the resulting naming should impact anything other than some configs have to be updated - as shown by my systemd-networkd example
I guess the real issues now will start - or were fixed by this commit - are if one has to deal with an actual modem like a mobile surfstick which has to be configured by modemmanager and maybe setup some PPP connection
using usb-tether on a phone should not be affected at all as pretty much in all cases even back to the iPhone4 around 2010 when jailbreaking was still required for tethering what's reported back to a pc is just some "generic standard nic" usually offering DHCP to auto-config an IP and routing information - which OPs issues is all about (at least from how I understand it)

actually google the device brings up https://www.amazon.com/dp/B0793318VJ - so the commit seem to refer to an issue which seem to had the problem in reverse: instead of being detected as a modem proper it was just detected as an ethernet nic and hence whoever reported this seem to had issues to properly configure that device
for what its worth: that device was likely designed with some windows-only control-software as the very first comment states

It works, appearing as a standard USB2 Ethernet Port (no special driver needed)

so obviously this wouldn't even work on windows without some special additional software to unlock the sim and setup the APN and all that stuff - comming all the way back around full circle: SOMEONE with some old designed-to-be-used-with-windows-only device raised an issue - and SOMEONE ELSE decided to modify something rather deep within the stack with such WIDE results maybe not even considered or bothered proper testing - for what? that thousands upon thousands users now have to suffer from such issues and that ONE user who initially raised the issue maybe already using something different - and hey, good news everyone - we will now drag this change along forever to eternity because "no regressions!"

sorry seth - we had this on antoher topic and we ended up here again: some supposed-to-be-minor tweak for some already EOL hardware resulting in an big avalanche causing issues for some number of people somewhere between 3 and 7 digits - and it's "forbidden" to revert this because "oh no we would break compatibility for this one very specific device noone uses anymore"
same as with all this decade old hardware maybe not existing anymore - the entire kernel base should be cleaned up of all this junk - if someone wants to live in the past - fine - so be it - but then it should be that one user using some 20 year old 2.4 kernel instead of millions of users and servers having to suffer from dragging along all this crap - in this the linux kernel is just as bad as windows: when you know where to look you can still find a win3.x style file dialog even in Win11 - for the very same reason
this commit should be reverted as it breaks more than it solves - its as simple as that
I had something similar myself when some change to the ahci driver disabled my HBA - because some devs thought it not be worth waiting for some timeout - luckly they accepted that waiting for some timeout is less of a problem than having other hardware fail completely no matter its the hardware's OEM fault by not implementing the specs correctly
or the one time when that one change for the audio-over-usb driver caused many usb-interfaces to either not work properly or not at all - it was supposed to be a minor fix yet caused quite a lot of issues
or the problem with amdgpu about a year ago where warm reboot not worked properly
should I continue this list?
I quite frustrates me how low the quality of kernel developing has dropped so that such far reaching minor tweaks get upstream without proper testing - and in this very case without proper research and rejection because of hardware EOL - and never designed to be used with linux anyway

an no - this time you will get that wall of text instead of me just cowardly editing it down to a simple "was done on 6.14.2" - some things just have to be said - and this is one of them - if it wouldn't be for ZFS and all that Win11 crap I would had moved back long ago - guess Win12 will be the point if I decide to change back and give ReFS on StorageSpaces a try

BEST8OY · 2025-04-13 00:22:52

seth wrote:

Yup. Though I'd hope that using ModemManager is only optional here…

I couldn't make it work with NM and MM
NM needs MM to detect Mobile broadband
MM couldn't detect my phone (https://wiki.archlinux.org/title/Mobile … _the_modem)
I tried whitelisting with udev and it just didn't work! (With the exact same errors in the wiki)
So, in the end I had to go with sd-nd + iwd

Last edited by BEST8OY (2025-04-13 00:25:00)

seth · 2025-04-13 07:42:46

I tried whitelisting with udev and it just didn't work!

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855

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

BEST8OY · 2025-04-13 10:04:30

seth wrote:

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
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

What do you mean?

I linked to what I did!
did you read it? ("Couldn't check support for device" and "not supported by any plugin") I got these errors in ModemManager service logs
Again:
https://wiki.archlinux.org/title/Mobile … _the_modem

Wiki:
"If you get error messages such as Couldn't check support for device and not supported by any plugin, you may have to whitelist your device using the ModemManager filter rules."
Which links to here
https://www.freedesktop.org/software/Mo … ilter.html

Last edited by BEST8OY (2025-04-13 10:04:53)

tekstryder · 2025-04-13 12:13:01

tekstryder wrote:

    Fixes: 63ba395cd7a5 ("rndis_host: support Novatel Verizon USB730L")

cryptearth wrote:

why this was thrown in at a patch rather than during the major upgrad from 6.13 to 6.14 - well, guess just either someone missed some deadline or the report and change was created and worked on after 6.14 was frozen - or for whatever reason anways

From the 6.14.2 commit you can see the Fixes tag pointing to this commit from 2017:

https://www.mail-archive.com/netdev@vge … 90500.html

You can see here, it took a couple tries to get the Fixes tag added and correctly formatted. That's kernel development. It can be finicky.

tekstryder · 2025-04-13 12:28:14

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.

@seth: Your eye's will roll further noting this was a stable commit (there were 726 of them in 6.14.2 due to 6.15 merge window), thus landing also in the 6.12.23 LTS release:

• https://git.kernel.org/pub/scm/linux/ke … 071eb80f02

...and trickled down the LTS stream as far as the 6.1.134 longterm kernel.

seth · 2025-04-13 12:32:15

did you read it?

Yes. If you used the example in the sublinks literally, it won't work.
If you forgot to reload the rules, they won't apply.
This is why you're supposed to detail what /you/ did /exactly/ - not what some wiki examples illustrate…

Did *you* read the sticky I linked?

giou · 2025-04-13 12:48:29

I can confirm after downgrading to 6.14.1-zen1-1-zen it works again.

BEST8OY · 2025-04-13 14:42:01

seth wrote:

This is why you're supposed to detail what /you/ did /exactly/

So here is the details
I made the 78-mm-allowlist-internal-modem.rules file
Changed idVendor and idProduct (lsusb)
then
sudo udevadm control --reload
sudo udevadm trigger
then
sudo systemctl restart ModemManager NetowrkManager
But I still get the same errors

lsusb result "Bus 001 Device 006: ID 05c6:9024 Qualcomm, Inc. Xiaomi Mi 9 Lite"

Udev rule like the example

ACTION!="add|change|move", GOTO="mm_allowlist_internal_modem_end"
ATTRS{idVendor}=="05c6", ATTRS{idProduct}=="9024", ENV{ID_MM_DEVICE_PROCESS}="1"
LABEL="mm_allowlist_internal_modem_end"

And I still get these logs for ModemManager

Apr 13 17:59:49 DIAMOND systemd[1]: Starting Modem Manager...
Apr 13 17:59:49 DIAMOND ModemManager[35435]: <msg> ModemManager (version 1.24.0-1) starting in system bus...
Apr 13 17:59:49 DIAMOND systemd[1]: Started Modem Manager.
Apr 13 17:59:53 DIAMOND ModemManager[35435]: <msg> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3': not supported by any plugin
Apr 13 17:59:53 DIAMOND ModemManager[35435]: <msg> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:14.3': not supported by any plugin
Apr 13 17:59:53 DIAMOND ModemManager[35435]: <msg> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1d.0/0000:02:00.0': not supported by any plugin

seth · 2025-04-13 19:45:27

Add

, RUN+="/usr/bin/touch /tmp/udev.proof"

to the rule to check that it applies and post your complete system journal for the boot covering this, eg.

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

for the previous ("-1") one.

BEST8OY · 2025-04-14 10:16:02

@seth
Here is the log
https://paste.rs/uzoi2.bash
I have udev.proof in /tmp but it is empty! is it how it should be?

Last edited by BEST8OY (2025-04-14 10:16:18)

seth · 2025-04-14 14:03:13

is it how it should be?

"man touch"; tl;dr - yes. This just creates a file so you can track whether the rule ever fires (apparently) or is maybe skipped by some other rule (not the case)

Please avoid pastebins services that only hand out html - the command in #23 would have made both our lives easier.

Apr 14 13:38:09 DIAMOND kernel: rndis_host 1-3:1.0 wwan0: register 'rndis_host' at usb-0000:00:14.0-3, Mobile Broadband RNDIS device, 62:c3:fe:ca:ad:99
Apr 14 13:38:09 DIAMOND kernel: usbcore: registered new interface driver rndis_host
Apr 14 13:38:09 DIAMOND mtp-probe[1697]: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
Apr 14 13:38:09 DIAMOND mtp-probe[1697]: bus: 1, device: 4 was not an MTP device
Apr 14 13:38:09 DIAMOND kernel: rndis_host 1-3:1.0 wwp0s20f0u3: renamed from wwan0
Apr 14 13:38:09 DIAMOND iwd[746]: udev interface=wwp0s20f0u3 ifindex=5
Apr 14 13:38:09 DIAMOND ModemManager[815]: <wrn> [plugin-manager] task 2: port context already scheduled
Apr 14 13:38:13 DIAMOND ModemManager[815]: <msg> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3': not supported by any plugin

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.
Then please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

Arch Linux

#1 2025-04-12 08:21:52

USB tethering not working after updating to latest kernel

#2 2025-04-12 14:54:02

Re: USB tethering not working after updating to latest kernel

#3 2025-04-12 15:17:46

Re: USB tethering not working after updating to latest kernel

#4 2025-04-12 16:17:59

Re: USB tethering not working after updating to latest kernel

#5 2025-04-12 17:14:49

Re: USB tethering not working after updating to latest kernel

#6 2025-04-12 17:21:59

Re: USB tethering not working after updating to latest kernel

#7 2025-04-12 17:27:37

Re: USB tethering not working after updating to latest kernel

#8 2025-04-12 18:54:42

Re: USB tethering not working after updating to latest kernel

#9 2025-04-12 19:25:19

Re: USB tethering not working after updating to latest kernel

#10 2025-04-12 20:57:37

Re: USB tethering not working after updating to latest kernel

#11 2025-04-12 21:00:06

Re: USB tethering not working after updating to latest kernel

#12 2025-04-12 21:14:00

Re: USB tethering not working after updating to latest kernel

#13 2025-04-12 21:38:10

Re: USB tethering not working after updating to latest kernel

#14 2025-04-12 23:20:08

Re: USB tethering not working after updating to latest kernel

#15 2025-04-13 00:22:52

Re: USB tethering not working after updating to latest kernel

#16 2025-04-13 07:42:46

Re: USB tethering not working after updating to latest kernel

#17 2025-04-13 10:04:30

Re: USB tethering not working after updating to latest kernel

#18 2025-04-13 12:13:01

Re: USB tethering not working after updating to latest kernel

#19 2025-04-13 12:28:14

Re: USB tethering not working after updating to latest kernel

#20 2025-04-13 12:32:15

Re: USB tethering not working after updating to latest kernel

#21 2025-04-13 12:48:29

Re: USB tethering not working after updating to latest kernel

#22 2025-04-13 14:42:01

Re: USB tethering not working after updating to latest kernel

#23 2025-04-13 19:45:27

Re: USB tethering not working after updating to latest kernel

#24 2025-04-14 10:16:02

Re: USB tethering not working after updating to latest kernel

#25 2025-04-14 14:03:13

Re: USB tethering not working after updating to latest kernel

Board footer