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. > > 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. > but we don't know how much > was truncated from the secobj name. True; if it's malformed, you're sunk. That's a good point. Perhaps just removing the old ones is the only sane thing you can do. > Then, nwam may not be able to use > that secobj. (And we'll get a bug from a user saying "nwam asks for key > even though I already entered and was able to use it until today"). > > We'd have to keep the old secobj also around for the failsafe. There are a few corner cases to consider. Suppose the user has an old one, and then he changes the key, and has to re-enter it. Do we save the new one under the old secobj name or do we delete the old secobj and create a new one? I guess it's the latter ... -- 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]
