I'm sponsoring this fast-track request for myself. The timer is set
to 12/05/2008.
The release binding is patch/micro due to the obviously compatible
nature. There is no intent to backport to Solaris 10 or release any
patch.
This is a fairly trivial update to "NWAM Phase 0.5 (picea)" (PSARC
2008/482). It modifies the contract private interfaces used between
NWAM and the GUI, but does so in a fully compatible way.
Issue 1: New Key-Setting API
----------------------------
A regression was found from NWAM Phase 0 with the setting of WPA
keys when the AP is not in range or not present in scan results.
This issue has been documented here:
6776888 libnwam needs new API to allow keys to be set for hidden
APs
In order to fix this, we need a new API for the Project Private
libnwam library shared between the GUI and NWAM. This new API is:
#pragma weak libnwam_wlan_key_secmode
extern int libnwam_wlan_key_secmode(const char *, const char *,
const char *, const char *, const char *);
This has one extra argument added to the existing libnwam_wlan_key
function, which in turn becomes a wrapper over this new function
(passing the last parameter as ""). Because it's used as a weak
symbol in the GUI, and the old API is preserved in the library, the
old library works with the new GUI, and the new library works with
the old GUI; there are no issues with upgrading one or the other
independently. (And testing has confirmed that this works.)
As a result, we claim that this project represents a trivial
addendum to the previous contract from 2008/482, and no new contract
is required. If you still want a new one for this new function,
speak up.
Issue 2: Private SMF Property
-----------------------------
Due to various limitations in the system, the BSSID is of limited
utility, though it is still tracked by NWAM. As a result, NWAM is a
bit more persistent in asking the user questions in many cases when
it should not be, and previous (soon to be fixed) bugs in NWAM were
masking this problem. This issue, and the fix, is documented in:
6773627 nwamd should be less interested in BSSID
The fix simply makes NWAM match on ESSID alone if ESSID+BSSID fails,
and assumes that if an ESSID+BSSID combination exists, then other
BSSIDs with the same ESSID are equivalent.
In order to allow the user to select the strict BSSID matching
behavior (if desired), we will provide an undocumented (Project
Private) SMF boolean property:
nwamd/strict_bssid
As neither the GUI nor the dladm/Nemo layer currently respect or
display BSSID selection, it's unlikely that this will be needed in
the near future, hence the undocumented nature. It's there (as are
most of the NWAM SMF tunables) for emergency purposes.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
