[Prism54-devel] Re: wireless API semantics when netif down?

[Jean Tourrilhes]

On Mon, Nov 24, 2003 at 09:21:24AM +0100, Herbert Valerio Riedel wrote:
> hello!
>=20
> I'm developing for the prism54 driver project,

	I know that, I've added your driver to the Howto. By the way,
congratulation on the quick pace of your project.

> and we stumbled upon
> some disagreement about how the driver should react, when the network
> device is not opened yet;
>=20
> And since you're the maintainer for the API, I'd guess you could
> clarify a bit...
>=20
> so to the actual issue: what are the semantics for the wireless
> extensions, when the device hasn't been opened yet, but the netdev is
> registered, i.e. the device is simply down?
>=20
> shall iwconfig et al. return any useful data at all? should iwconfig
> config requests be successful?
>=20
> regards,
> --=20
> Herbert Valerio Riedel

	I'll answer, but not directly. Bear with me a second. BTW,
forward as necessary on the mailing lists.

	When the card is brought up by ifup (either at boot time or
via hotplug), ifup set an IP address to the card and "up" it. If the
IP address is 00.00.00.00 when the card is set "up", one of the
various autoconfiguration scheme, such as DHCP or ZeroConf will do its
stuff and allocate a proper IP address to the card.
	Now, DHCP and ZeroConf must have network access to do their
job. Both with do a limited number of retries, and will use broadcast
which is very unreliable on a wireless link (see my paper), so you
want to make sure the wireless link is established before they run.
	Because we want to be simple and safe (autoconfig might be
done in a various number of ways, including in the kernel), the
solution is to set the wireless configuration before the card is set
"up". This way, you are guaranteed that the wireless config is
*always* set before autoconfig runs.
	If you look at the various wireless config scripts (file
DISTRIBUTIONS.txt on my web page), you will realise that all distro do
that (or should do that), they start with the link configuration and
do IP config after it. If you think about it, it's logical.

	Now, most driver don't power-up the card before it's set
"up". This allow to power save easily (ifconfig XXX down), and is
conceptually the right thing. As the hardware is not active, you can't
configure it.
	Now, if you look at a driver like Orinoco, you will realise
how to reconciliate those two requirements. If the driver is "down",
all iwconfig requests are "cached" in the driver. When the card is set
"up", the configuration cache is then really applied to the card. One
of the advantage of this scheme is that configuration changes are
"batched", and in testing we noticed a nice speedup at card setup.
	The "new API" helps you in that matter by having the "commit"
handler that is supposed to be called appropriately. My patch for the
Orinoco driver uses the commit handler.

	That was for the "requests". For the display, it would be nice
to display the values from the cache when the card is "down". However,
Orinoco display bogus values when the card is down and not many people
do complain.

	On a related note... The usage of "nameif" and other evoluted
config scripts (see Debian bugs) requires that the driver report a
valid MAC address when the card is down. If it's too hard, make it a
valid MAC address prefix ;-)

	Have fun...

	Jean