linux-kernel - Re: Network drivers that don't suspend on interface down

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: <Pine.LNX.4.64.0612211359400.30016@mercury.sdinet.de>
Date:	Thu, 21 Dec 2006 14:19:20 +0100 (CET)
From:	Sven-Haegar Koch <haegar@...net.de>
To:	Dan Williams <dcbw@...hat.com>
cc:	Matthew Garrett <mjg59@...f.ucam.org>, Jiri Benc <jbenc@...e.cz>,
	Arjan van de Ven <arjan@...radead.org>,
	Linux-Kernel-Mailinglist <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org
Subject: Re: Network drivers that don't suspend on interface down

On Wed, 20 Dec 2006, Dan Williams wrote:

>> If we define interface down as meaning that the device is powered down
>> and the radio switched off, then (b) and (c) would presumably just need
>> to ensure that the interface is downed. (a) is a slightly more special
>> case - if the switch disables the radio, I guess we then want the driver
>> to down the interface as well.
>
> Correct.
>
>> In the (a) case, drivers should presumably refuse to bring the interface
>> up if the radio is disabled?
>
> Right; the driver simply can't do anything about it, because the switch
> is hardwired to the card and either the card's firmware takes care of
> it, or the chipset takes care of it.  The driver has no say whatsoever
> in the state of the card's radio for this case.  I tend to think this
> case is on it's way out in the same way that fullmac cards are falling
> out of favor (ie, do everything in software and save $$$), but they are
> around and we need to support them.
>
> In this case, down really does mean down too.  The driver cannot honor
> requests to set SSID, frequency, etc, because it's simply not possible
> at that time.

What do you mean with this exactly?
Should the user not be able to set these values, or should the driver not 
be able to activate them?

I think it is correct when the driver does not activate them, but I think 
the user should be able to configure them, have them stored inside 
cfg80211/the driver, and have them activated/used when uping the 
interface, or when the rfkill switch has been deactivated. Otherwise it 
will get impossible to boot with rfkill disabled, toggle the switch later 
on and have everything working.

And another side to this:
if a disabled rfkill switch downs the interface (opposed to just 
disabling it but staying "ifconfig up") - what happens to the ip config 
of this interface? What reconfigures the needed routes when a re-enabled 
rfkill switch reactivates the interface? Will manual route add and 
ifconfig statements be impossible and we'll get forced to use some crappy 
distri-scripts and daemons for it?

And third point just coming to my mind:
how is changing the mac address of the card supposed to work? Chaning it 
through ifconfig only works when the interface is downed, so the newly 
wanted mac address has to be saved somewhere before the interface is 
reenabled and reinitialized on the next "ifconfig up".
(And I think it is an absolute requirement that NO packet with the 
old/default mac address may be sent into the air whatsoever)

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)
-
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/