Sebastien Roy writes:
> On Mon, 2008-11-24 at 03:58 -0800, Darren Reed wrote:
> > James Carlson wrote:
> > > We'd probably be better off just to hash ESSID and BSSID together and
> > > use some printable form of the hash as the secobj name.
> > >
> >
> > I like that last idea better than any of the above as it reduces
> > the chance of a natural collision.
>
> 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.
--
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]
