lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200903192024.30562.elendil@planet.nl>
Date:	Thu, 19 Mar 2009 20:24:27 +0100
From:	Frans Pop <elendil@...net.nl>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	"John W. Linville" <linville@...driver.com>,
	jeff.chua.linux@...il.com, mingo@...e.hu,
	torvalds@...ux-foundation.org, rjw@...k.pl,
	linux-kernel@...r.kernel.org, bunk@...nel.org,
	akpm@...ux-foundation.org, kernel-testers@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: Required sequence to set wireless parameters?

On Thursday 19 March 2009, Johannes Berg wrote:
> Wext is a mess, and we've known that for a long time... But no, the
> sequence should _not_ be required, it's just _easier_ for the kernel,
> and as such has a better probability of succeeding if there are
> problems, it should still work though.
>
> However, one thing that will _not_ work is this:
> iwconfig wlan0 essid xyz
> iwconfig wlan0 key s:xyz
>
> you still need:
> iwconfig wlan0 ap any
>
> or anything similar after setting the key to trigger the kernel to do
> something.

OK. Thanks for the info.

> > Reason I ask is that for example when writing wireless support for
> > e.g. a distro installation system, it seems most logical to *first*
> > ask the user what network (ESSID) he wants to connect to. Next to
> > check if we can connect to that network without additional
> > authentication and only then, if needed, ask for keys etc.
> > If it's not possible to set that info in that logical order that
> > seems rather restrictive to me and would probably mean that you'd
> > have to reset AP, ESSID and possibly other settings before each
> > incremental attempt.
>
> That's a pretty wrong argument, nothing says your software cannot
> collect all the information and then give it to the kernel at once
> later, I think... In fact, this is required anyway when you use RSN or
> WPA (wpa_supplicant needs all information at once), for example.

Well, the thing is that we'll already have tried just setting essid to 
check if it's an open network. However, I can see the point of needing to 
set the essid _again_ after asking the key info and setting that.

I can also see how you might have to unset some settings in some cases, 
for example if the NIC has already associated with the wrong network 
(e.g. because there's a totally open network in range).

Our current logic (in Debian Installer) definitely needs improving and 
these pointers will help. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ