Bug #405
closedCan't connect to similarly-named, encrypted wireless networks.
100%
Description
Previously, when nwam stored secure objects, the keys for each network was saved with its MAC address appended to the secure object's name. So, when trying to connect to "blue line" or "blueline", the stored key "nwam-blueline" is used for both.
Files
Updated by Albert Lee about 12 years ago
- Project changed from OpenIndiana Distribution to illumos gate
- Difficulty set to Medium
- Tags set to needs-triage
Updated by Enrico Papi about 11 years ago
- Status changed from New to In Progress
the nwam behaviour on 151.1.2 is the same
after setting up and enabling a new ncp with a configured ncu phys/ip bound to :
nwamadm scan-wifi _wifilink_ nwamadm select-wifi _wifilink_ ESSID NET GEAR BSSID _mac_ ESSID NETGEAR BSSID _mac_ Other Choose WLAN to connect to [1-3]:
Both network are mapped to a secure object named nwam-NETGEAR
only alphanumeric chars are left and also - and . and _
the nwamd_set_key_name fuction actually adds the BSSID that should be passed
i am debugging it
Updated by Enrico Papi about 11 years ago
a possible approach to solve this
Updated by Enrico Papi about 11 years ago
- File illumos-405-webrev.zip illumos-405-webrev.zip added
new webrev attached
Updated by Enrico Papi about 11 years ago
- File illumos-405-webrev.zip illumos-405-webrev.zip added
Updated by Enrico Papi about 11 years ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
This patch maily consists in the following nwam design changes:
http://sunkiss.altervista.org/illumos-405-webrev
-when strict_bssid is true, secobj name format will be nwma-ESSID-BSSID if a similarly named secobj already exists, and a distinct key needs to be stored
http://pastebin.com/BDcWrZ2S
-when strict_bssid is true, nwam will now use the same secobj only when ESSID+BSSID+keyval are identical
http://pastebin.com/Wj415rr0
-when strict_bssid is true, the user now can switch between two distinct APs with the same ESSID and different keys without recreating knownwlan/secobj all the times
http://pastebin.com/m2ChhrrX
-when strict_bssid is false, the current nwam requirements are correctly preserved, in particular, using nwam select-wifi, nwam will not prompt for password of when an existing secobj matches, and finally, the wifi automatic roaming functionality is preserved for identical ESSIDs.
http://pastebin.com/FuPcCzXA
http://pastebin.com/EaPmeRN5
It has to be noted, as shown in this last test, that the current nwamd code will allow an user-transparent association to a different AP with the same ESSID if strict_bssid=false even if the AP (with the exact BSSID) is not on the known wlan list. This could be a serious security issue.
I think, the correct way of implementing this should be requesting the user a manual selection of the AP the first time the BSSID is encountered. After that, the BSSID will be added to bssid list in the matching known wlan and automatic roaming will be allowed. This change would require a simple change in the wifi_scan_thread function.
Let me know if we want to put in also this change before RTI
Updated by Rich Lowe about 11 years ago
- Category set to cmd - userland programs
- Status changed from Feedback to Resolved
- Tags deleted (
needs-triage)
Resolved in r13694 commit:3a75fed3cee2