Bug 431952

Summary: ModemManager takes over the active usb tether connection and traffic stops
Product: [Plasma] plasmashell Reporter: Michael <michael.hmich>
Component: Networking in generalAssignee: Jan Grulich <jgrulich>
Status: RESOLVED FIXED    
Severity: normal CC: nate
Priority: NOR    
Version First Reported In: master   
Target Milestone: 1.0   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Michael 2021-01-22 19:09:21 UTC
the active usb tethering connection stops, typical browser info then is: you have no network connection

there is no clear way to reproduz it but seems to happen more often with a idle connection, you read something and then want to go ahead and no connection, the tray network icon changes then to the wireless icon

it often happens when I activate the tethering option on the cellphone before the desktop is totally up and then it already comes up with the wireless icon

the only way to get it back is closing the tether connection on the cellphone and reactivate it

workaround is deactivating the ModemManager

thanks


System:    Host: hm-neon Kernel: 5.10.7-hmich-rt-ftl-2.32 x86_64 bits: 64 Desktop: KDE Plasma 5.20.5 
           Distro: KDE neon 20.04 5.20 
CPU:       Topology: Quad Core model: AMD Phenom 9550 bits: 64 type: MCP L2 cache: 2048 KiB 
           Speed: 2200 MHz min/max: 1100/2200 MHz Core speeds (MHz): 1: 2200 2: 2200 3: 2200 4: 2200 
Graphics:  Device-1: NVIDIA GK208 [GeForce GT 710] driver: nvidia v: 390.141 
           Display: x11 server: X.Org 1.20.9 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa 
           resolution: 1280x1024~75Hz 
           OpenGL: renderer: GeForce GT 710/PCIe/SSE2 v: 4.6.0 NVIDIA 390.141
Comment 1 Ben Cooksley 2024-12-23 18:23:34 UTC
Bulk transfer as requested in T17796
Comment 2 Nate Graham 2025-05-07 20:36:34 UTC
Thank you for the bug report! I'm sorry that we weren't able to get to it yet. Can you see if it's still an issue in Plasma 6.3.4 or later, and also presumably with a newer networking stack? Thanks a lot!
Comment 3 Bug Janitor Service 2025-05-22 03:47:19 UTC
๐Ÿ›๐Ÿงน โš ๏ธ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Michael 2025-05-22 10:03:59 UTC
(In reply to Bug Janitor Service from comment #3)
> ๐Ÿ›๐Ÿงน โš ๏ธ This bug has been in NEEDSINFO status with no change for at least 15
> days. Please provide the requested information, then set the bug status to
> REPORTED. If there is no change for at least 30 days, it will be
> automatically closed as RESOLVED WORKSFORME.
> 
> For more information about our bug triaging procedures, please read
> https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.
> 
> Thank you for helping us make KDE software even better for everyone!

well, quite old this one isn't it, kde's way of solving problems is time ๐Ÿ˜‚
anyway , the problem now is different ,but would probably need another report, working with two different connection types is problematic under kde , now the new activated connection gets hyjacked and kde tries to connect with the config of the former one , it is not using the new device configuration for it
Comment 5 Nate Graham 2025-05-22 15:31:56 UTC
If there's a new issue now, we'd need a new bug report for it, yeah. Thanks a lot for for following up!