Open labno opened 2 years ago
Yes, I think that a good solution is to use the newer flag parsing output in order to get the key management information from the access point.
The new output breaks out the various components of the flags and so we don't have to include every possible complete flag, but rather we can look for the pieces of the key management to derive these things. I am almost leaning towards just sending the flags down to the client and allowing the client to figure out the key management. However, I haven't looked at the code in a while so I will read a bit to understand what the implications are in regards to doing that. I am open to suggestions.
Thank you!
Classification of the flags happens first in access_points.js
to set the value in the table of access points and then again in router.ex
to render the password page. So, I'm thinking we could simply unify those two into a single function (e.g. in WiFiConfiguration
) and go by the broken-down flags there?
I'm afraid I'm not sure what you mean by "sending down to the client", but of course I'm open to other approaches.
Hi all,
Some WPA2_PSK protected wifis I encountered in the wild don't show up as such in the listing on
/network
. As it turns out, all of those have the flagwpa2_psk_sae_ccmp
, which is correctly assigned to APs, but not included in the list of flags making it show as WPA2_PSK protected in the table:access_point.js
:However, this flag is included in
router.ex
when determining the parameters for the password page:Is this discrepancy deliberate? If not, I'll prepare a PR.
Thanks!
EDIT: This seems to be the
VintageNetWizard
version of this issue: https://github.com/nerves-networking/vintage_net_wifi/issues/61So maybe it would be good to include all the flags here added recently to
VintageNetWifi
?