Project

General

Profile

Actions

Bug #405

closed

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

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

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
cmd - userland programs
Start date:
2010-11-09
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

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

405.patch (3.23 KB) 405.patch Enrico Papi, 2012-04-11 09:53 PM
illumos-405-webrev.zip (368 KB) illumos-405-webrev.zip Enrico Papi, 2012-04-16 06:26 PM
illumos-405-webrev.zip (393 KB) illumos-405-webrev.zip 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_

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

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

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

Actions

Also available in: Atom PDF