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

Sun Jun 17 06:14:21 EDT 2012

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

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.laptop.org/pipermail/devel/attachments/20120617/068ff3c4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-au-1305-Use-cached-secrets.patch
Type: application/octet-stream
Size: 2304 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20120617/068ff3c4/attachment.obj>