[MASTER] Endlessly many "Wireless Network Authentication Required" dialogs put up

and here is another screenshot

I have similar problem. It looks like nm-applet lost access to the gnome-keyring and now every time is asking for wireless key, does't remember it, and seemengly spawns the dialog asking for the key indeffinately.. I didn't count the number of windows, but had to click close for quite a while before it went away.

It could conect to the router just fine before, now suddenly (after holidays) started to ask for the key.

Same symptoms here, but it has always been that way ever since installing 11.10 -- whenever the machine can't connect to the wireless access point (there are some genuine wifi issues where I am), it pops up a new authentication window every few minutes. Could it be the window is not appropriately application-modal? (or whatever it's called these days...)

Hi...I made my WiFi a personal hotspot.with its own security code.and have
it come on as soon as I logged in...no more authentication problems..thanks

On Mar 26, 2012 12:50 PM, "Asaf Bartov" <email address hidden> wrote:

Same symptoms here, but it has always been that way ever since
installing 11.10 -- whenever the machine can't connect to the wireless
access point (there are some genuine wifi issues where I am), it pops up
a new authentication window every few minutes. Could it be the window
is not appropriately application-modal? (or whatever it's called these
days...)

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/912702

Title:
 the window "Wireless Network Authentication Required" keeps popping up
 until "the end of times" even though the previous one was not closed

Status in “network-manager-applet” package in Ubuntu:
 Confirmed

Bug description:
 I left the computer turned on for the night and in the morning I found
 not less than 65, yes 65!!!!!! instances of the same window. my system
 was responding very slowly. and closing one took more than a minute,
 so I had to kill it manually. take a look on my screenshots, they look
 really weird.

 this is very annoying!!!!

 solution: this window shouldn't pop up when the previous one was not
 closed!

 ProblemType: Bug
 DistroRelease: Ubuntu 11.10
 Package: network-manager-gnome 0.9.1.90-0ubuntu6
 ProcVersionSignature: Ubuntu 3.0.0-14.23-generic 3.0.9
 Uname: Linux 3.0.0-14-generic i686
 ApportVersion: 1.23-0ubuntu4
 Architecture: i386
 CRDA: Error: [Errno 2] No such file or directory
 Date: Fri Jan 6 11:38:28 2012
 ExecutablePath: /usr/bin/nm-applet
 Gconf:

 IfupdownConfig:
  auto lo
  iface lo inet loopback
 InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta i386 (20110921.2)
 IpRoute:
  default via 158.195.192.1 dev eth0 proto static
  158.195.192.0/19 dev eth0 proto kernel scope link src
158.195.196.69 metric 1
  169.254.0.0/16 dev eth0 scope link metric 1000
 Keyfiles: Error: [Errno 2] No such file or directory
 NetworkManager.state:
  [main]
  NetworkingEnabled=true
  WirelessEnabled=true
  WWANEnabled=true
  WimaxEnabled=true
 ProcEnviron:
  SHELL=/bin/bash
  PATH=(custom, no user)
  LANG=en_US.UTF-8
 SourcePackage: network-manager-applet
 UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/912702/+subscriptions

It's been six months since this bug was reported, its importance remains undecided, and fixing it remains unassigned. This is a problem. Whenever my machine is disconnected from wi-fi for a few hours, it is faster to reboot than to close the dozens of nm-applet authentication windows trying to connect to alternative wi-fi networks. This drives me nuts.

Yes, you're right. Still nothing has changed about this, the bug continues to present itself in 12.04 too.

KALImar Franklin (kalimar999), please how did you make you wifi a personal hotspot, or something? And is it a convenient solution?

The Only thing I did was plug in my wifi equipment...and Ubuntu ran a scan
asking me did I want to use a coded password..I put in my password setting
Ubuntu to a personal hotspot on my computer so no one would still my wifi
usage..After doing a private security PW, I set wifi to come on
automatically when I logged in..I had NO further issues

On Jun 26, 2012 8:30 PM, "zsolt.ruszinyák" <email address hidden>
wrote:

KALImar Franklin (kalimar999), please how did you make you wifi a
personal hotspot, or something? And is it a convenient solution?

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.l...

I went under Network Connections then edit in Wireless.setting private
password and personal hotspot

On Jun 26, 2012 8:30 PM, "zsolt.ruszinyák" <email address hidden>
wrote:

KALImar Franklin (kalimar999), please how did you make you wifi a
personal hotspot, or something? And is it a convenient solution?

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.l...

In this particular cas eduroam isn't working. I'm not sure I've ever seen it work, but it really ought to. Can you please verify that you're using the right credentials and start NetworkManager in debug mode?

Please follow the steps in http://wiki.ubuntu.com/DebuggingNetworkManager to attach more information to this bug report.

As for the multiple window instances, that's covered in another bug. It's unfortunate, but not something that can be easily fixed. If the connection is stable and doesn't disconnect frequently due to bad signal levels or other reasons, then you won't be seeing multiple authentication requests -- this is only because there is no easy way to distinguish between the different reasons for a disconnection.

Present in Lubuntu 12.04 too. See attachment (image). Terminal output:

nm-applet
** Message: applet now removed from the notification area
** Message: using fallback from indicator to GtkStatusIcon
** Message: applet now embedded in the notification area
** Message: No keyring secrets found for WIRELESSNETWORKNAME; asking user.

After I get:
Trådlöst nätverk
Frånkopplad

@"Myself" comment #13
Wireless network
disconnected

Workaround for not nm-applet asking for the keyring all the time is to go to NetworkManager (nm-connection-editor) & remove wireless networks that are not currently in use or those wireless networks one doesn't have access to.

@Mathieu:

What is the other bug that describes the issue with multiple window instances? The other bug that I know of is bug 923737, which is marked as a duplicate of this one. Which is the correct bug for tracking multiple window instances?

(I left a computer running for a week, when I came back to it there were >300 authentication dialogs onscreen)

I can't find it anymore. We'll just use this one.

This is ridiculous super annoying. It's pissing off my wife who I'm trying to convert to linux and it's pissing off me. I know there are tons of other people who are annoyed but not advanced enough to post this as a bug or in a forum... “oh linux... yeah, that thing that makes those annoying windows pop up while I'm asleep , and then have to wait for my computer to reboot my every morning. Never had that trouble while I was on Windows.

The code for showing this dialog is rather ugly.

It even has a function show_ignore_focus_stealing_prevention() which is bad X11 citizenship.

A patch to get rid of such things, use gtk_window_set_urgency_hint() instead, and keep track of the dialogs would allow whatever problem is causing multiple dialogs to be ignored for a while longer.

I can confirm that Linux Mint 13 (Cinammon) is also affected. Opens tons of "Wireless Network Authentication Required" dialogs while I'm away.

Well, the dialog could just not pop up if there is one already open...

Upstream commit

 http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=30fe3e18766367d159dfb16d7ca5559d7dc58b9a

should fix this issue.

Please don't set committed for Ubuntu if you haven't checked if a fix is actually committed.

@Marius

The fix is committed upstream so I have set it to fix committed in Ubuntu so the package maintainers can spot the fix committed and take action. This is the procedure for upstream bugfixes.

That is incorrect. Fix committed for Ubuntu means a fix is available in a launchpad branch and is usually set automatically. The bug watcher will soon update and indicate that a fix is committed upstream.

Actually, the commit that fixes this bug is released in Raring now: https://launchpad.net/ubuntu/+source/network-manager/0.9.6.0+git201301021750.e78c3e8-0ubuntu1. It is from upstream e78c3e83d2e0b49641c9d484e0b35b3c6ff9f0db which contains the fix commit.

The fix should probably be backported. As a workaround, the raring package might be able to use in earlier versions too, or it is possible to use the daily built packages at: https://launchpad.net/~network-manager/+archive/trunk

I still have this problem. It came about recently, was not fixed in the update.

I still have this problem too... any workaround?=

$ uname -a
Linux diego-toshiba 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Marius,

  From #25, I found the patch from upstream is not related to this issue.

commit e78c3e83d2e0b49641c9d484e0b35b3c6ff9f0db
Author: Alban Browaeys <email address hidden>
Date: Wed Jan 2 10:37:36 2013 +0100

    build: negate the grep result. Not the echo result.

    https://bugzilla.gnome.org/show_bug.cgi?id=690991

diff --git a/configure.ac b/configure.ac
index f94d29c..84c36ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -278,7 +278,7 @@ AS_IF([test -z "$with_session_tracking"], with_session_tracking=consolekit)
 AS_IF([test "$with_session_tracking" = "ck"], with_session_tracking=consolekit)
 AS_IF([test "$with_session_tracking" = "none"], with_session_tracking=no)
 # check value
-AS_IF([! echo "$with_session_tracking" | grep -q -E "^(systemd|consolekit|no)$"],
+AS_IF([! (echo "$with_session_tracking" | grep -q -E "^(systemd|consolekit|no)$")],
        AC_MSG_ERROR([--with-session-tracking must be systemd/consolekit/no, not $with_session_tracking]))
 # add conditionals and subtitutions
 AM_CONDITIONAL(SESSION_TRACKING_CK, test "$with_session_tracking" = "consolekit")

Sorry, it should be the one in comment #21. Do you still reproduce this in Raring?

This bug is also present in Linux Mint 14 MATE.

I dont understand the solution...How can I put this into the terminal to
solve the problem? Thank U

On Wed, Mar 27, 2013 at 9:14 AM, SteveFoerster <email address hidden>wrote:

> This bug is also present in Linux Mint 14 MATE.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/912702
>
> Title:
> [MASTER] Endlessly many "Wireless Network Authentication Required"
> dialogs put up
>
> Status in One Hundred Paper Cuts:
> Fix Released
> Status in The Linux Mint Distribution:
> New
> Status in NetworkManager:
> Fix Released
> Status in “network-manager” package in Ubuntu:
> Fix Released
> Status in “network-manager-applet” package in Ubuntu:
> Invalid
>
> Bug description:
> I left the computer turned on for the night and in the morning I found
> not less than 65, yes 65!!!!!! instances of the same window. my system
> was responding very slowly. and closing one took more than a minute,
> so I had to kill it manually. take a look on my screenshots, they look
> really weird.
>
> this is very annoying!!!!
>
> solution: this window shouldn't pop up when the previous one was not
> closed!
>
> ProblemType: Bug
> DistroRelease: Ubuntu 11.10
> Package: network-manager-gnome 0.9.1.90-0ubuntu6
> ProcVersionSignature: Ubuntu 3.0.0-14.23-generic 3.0.9
> Uname: Linux 3.0.0-14-generic i686
> ApportVersion: 1.23-0ubuntu4
> Architecture: i386
> CRDA: Error: [Errno 2] No such file or directory
> Date: Fri Jan 6 11:38:28 2012
> ExecutablePath: /usr/bin/nm-applet
> Gconf:
>
> IfupdownConfig:
> auto lo
> iface lo inet loopback
> InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta i386 (20110921.2)
> IpRoute:
> default via 158.195.192.1 dev eth0 proto static
> 158.195.192.0/19 dev eth0 proto kernel scope link src 158.195.196.69 metric 1
> 169.254.0.0/16 dev eth0 scope link metric 1000
> Keyfiles: Error: [Errno 2] No such file or directory
> NetworkManager.state:
> [main]
> NetworkingEnabled=true
> WirelessEnabled=true
> WWANEnabled=true
> WimaxEnabled=true
> ProcEnviron:
> SHELL=/bin/bash
> PATH=(custom, no user)
> LANG=en_US.UTF-8
> SourcePackage: network-manager-applet
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/hundredpapercuts/+bug/912702/+subscriptions
>

--
*KALImar Franklin, Shamanistic Owner of KALImar's Inner Healing GAteways &
Publishing Owner of KALI's Sacred Sex... Both Entities are Copyrighted,
Registered & TradeMarked...ALL RIGHTS RESERVED....*

I'm still seeing this on Raring.

i'm seeing this in raring too (dual boot lenovo q190 with kernel 3.10 - the only way to get realtek rtl8188 working).

i tried to replace nm-applet with wicd without success (managed to screw up all networking by apt-get purging network-manager; restored it; removed wicd; am back to nm-applet).

can't find a workaround/solution anywhere. can't believe there hasn't been one for so long. help!

I had this problem last night. The cause in my case was that I changed the network password from another machine, and the machine that the problem was on was left on all night. When I got to it in the morning there were many dozens of "Wifi network identification required" dialogue windows open, which indeed won't go away very quickly. nm-applet is using a whole core all to itself, and not doing a lot. The wifi is in the meantime connected, but the dialogue boxes will not go away.

This is Ubuntu 13.10, 64bit.

Still having this issue in Ubuntu 13.10 x64. Added the Wi-Fi card recently. Completely makes it unusable as Wi-Fi breaks from time to time it means about hundred of windows per day and PC freeze after a while.

This clearly isn't fixed. Reopening, we have a different report with the same kind of issue and I wrote a patch that should fix it...

Updating the remote watch for the bug I reported for this; with a patch

NetworkManager itself appears to be resetting the number of retries for *all* "failed" connections regardless of what the cause for failure was, even if that failure was caused by missing secrets (what seems to be causing the prompt for entering the password again).

Now, this particular issue can come from buggy drivers which would pass the secret wrong or otherwise fail to connect to an access-point with an unusual or plain incorrect return code. We can't really account for these without special casing each driver. However, I was able to reproduce the issue and write a patch that seems to properly fix the authentication cases where the password in "incorrect" in NM or otherwise refused by the AP. When a connection fails because of missing secrets (e.g the user was prompted but never answered), the connection is properly marked as failed; then, after 5 minutes the connections that are failed because of "missing secrets" don't have their retries set back to 0 like the other failed connections, but rather will wait until an agent registers, at they should.

There is a test package being built at https://launchpad.net/~mathieu-tl/+archive/ppa/+sourcepub/3776171/+listing-archive-extra (my PPA). Please give it a shot and let me know if this fixes the issue acceptably.

Regardless of the underlying cause of the "authentication requested" dialog popping up, isn't the main issue just that nm should never pop up a new authentication request dialog if one's already open?

Kind of, but it's not as simple. It's multiple different pieces, NM doesn't itself generate any dialog box, it just asks the agent to do it. Regarless, 90% of it should be fixed with the package in my PPA, it just needs more testing.

Same problem here (Mint 14), whenever a secured connection has a weak signal. Of course, the immediate way to avoid waking up to a computer slowed down by hundreds of dialogs is to disable wireless overnight when in the presence of such a network, but that's not a good fix overall.

I agree that if the login information is missing or incorrect then Mathieu's fix is the right thing--just stop trying to connect until the user supplies new information. But in most cases where I have come across this bug the login information is already correct, and the issue is instead (as far as I can tell) that the signal isn't good enough to get it across reliably. In such a case it is preferable to just try again without consulting the user to verify the password.

Perhaps if it is hard to implement the "at most one dialog" approach, you could instead add a "don't ask me to authenticate for this network again" flag in the dialog? Ideally, this would turn just the relevant network from Mathieu's behavior (always ask and wait for authentication) to the bad signal behavior (always retry without asking). Of course, there should be a similar flag in the connection preferences (perhaps near "connect automatically") where this option could be unset.

No. It's generally a bad idea to add flags and checkboxes.

Please test the package I provided, it should address all the issues brought up for NetworkManager.

A failure caused by insufficient signal is handled very differently and will re-request the auth dialog -- this is why there is also a need to fix network-manager-applet.

I've been running the test package (network-manager 0.9.8.4-0ubuntu4~mtrudel1) from comment #38 for about a week. So far I have not seen a single authentication failed dialog. Normally I'd see at least 10 of the dialogs during this time period, if not many more. I have not noticed any bad side effects of the test package.

This bug was fixed in the package network-manager - 0.9.8.8-0ubuntu1

---------------
network-manager (0.9.8.8-0ubuntu1) trusty; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * New upstream release (LP: #1269179).
  * debian/control: add a Build-Depends on libmm-glib-dev.
  * debian/rules: configure with --with-modem-manager-1=yes. This enables
    support for the new ModemManager API.
  * Dropped patches (included upstream):
    - git_core_do_not_call_functions_with_null_connection_5e129f1.patch
    - bluetooth.patch
  * debian/patches/lp912702_fix_multiple_dialogs.patch: handle the case where
    multiple authentication dialogs would be shown if the user doesn't respond
    in time for network auth. (LP: #912702)

  [ Michael Schaller ]
  * ifupdown plugin: Support ifupdown's source stanza. (LP: #1271567)
 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 24 Jan 2014 12:35:34 -0500