network-applet hangs Budgie after vpn connection

[mark-nicholson]

Summary

After the major update on 2023-10-27 the system worked fine until I tried the VPN to get to work this morning.

Steps to reproduce

1. clean boot of system
2. right-click on network-applet on the task bar
3. select "VPN" and choose my normal work VPN entry
4. open-connect window opens, negotiation begins
5. the "VPN connected" window does not appear
6. The Icon of the network applet freezes with the "vpn connect spinner and the lock"
7. If I right-click on that network-applet, the ENTIRE desktop freezes

I have figured out that if I press Ctrl+Alt+Delete, after a few seconds, I can regain access to the other desktop windows

Expected result

The VPN should connect as usual. I have not modified my connection profile in a very long time and it has worked flawlessly for over a year. No known changes to the VPN server at my work.

Actual result

The VPN does not connect. ip addr show does not display the VPN interface.
The desktop completely hangs (Initially was able to switch to a console to start debugging, then found that Ctrl+Alt+Del in the GUI would eventually get back to partial functionality)

Noticed:

root # ps auxww | grep open 
mjnichol    3101  0.0  0.0      0     0 ?        Z    08:24   0:01 [nm-openconnect-] <defunct>
root        3595  0.0  0.0 222524  2304 pts/1    S+   09:02   0:00 grep open
root #

which appears to show the nm-openconnect became a zombie process. The system was clean from a reboot and had no openconnect processes at all.

Environment

• Is system up to date?

Repo

Shannon (stable)

Desktop Environment

Budgie

System details

Hardware Model: Dynabook Inc. PORTEGE X40-J
Memory: 32.0 GiB
Processor: 11th Gen Intel® Core™ i7-1185G7 × 8
Graphics: Intel® Xe Graphics (TGL GT2)
Disk Size: 512.1 GB
Bugdie Version: 10.8.2
OS Name: Solus 4.4 Harmony
OS Type: 64-bit
Windowing System: X11
Kernel Version: Linux 6.5.9-262.current

(would be nice to have a copy-info button in the "About" applet)

Other comments

This problem is significant for me as I tried to do:

sudo eopkg history --yes -t 467

to get back to the state of the system last week -- which worked fine -- but that failed. (Other ticket filed.)

[mark-nicholson]

I finally got this to work without any quirks.

It seems that the newer version of the software (not sure if it is NetworkManager or OpenConnect) was having problems with the actual "profile" file. It seems that it crashed when it loaded the profile and didn't like something.

I removed the profile in NetworkManager (then double checked the file-system to ensure it was really gone) then re-created a new VPN profile... bingo, it works again.

The issue seems to be just an incompatibility between the profile storage formats between the versions.

It would be nice to have it recognize the "old" format and either disable that profile with some sort of notice to the user, or "re-write" the file in the new format quietly.

I'd been using the same VPN configuration file for probably, at least, the last 12 months.

[ermo]

@EbonJaeger How do we want to tackle this (if at all?)

[EbonJaeger]

@ermo I suspect that it happening on Budgie is incidental and the problem is something (an incompatible config, or a bug) in networkmanager or networkmanager-applet.

Unless there is a patch somewhere to pull in, I don't see anything for us to do.

[EbonJaeger]

It also sounds like this is solved on our end, already.

[TraceyC77]

I'm closing this as it appears to be a bug with Network Manager hanging with something in the old config file.
If you would like NM to support the old format or auto recover as you describe, I suggest heading to the [Network Manager}(https://gitlab.freedesktop.org/NetworkManager/NetworkManager) project, and search their issue tracker. I did see this issue which appears to possibly be related to the same behavior.