Bug #405


Can't connect to similarly-named, encrypted wireless networks.

Added by J Kimball over 12 years ago. Updated about 11 years ago.

cmd - userland programs
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


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.


405.patch (3.23 KB) 405.patch Enrico Papi, 2012-04-11 09:53 PM (368 KB) Enrico Papi, 2012-04-16 06:26 PM (393 KB) Enrico Papi, 2012-04-18 10:45 AM
Actions #1

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
Actions #2

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_


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

Actions #3

Updated by Enrico Papi about 11 years ago

a possible approach to solve this

Actions #4

Updated by Enrico Papi about 11 years ago

new webrev attached

Actions #6

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:

-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

-when strict_bssid is true, nwam will now use the same secobj only when ESSID+BSSID+keyval are identical

-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

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

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

Actions #7

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


Also available in: Atom PDF