Anurag Maskey writes: > > 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?
Yes. > If yes, then each secure object can be used with only one > ESSID/BSSID pair. Is this the idea? That's correct. I don't know if it's _right_, but it's certainly correct. ;-} There's much about the NWAM Phase 0 design that's unclear to me, and the area surrounding BSSID handling has an aura of great mystery. The code goes to great lengths to keep this stuff apart and match on it in various contexts, but then the actual 'libdladm' functions called by NWAM ignore the BSSID almost completely and rather pointedly. In fact, in the few places where it's used, it's totally ineffectual and serves no purpose other than to confuse. And I have no idea what the drivers are doing. Why is this code in nwamd? I dunno. I just don't want to spend a lot of time trying to polish this when Phase 1 should rewrite it all. > 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. Getting back to the original problem, all we need is a name that's predictable from the ESSID+BSSID (i.e., not random), that is fairly unlikely to clash for a range of ESSID+BSSID strings, and that fits in the 'secobj' name space restrictions. As a bonus, not losing the user's already-entered keys would be really nice, but if we can't manage that, then I guess folks will understand. Anything like that will make me happy. I mentioned hex representations of hashes because they'd probably be more robust than what we have been doing, but that's not the only way to solve the problem, and it's not even really the crucial part, which is the conformance to clear 'secobj' restrictions for character set and length. > > 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. That'd be the only way to do it. -- 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]
