James Carlson wrote: > Anurag Maskey writes: > >> Are we always hashing ESSID-BSSID? If so, then a user cannot roam >> multiple WEP/WPA protected AP's which the same ESSID. >> > > Today, the "hash" always includes ESSID and BSSID. (The hash is > rather transparently just copying the strings and lopping off the > parts that don't fit, but as you point out, any function can be a > "hash.") > > >> So, my idea was to use the fact that the user has indicated how strictly >> s/he wants the ESSID/BSSID pair to be considered. If the user says >> strict_bssid, then use both to generate the name. The user won't be >> able to roam. If not_strict_bssid, then only the ESSID is used to >> generate the name and the user can roam. >> > > The user really shouldn't be tweaking this flag at all. It defaults > to "false," and it's intentionally not documented because we're > reserving it in case there's some sort of emergency. > > Given that we still use BSSID when the flag is set (we just treat any > match on ESSID as being equivalent), I don't see how it's relevant for > your change. In other words, I don't think you should be checking > this flag. > So, the secure object name *always* includes the "hash" of ESSID and BSSID? If yes, then each secure object can be used with only one ESSID/BSSID pair. Is this the idea?
I had planned to fix the way nwamd generated secure object names as part of the fix for this CR 6766937. Should there be a different CR changing how nwamd generate secure object names (this md5,sha1,and other "hashes" we are discussing)? I am very confused as to what else I need to do besides have libdladm and dladm verify that secure object names contain only alphanumerics and underscores. > >>> 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 ...) >>> >>> >> Yes, we can rename (delete+create) the names, >> > > Rename isn't the same as delete and create. "Create" for a secobj > means that you have to enter in the key -- and you don't have that and > can't retrieve it from the protected storage. > Right. One could manipulate /etc/dladm/secobj.conf with the new names before init-secobj is called. Anurag _______________________________________________ networking-discuss mailing list [email protected]
