Hi all. After a day's work of R&D, I think we could have discovered the solution for this irritating behaviour. Following are the details (built upon some of the details provided by Jerry in the previous mail-reply) ::: ################################################################################################# NM may (re-)request the secrets in the following cases :: a) Wifi connection is lost. (Yes, even if the AP is switched off permanently, the dialog-box keeps popping up periodically). b) After being lost, the wifi connection is again within the range. c) When the credentials for the wifi network change. Supposedly, for every case, the "request_new" parameter in "GetSecrets" method is True. Thus, in all the above cases, we would get the irritating dialog-box. Ideally, "request_new" should be True, only for case c). However, case c) is rare (and when it does happen, usually the system-administrator, or the like, has the responsibility for issuing the changes publically). Thus, due to case c) (which is rare), cases a) and b) were suffering (these cases are generally very plausible cases in everyday life). So now, the intended solution is ::: 1. Always return the cached secrets. This would make the irritating dialog-box go away, for cases a) and b). 2. For case c), the user would :: (i) "Discard Network History". (ii) Click on the wifi icon (in the neighborhood-view). (iii) Enter the new (publically broadcasted) credentials. ####################################################################################################### I am attaching the patch for brevity. NOTES ::: a) This has been tested to work as expected on dextrose3. b) I tried to do the same for the sugar-mainline branch (on F17). However, the code for "src/jarabe/model/network.py" is substantially different. Therein, there is no "class Secrets", which is used to cache the secrets. Also, there is no "load_wifi_connections" method. c) Could b) be due to the fact the System-Settings are being used for NM? If yes, we could still cache the secrets somehow in sugar, since anyways the secrets ARE received somehow upon automatic-wifi-connection-upon-reboot. d) If the solution seems ok, I will be happy to port the solution to sugar-mainline. Let me know :) Thanks and Regards, Ajay <div class="gmail_quote">On Thu, Jun 14, 2012 at 6:02 AM, Jerry Vonau <<a href="mailto:jvonau@shaw.ca" target="_blank">jvonau@shaw.ca</a>> wrote: <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Thu, 2012-06-14 at 18:44 +1000, James Cameron wrote: > Sridhar begins in the bug report by saying that the repeated prompt > for the WPA passphrase is due to losing connection. Is there other > evidence, other than the repeated passphrase prompt, to suggest that a > connection was lost? If so, what connection is it that is lost? > > When I last looked at this problem, Sugar was being asked by Network > Manager for the passphrase, and Sugar was immediately prompting the > user. > </div>I faked the loss of connection by powering down the AP until the loss was recorded by NM in /var/log/messages and powering the AP back up. Sugar did prompt for the passphrase, which is already recorded in ~/.sugar/default/nm/connections.cfg, so sugar is not re-reading its config file before prompting the user for input. If you were to cancel the dialog box for the passphrase and reselect the AP you are NOT prompted for the passphrase and the connection is re-established. I'll post /var/log/messages|wpa_supplicant.log from this test in the issue. <div class="im"> > Offhand I don't know what version of Sugar you are planning to ship > with your target version for 12.2, so I didn't bother digging into the > Sugar network model and view code for your version. > </div>Dextrose 3, based on sugar 0.94. <div class="im"> > But master in git has a SecretAgent in model/network.py that registers > itself with NetworkManager as an agent that can provide passphrases to > NetworkManager. The SecretAgent does not cache the passphrase, but > instead delegates to __secrets_request_cb and WPAKeyDialog which then > prompts the user. > </div>I think WPAKeyDialog should check if a secret is already recorded in connections.cfg for the AP in question before prompting the user. <div class="im"> > Perhaps the GNOME equivalent does cache? I don't know. It is worth a > test, don't you think? Look at how they do it. > > The problem with caching is that if the passphrase changes, the agent > would somehow have to recognise that the passphrase it had was no > longer valid. I seem to recall work that was done in that area within > the last few years, possibly relating to inability to connect to an > access point after the passphrase had been changed. > </div>Think "Discard network history" in network-control-panel would be needed to be used to erase the old passphrase, forcing a prompt to the user for new input. <div class="im HOEnZb"> > It may be wasteful to speculate further. You need to determine from > logs what components (NetworkManager, Sugar, driver, firmware) are > causing the symptom. If you don't have good logs, work to get them. > </div>Jerry <div class="HOEnZb"><div class="h5"> _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </div></div></blockquote></div>