Ubuntu
network-manager-applet package

network-manager-applet: stored auto connect VPN gets changed when viewing settings

Bug #1935604 reported by Joe Bauser
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager-applet (Ubuntu)
New
Undecided
Unassigned

Bug Description

Xubuntu 20.04.2 LTS focal
Applet version from network-manager-gnome 1.8.24-1uubuntu3 amd64

Please note: the issue described below only seems to occur when building the applet on my xubuntu 20.04.2 LTS machines. (I have not tried other ubuntu variants).

If I'm on my home xubuntu machine the problem seems to appear whether I'm using the ubuntu package, the ubuntu source archive, the upstream archive, or the upstream source distribution.

The problem does _not_ seem to occur when building the exact same upstream sources in debian using xfce as its window manager. (I have not tried other debian variants).

Experienced

If I open an existing connection with an existing VPN, the selected VPN in the VPN drop down list appears to always show the incorrect VPN. This results in a situation where opening a connection and clicking "save" on the general tab always changes the selected VPN, even if I did not make any change.

Expected

When I open an existing connection, the VPN listed should be the VPN actually on the connection, not some other random VPN from my list

Reproduction Steps

1. Open nm-connection-editor
2. Add multiple VPNs with different names (i.e. US VPN East, US VPN West, Corp VPN East, Corp VPN Europe, Corp VPN West)
3. Create a connection (I've reproduced this on wireless and wired connections)
4. Set the connection to automatically connect to VPN
5. Choose any VPN to automatically connect to
6. Save and close
7. re-open nm-connection-editor
8. Edit the same connection created before
9. Note that the automatic VPN has changed to a different VPN in your list without you having to do antying
10. Click save without changing anything
11. re-open network-manager-editor
12. Note again that the VPN connection is _again_ incorrect

The symptom you should be experiencing is that the VPN that is chosen when you save - gets saved and used by the connection, but the user interface does not display the correct VPN when viewed in the connection editor. This means that any time you edit the connection it might be swapping your selected VPN without your knowledge.

Tags: patch
Revision history for this message
Joe Bauser (coderjoe+ubuntuone) wrote :

I've created a virutal machine which expresses the bug in Xubuntu 20.04.02 from a fresh install. You'll need to log in as the user "user" with the password "password". In order to experience the bug you'll need to change and save the VPN once, then you should be able to follow the instructions above.

Hopefully having this virtual machine will make it a little easier to identify the cause. I've so far been unable to identify what could possibly be causing it.

The VM export in ova format can be found here:

http://files.coderjoe.net/Xubuntu.ova

Revision history for this message
Joe Bauser (coderjoe+ubuntuone) wrote :

For anyone who may not want to download the full ova just to see the bug, I've created a screen recording of the bug as I experience it.

It can be viewed here: https://www.youtube.com/watch?v=RVFoaiHCto8

From the video description to give some context to what I'm demonstrating in the video:

A demonstration of an nm-connection-editor bug I'm experiencing. For some reason the saved VPN does not persist across future saves even if I change nothing in the dialog. Simply saving the dialog is enough to trick it into swapping behind the scenes.

This video demonstrates 2 things:

1. The first demo shows that when the VPN selected is "Vancouver" then every time the dialog is saved the stored VPN is changed.
2. When Vancouver is selected it rotates only through "Vancouver", "US West", and "Corp - UK London"
3. If either of the remaining 2 VPNs are chosen ("Corp - Hong Kong" or "US East") then they do NOT exhibit the bug.
4. Swapping back to any of the original 3 causes the bug to express again.

To test the bug locally it's enough to create 5 VPNs with the same names as mine. They need not be fully functional as you don't need to connect to the VPN to trigger the bug.

Revision history for this message
Joe Bauser (coderjoe+ubuntuone) wrote :

I started experimenting with Xubuntu 21.04 hirsute I've noted the following things:

1. The default hirsute install currently installs newer versions of network-manager dependency packages (1.30.0-1ubuntu3) with the sole exception being network-manager-gnome
2. The default hirsuite installed version of network-manager-gnome is 1.18.0-1ubuntu2 which is very similar in version to the 1.18.24 in Xubuntu 20.04.02

When network-manager-gnome-1.18.0 is installed in hirsute my bug is replacable.
If I upgrade to network-manager-gnome-1.22.0 from impish (which I can do on hirsute thanks to the higher dependency package versions) the bug disappears and everything appears to work.

Upstream has also seemed to imply in my original bug report to them that work had been done as of 1.22 of the upstream packages which might have fixed my bug.

My experience seems to suggest that my problem is already solved as of network-manager-gnome-1.22.0, but it looks like 1.22 hasn't been backported to focal. What would it take to backport 1.22.0 to focal for those of us stuck on LTS releases?

Revision history for this message
Joe Bauser (coderjoe+ubuntuone) wrote :

After some experimentation I have found that applying the following commits from the upstream 1.22 version of the pacakge to the focal/devel branch of network-manager-applet appears to fix the bug.

1. `768eb7dfa974bd3255e0062b1e9f191b731aefbe` c-e: fix initializing drop-down-list for connection.secondaries
2. `da6b2bb94250d8ffb218caf921c9df8c394372d4` editor: fix crash when evaluating secondaries
3. `8183932d985e4ca7c17bafb2cbaddb1ed5d5d6b8` editor: fix vpn tree sort parameters

(the final commit I added only to simplify my debugging, I have not tested without it)

I have no prior experience with debian or ubuntu package contributions, so I'm not entirely sure how to contribute these potential backported changes as patches to the package. I would very much welcome any suggestions.

Please note that as these patches are just backports of specific commits from upstream they would not be necessary if the entire 1.22 version of the package could be made to work on focal.

Revision history for this message
Joe Bauser (coderjoe+ubuntuone) wrote :

Attaching the patches I've used to test the fix. I've generated these patches via `git format-patch -1 HASH` from upstream for each of the above listed commit hashes.

Revision history for this message
Joe Bauser (coderjoe+ubuntuone) wrote :
Revision history for this message
Joe Bauser (coderjoe+ubuntuone) wrote :
Revision history for this message
Joe Bauser (coderjoe+ubuntuone) wrote :
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "0001-c-e-fix-initializing-drop-down-list-for-connection.s.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
coderjoe (coderjoe) wrote :

After some prompting it was suggested I attach a debdiff of the above patches applied on 1.8.24-1ubuntu4. I've tested locally on my machine and it appears to work, as well as fix the bug I experienced.

I'd much prefer to backport the existing 1.22 package but there were too many updated package dependencies for me to get it working.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.