FS#79655 - networkmanager 1.44.0-1 + ppp 2.5.0-1 don't play nicely with renamed nm connections

Attached to Project: Arch Linux
Opened by Bill Sideris (bill88t) - Monday, 11 September 2023, 15:08 GMT
Last edited by Toolybird (Toolybird) - Tuesday, 12 September 2023, 20:46 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


First things first.
Thinkpad T480 and a 2-month-ish setup w/ KDE.
Nothing special (like manual configs) done with either of those packages.

I have configured a "Hotspot" connection via KDE, that I use frequently.
And it has worked flawlessly up till those upgrades.

I installed the updates like regular and restarted my system.
All fine and dandy till I decided to enable the AP like regular.

It started up and worked till the first device connected.
Then.. "wait, where my nm applet go?"
nm had segfaulted, and even left the dnsmasq process behind.

After killing dnsmasq to free the ip range and restarting nm, I tried again only for the same thing to happen.
I then downgraded nm instinctively to 1.42.6-1 and life is good.
I came here then, to see and potentially report it (it's my first bug report in here), but I found  FS#79642 , which seems quite similar.
Weirdly enough, if I upgrade nm back to 1.44 and downgrade ppp to 2.4.9-3, the issue doesn't happen.
It only happens when both nm and ppp are on latest.

Additional info:
* networkmanager 1.44.0-1 / 1.42.6-1
* ppp 2.5.0-1 / 2.4.9-3

Steps to reproduce:

It's probably related to kde and nm renamed connections.
- Have an arch + kde setup with everything on the latest version.
- Make a custom networkmanager connection.
- Rename that connection.
- Have something connect to that connection?
- Segfault!

Do keep in mind, that after an nm crash on a AP connection, dnsmasq is effective a zombie process, blocking the connection from restarting by keeping the ip range to itself.
You have to kill it to retry.
This task depends upon

Closed by  Toolybird (Toolybird)
Tuesday, 12 September 2023, 20:46 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#79658 
Comment by Peter Wang (PeterWang-dev) - Monday, 11 September 2023, 16:12 GMT
Same thing happened to me. Moreover I found wifi connection broke and kernel dumped from time to time.
Comment by Toolybird (Toolybird) - Monday, 11 September 2023, 21:45 GMT
> nm had segfaulted

Note also  FS#79658  (maybe related, maybe not). Anyway, can you please post a backtrace containing debug symbols [1]? It's often as simple as this (with gdb installed):

$ coredumpctl gdb (then answer y when it asks "Enable debuginfod for this session?")
(gdb) set logging enabled
(gdb) bt (or bt full)

Then post gdb.txt

But the chances are this is all ppp related i.e.  FS#79639   FS#79642 

[1] https://wiki.archlinux.org/title/Debugging/Getting_traces
Comment by Bill Sideris (bill88t) - Monday, 11 September 2023, 23:17 GMT
Alrighty, here you go. I made a fresh one, with everything updated. I added some more stuff, just to make sure.
I tried also downloading the debug symbols for glibc, but those weren't used it so seems. I don't know how to force it to use them and populate the whole thing.
Note: I haven't used the systemd coredump stuff before.
I hope this helps.
Comment by loqs (loqs) - Monday, 11 September 2023, 23:49 GMT
Looks to be  FS#79658  from the backtrace. Can you reproduce with glib2 2.78.0-2?
Comment by 2000 (Utini) - Tuesday, 12 September 2023, 09:23 GMT
So maybe my problem is related to this too. Sounds like a similar issue:

Comment by Peter Wang (PeterWang-dev) - Tuesday, 12 September 2023, 16:26 GMT
Solved. Not a bug but because glib update after nm update.
Comment by Bill Sideris (bill88t) - Tuesday, 12 September 2023, 20:44 GMT
I have been trying to make it happen again all day after upgrading glib2 to 2.78.0-2, without success.
So it was just glib2 at fault I guess.