On 8/28/15, 1:35 AM, "connman on behalf of Patrik Flykt" <connman-boun...@connman.net on behalf of patrik.fl...@linux.intel.com> wrote:
> > Hi, > >On Thu, 2015-08-27 at 15:43 +0000, Adam Moore wrote: > >> I¹m using 1.29. After looking at these commits I believe I¹m seeing >> another corner case. If I enter a wrong passphrase, and instead of >> invalid-key, I get connect-failed (due to association problem, >> interference, etc), the passphrase isn¹t cleared. > >The code now follows the actual service error, so if the error is set to >invalid-key, the passphrase will be asked on the next connect. If the >error reported is connect-failed, ConnMan will put the service as >"ignored" and not autoconnect to it until the service is purged and >re-created by wpa_supplicant. The passphrase is actually not cleared and >set to NULL in order not to remove a working setup when encountering an >identically named AP with the same security settings somewhere else; >instead the invalid-key error status now does the same job. > >So on a connect-failed ConnMan is expected not to autoconnect. What >should work is a manual connection attempt to that network. In your >case, will the subsequent connection attempts always end in >connect-failed? The first invalid-key error received should cause >ConnMan to ask for a passphrase next time a Connect() is requested >either as a user action or as a retry from the Agent. Do you ever get >anything else than connect error from wpa_supplicant? Sorry for my delay, Patrik - got derailed for a bit. Correct - in my case, all attempts after connect-failed stay connect-failed. The autoconnect behavior you describe above, which is correct for autoconnect, is where I think a problem lies for manual connect. In one of our offices, where there is a lot of noise, we can receive a connect-failed even with a bad password. This locks in the bad password. So the edge case is this: User enters a bad password in a noisy environment. All attempts to fix the situation fail even when the password is corrected because the bad password is relayed to the supplicant again. > >> To simulate a difficult RF environment, I changed network.c line 1323 to >> call set_connect_error instead of set_invalid_key_error. After >>attempting >> a connection with a bad passphrase, I was unable to try again even with >>a >> good passphrase. > >This will not trigger ConnMan to ask for a passphrase, as the error >always is due to the connection being bad, not the passphrase being >wrong. I agree this behavior is correct for autoconnect, but since this error can be seen on manual connect even with a bad password, we should ask for a new password only if we are doing a manual connect, as the correctness of the password has not yet been proven. I only mention the network.c patch to show how to observe the symptom of the edge case if you don’t have sufficient RF noise to observe the real thing. I’ll pass along the real patch to service.c so you can see what I’m thinking. Thanks! > >Cheers, > > Patrik > >_______________________________________________ >connman mailing list >connman@connman.net >https://lists.connman.net/mailman/listinfo/connman Statement of Confidentiality The contents of this e-mail message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust, and the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or at 508.683.2500 and delete this message and its attachments, if any. _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
