Network Manager should only request new secrets during the initial connection for wired interfaces

Bug #1272321 reported by Michael Schaller on 2014-01-24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Mathieu Trudel-Lapierre

Bug Description

Hi everyone,

Network Manager received a patch so that it only requests new secrets during the initial connection for WiFi connections in 2012:

This patch has been ported for wired connections:

Can we include the upstream patch for wired connections in Trusty?
(The patch for WiFi connections is already present)


Michael Schaller

Michael Schaller (misch-9) wrote :
description: updated
Michael Schaller (misch-9) wrote :
Michael Schaller (misch-9) wrote :

Subscribed sponsors. Please let me know if there are any questions.

Unsubscribing sponsors, I'll sponsor this shortly along with a bunch other fixes.

Changed in network-manager (Ubuntu):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Michael Schaller (misch-9) wrote :

Thank you, Mathieu. ^^

I haven't forgotten about this, just having some issues with the build for armhf, tests aren't passing...

This makes me think however, isn't that going to break the case where the secrets expire for the wired connection? What happens if you need to change to a different password, either because it is an 802.1x network secured with RADIUS, say with an RSA Securid token.

That would affect wifi too, of course...

I'm only saying this to keep a trace somewhere, since it's already upstream it would be a matter of filing a bug if there is ever a major issue caused by these changes.

Michael Schaller (misch-9) wrote :

Mathieu, that is an excellent question that Dan Williams covered in his commit for WiFi connections:
"Otherwise we assume the secrets good; if they aren't, the user should change them through a configuration editor."

Looking at the Network Manager code itself it doesn't have much choice as currently it doesn't get any error information from WPA supplicant. In fact the way how Network Manager handles WPA supplicant errors is not good at all. Basically Network Manager gives WPA supplicant 25 seconds to finish the authentication. Without these two patches Network Manager just assumes on timeout that the secret was bad and asks repeatedly to correct the secret. But this behavior is frustrating for the users as there are of course a lot more issues than just a bad secret that can cause WPA supplicant to fail... These two commits change the behavior so that Network Manager only asks to correct the secret if the connection wasn't successful so far. I personally think that the new behavior is still not good but at least it is a bit better than the previous behavior.

IMHO to fix this issue one would need to change WPA supplicant to properly export errors via its D-Bus interface and then Network Manager needs to be changed to react properly depending on the actual WPA supplicant error.

Michael Schaller (misch-9) wrote :

Mathieu, how does it look with NM and this patch? Did my explanation make sense to you?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager -

network-manager ( trusty; urgency=medium

  * debian/tests/urfkill-integration, debian/tests/killswitch, debian/tests/nm:
    really fix the tests this time, hopefully.
 -- Mathieu Trudel-Lapierre <email address hidden> Thu, 20 Feb 2014 21:23:35 -0500

Changed in network-manager (Ubuntu):
status: In Progress → Fix Released
Michael Schaller (misch-9) wrote :

Thank you, Mathieu.

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

Other bug subscribers