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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1166672277.23168.48.camel@localhost.localdomain>
Date:	Wed, 20 Dec 2006 22:37:57 -0500
From:	Dan Williams <dcbw@...hat.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Daniel Drake <dsd@...too.org>,
	Michael Wu <flamingice@...rmilk.net>,
	Stephen Hemminger <shemminger@...l.org>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Network drivers that don't suspend on interface down

On Thu, 2006-12-21 at 03:25 +0000, Matthew Garrett wrote:
> On Wed, Dec 20, 2006 at 10:08:22PM -0500, Daniel Drake wrote:
> > Matthew Garrett wrote:
> > >Hm. Does the spec not set any upper bound on how long it might take for 
> > >APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. 
> > 
> > I'm not sure, but thats not entirely relevant either.  The time it takes 
> > for the AP to respond is not related to the delay between userspace 
> > sending the siwscan and giwscan ioctls (unless you're thinking of 
> > userspace being too quick, but GIWSCAN already returns -EINPROGRESS when 
> > appropriate so this is detectable)
> 
> Ah - I've mostly been looking at the ipw* drivers, where giwscan just 
> seems to return information cached by the ieee80211 layer. A quick scan 
> suggests that most cards behave like this, but prism54 seems to refer to 
> the hardware. I can see why that would cause problems.

Prism54 (fullmac) does background scanning all the time when the
interface is up.  You can't turn it off AFAIK.  If you look at SIWSCAN,
you'll see that it's essentially a NOP since the firmware is always
scanning, and you'll always have up-to-date scan results.  Ideally, all
drivers would do it like prism54 does (and some later ipw versions, I
think).

Dan

> 
> > I think it's reasonable to keep the interface down, but then when the 
> > user does want to connect, bring the interface up, scan, present scan 
> > results. Scanning is quick, there would be minimal wait needed here.
> 
> Yeah, that's true.
> 

-
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