[Sugar-devel] Passphrase must be re-entered when XO loses then regains wifi connection

[Jerry Vonau]

On 17 June 2012 05:14, Ajay Garg <ajaygargnsit at gmail.com> wrote:

> 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.
>
>
Good job on tracking this down, works for me here by hand editing in the
change.


> 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.
>
>
Things have changed with NM 0.9 for F17.


> 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.
>
>
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.


> d)
> If the solution seems ok, I will be happy to port the solution to
> sugar-mainline. Let me know :)
>
>
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.


> Thanks and Regards,
> Ajay
>
>
Thanks a bunch,

Jerry


>
>
> On Thu, Jun 14, 2012 at 6:02 AM, Jerry Vonau <jvonau at shaw.ca> wrote:
>
>> 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.
>> >
>>
>> 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.
>>
>> > 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.
>> >
>> Dextrose 3, based on sugar 0.94.
>>
>> > 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.
>> >
>>
>> I think WPAKeyDialog should check if a secret is already recorded in
>> connections.cfg for the AP in question before prompting the user.
>>
>> > 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.
>> >
>>
>> 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.
>>
>>
>> > 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.
>> >
>>
>> Jerry
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120617/2dee9a21/attachment.html>