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