I've logged http://defect.opensolaris.org/bz/show_bug.cgi?id=5460 so that Phase 1 can deal with ESSID/BSSID and secure object names.
For the fix for this CR, I'll go the simple route of excluding invalid characters from the ESSID when creating secure object names. I'll add '.' and '-' to the list of allowable characters for secure object names, so we still have the nwam-ESSID-BSSID as the secure object names. I'll also file a man page bug to get both the linkname and secure object name explanations corrected. NWAM Phase 1 should come up with a more robust solution for the naming of the secure objects. Anurag James Carlson wrote: > 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. > > _______________________________________________ networking-discuss mailing list [email protected]
