Passphrase must be re-entered when XO loses then regains wifi connection

[Jerry Vonau]

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