On 8/26/15, 11:56 PM, "connman on behalf of Patrik Flykt" <connman-boun...@connman.net on behalf of patrik.fl...@linux.intel.com> wrote:
> > Hi, > >On Wed, 2015-08-26 at 16:54 +0000, Adam Moore wrote: >> In September, there was a discussion on how we should handle a situation >> where an autoconnect fails due to receipt of a connect-failed error, >>which >> can be seen in difficult RF environments. >> >> I understand the current recovery mechanism where we let wpa_supplicant >> age off BSSs during a sufficiently long interval between autoscans in >> order to prevent too many conneciton attempts to the AP. >> >> There is one situation this does not cover, which is where you do not >>have >> any favorite networks, and are performing a connection for the first >>time. >> In this scenario, the user facing application must periodically scan >>at a >> rate that will prevent BSS age offs, in order to keep a list populated >>and >> to support net.connman.Service.Connect calls. However, this prevents >> clean instances of the service from being created, and a user that >>happens >> to receive a connect-failed on their first attempt will be unable to try >> again without restarting connman. Even if the more aggressive scanning >>is >> removed, subsequent Connect attempts will fail until the failed BSS is >> aged off. Though this problem resolves itself over time with >>autoconnect, >> it will be a pretty annoying UX problem for a user who is actively >>trying >> to connect. >> >> Is there interest in an upstream change to address this? Since Connects >> at this stage will be user initiated, I am less worried about the >>problem >> of getting locked out of an AP. > >This should have been fixed with commits >edc02deab0225b3410179c8937e7cfb4058ced7c from May and >026690ff7c5d8a434b26aaedbe70e3580aa5027a from October last year unless >you have found yet another corner case. What was the ConnMan version you >are using? Hey Patrik, 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. 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. Thanks, -Adam > >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
