Anurag Maskey writes:
> Rather than using the nwam-ESSID-BSSID as it currently does, nwam will
> create a MD5/SHA1 (which one?) hash of the name(s) that it will use for
> the names of secure objects. The name is be "nwam_hash". If the
> tunable nwamd/strict_bssid from CR 6773627 is set, then the hash will be
> of the string "ESSID-BSSID" ('-' between the two values), otherwise the
> hash will be just "ESSID". Since libdladm has a length restriction of
> DLD_SECOBJ_NAME_MAX (32) on the names, only the first 27 from the
> characters from the hash will be used in the secobj name.
Does this mean that when I set or reset strict_bssid, I lose my keys?
The current NWAM code still differentiates on BSSID, even after CR
6773627. I haven't redesigned that. I'm not so sure that new flag
should affect how key objects are named.
> The second situation is where there are secobjs already out there that
> don't follow the character restrictions (either through nwam or dladm).
> These could contain @*% and other characters. These secobj's should
> still be allowed to be loaded by dladm, and used by both dladm and
> NWAM. Thus, NWAM will need to failover to the current nwam-ESSID-BSSID
> naming scheme if the new nwam_hash scheme fails when it tries to connect
> to a WEP/WPA network.
I'd rather see the start-up script for the 'network/physical:nwam' SMF
service search for those old secobj values and rename them. (Too bad
there's no 'rename-secobj' function ...)
Failing that, continuing to use use the object under the old name if
it's found (but never creating new ones that way) seems ok.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
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
_______________________________________________
networking-discuss mailing list
[email protected]
