Jiri Benc wrote: > On Sat, 27 Aug 2005 11:21:37 -0500, James Ketrenos wrote: > >>The order required of user space is: >> >> kernel hotplug hotplug script >> ----------------------- -------------- ----------- >>1. module load >>2. netdev device registered >>3. new device >>4. ifconfig up >>5. open: load firmware, >>6. init device, etc. >>7. configure wireless >>8. scan >>9. associate >>A. >>link >> >> >>B. carrier detected >>C. configure link >>(dhcp) > > > I don't agree with this scheme. Association should be started on > explicit userspace request (*). As we definitely don't want to add a new > WE (or some other) call to perform this, the only call we can use for > telling the driver "ok, now it's the time to associate" is ifconfig up. > So opening the card should follow its configuration. >
The scheme looks good to me. Wireless cards mostly map to a regular network card. Only difference is that you need to do something to configure the link to have "carrier detected" and DHCP should only be started after "carrier detected" (IFF_RUNNING IIRC). Regarding association only on explicit userspace request, that's fixable in the drivers (some drivers automatically associate once they're ifconfig'ed up, the ipw2x00 drivers have a module parameter to change this behaviour). > And yes, this brings up the problem with firmware loading. It should > really be solved, but trying to solve it by requiring to bring the card > up before it is configured is the bad way. Why is it the "wrong way"? I don't see a big problem with this, the card is only going to be used after it's UP. The only problem i see is that it doesn't behave exactly like most network drivers, where they are able to detect a link even when they're DOWN. Is there a good reason for a card to do anything even when it's DOWN? > > Today, some cards require to be brought up before they are configured > and some require it in the other order. Distributions have to deal with > it if they want to support different devices. It definitely needs to be > unified. And when the unification is performed, why not do this the > right way? > Agreed, there should be a guideline for the setup behaviour. > (*) Because it's not good idea to start association before wireless is > fully configured. Trying to associate to some random AP because > semi-entered configuration matches the AP settings is very unexpected > behaviour. And there might arise some problems with allowed/forbidden > channels as well. > Right, that would need a new interface where all parameters are passed at once, or keep the existing interface and add another just to explicitly associate. Besides that, there should also be a way to configure if you want to auto-associate to new access points if the old access point becomes unavailable or with a weaker signal than the new one, or if you want to manually associate, ex: association is done once and never tried again until you tell it to do so. The manual association would be a good thing for a wireless managed, where it would have the work of handling new networks, APs becoming unavailable and available again, etc. -- Pedro Ramalhais - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
