-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test manual network name entry for secure network which is NOT WPA2 secured #13
Comments
From @zsup on February 24, 2015 14:24 sounds like this may require work on the firmware side? Is there an |
From @jensck on February 25, 2015 16:59 At least on Android, we could probably guess correctly most of the time while allowing the user to change it(?). The idea relies a couple assumptions -- feel free to question these(!):
IF both of the above are true, then most of the time, the workflow could look like this:
If the above fails (no hidden SSIDs, not all security types match, etc): default to WPA2, since (I assume/hope) that's the default on modern APs. If setup fails, suggest to the user that their security type might have been wrong? OTOH, it'd be pretty great if the firmware could just figure this out. |
From @towynlin on February 27, 2015 23:9 I love that flow @jensck. 👍 @m-mcgowan should weigh in here on firmware capabilities in this scenario. On iOS AFAIK we can't scan from within the app, so defaulting to WPA2 sounds like a good idea. If the firmware can scan and/or retry other security types on failure to connect that would be helpful. Otherwise the mobile app could send multiple configurations with different security types. Gross, but might work as a last resort. I do believe defaulting to WPA2 will be correct for over 99% of users with hidden networks, so we shouldn't spend much time on this issue. 😸 |
From @idokleinman on February 24, 2015 1:16
app doesn't know which security type is a manually entered network
but it's very bad UX to ask user about the type so app assumes WPA2 for all secured networks
we need to check this theory and see if firmware behaves correctly (firmware gets security type/channel on
configure-ap
command)(also assuming channel 0)
relevant to #55
cc:
@jensck @towynlin
Copied from original issue: spark/mobile-sdk-ios#56
The text was updated successfully, but these errors were encountered: