On Mon, 2008-11-24 at 09:29 -0500, James Carlson wrote: > Sebastien Roy writes: > > That would only make sense to me if there was a documented way of > > knowing what secobj name was being used by NWAM for any given WiFi link. > > Otherwise, it makes it difficult to diagnose problems through the CLI by > > doing: > > > > dladm connect-wifi -e <essid> -k <secobj-name> <link> > > > > ... after NWAM has automatically created <secobj-name> through the GUI. > > I think that's 'just' a debugging issue. Normal users should never > have a need to do anything like that, and when they do, I'd be ok with > saying something like this: > > NWAM stores the security objects using hashes. If you only have one > key stored, then "dladm show-secobj" will identify the one needed. > Otherwise, you can recreate the hash used in NWAM by doing this: > > echo 'ESSID name' 'BSSID string' | digest -a sha1 > > For example: > > % echo 'sunwifi' '0:18:b0:7d:34:c1' | digest -a sha1 > 09a75098435200505fb5de8e59a3a4edfe544781 > % pfexec dladm connect-wifi -k > nwam-09a75098435200505fb5de8e59a3a4edfe544781 > > > Well, *something* like that. Another problem here is that the secobj > names are of limited length, and dladm(1M) doesn't tell you what the > limits are. You have to guess.
Instead of having to crunch the hashing algorithm, we could instead include the secobj name in the /etc/nwam/known_wifi_nets file (or equivalent for Phase 1). The nwamd daemon could also grab the name out of there instead after having generated the key. -Seb _______________________________________________ networking-discuss mailing list [email protected]
