Skip to content
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

Open
idokleinman opened this issue Apr 9, 2015 · 3 comments

Comments

@idokleinman
Copy link
Contributor

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

@idokleinman
Copy link
Contributor Author

From @zsup on February 24, 2015 14:24

sounds like this may require work on the firmware side? Is there an auto security option where the firmware will first try WPA2 but if that fails try WPA and then WEP? seems like this would only be necessary for private networks where the security method isn't broadcasted. @m-mcgowan

@idokleinman
Copy link
Contributor Author

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(!):

  1. Networks with hidden SSIDs are a small minority
  2. Anyone who's hiding their SSID is also probably using WPA2, since WPA and WEP are known to be insecure. This is admittedly a big assumption.

IF both of the above are true, then most of the time, the workflow could look like this:

  1. User taps the button for manual SSID entry
  2. Look at scan results for all networks in range with hidden SSIDs
  3. Compare the security types of each network from step 2. If they all match, we have a solid guess about what security type to use.
  4. If we get back a single security type from step 3, just select this value, and don't present an option to the user, or present the option, but pre-select the right value.

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.

@idokleinman
Copy link
Contributor Author

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. 😸

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant