Re: rt2x00/rt2500 support

[Dan Williams <dcbw redhat com>]

On Fri, 2006-07-14 at 13:54 +0200, Jiri Benc wrote:
> On Thu, 13 Jul 2006 23:03:50 -0400, Dan Williams wrote:
> > The d80211 stack clearly supports the ENCODEEXT and AUTH handlers.
> > However, the ieee80211_ioctl_giwrange() handler in ieee80211_ioctl.c is
> > _pathetically_ small and shouldn't even be allowed out of the asylum:
> 
> Thanks for the report and really useful description of the problem and
> its solution. I will look into this; however, I don't have much
> experiences with this part of WE. But it is definitely important to get
> NM work with d80211 (and d80211 with NM ;-)).
> 
> I will need some time for this, but it is a high priority for me.

It shouldn't actually to be too bad here; but you'll need to know some
specific information about the card's hardware (does it support 802.11a?
what rates does it support?) to fill in some instances of this
structure.

Note that not all those items are time-critical; some of them may be
ignored for a while.  But at a minimum, d80211 _needs_ to set the
following:

1) range->enc_capa: lets NM and other user apps know that the driver
supports WPA
2) range->max_qual: sets up quality ranges so users can get useful
quality information out of the driver

These two are by far the most important, and are quite critical.  Note
that range->max_qual is somewhat tricky to get right; see the bcm43xx
discussion that Larry Finger and I are having on netdev right now.  In
any case, these values are somewhat hardware-dependent, especially
quality.  Which is why, I think the hostap/Intel ieee80211 layer leaves
SIOCGIWRANGE up to the individual driver, not the 80211 stack in
general.

> > This appears to happen due to this check in ieee80211_ioctl_siwmode() in
> > ieee80211_ioctl.c:
> > 
> > 	if (netif_running(dev))
> > 		return -EBUSY;
> > 
> > If I understand that correctly, that means the driver is marked
> > IFF_RUNNING, and I think returning -EBUSY here is also likely wrong.
> > What should a user space application have to take the device down (which
> > also clears IFF_RUNNING AFAIK) just to be able to switch modes?
> 
> Sorry, modes cannot be switched when the network interface is up. It
> should have never been allowed at the first place. Switching modes
> requires beastly operations in the stack including reallocation of
> fundamental structures. There was even opposition against allowing
> changing of modes at all (so it would be required to remove the network
> interface and add a new one with a different mode).

Ok; fair enough.  Softmac stuff does have to do a lot more work here.
Fullmac cards usually just restart the firmware with different values
anyway, which is like cheating :)  Since it is quite hard to from a
clean slate, I'll buy this argument.

> > At a minimum, it should silently return success if the mode that's about
> > to be set is the same mode the driver is already in.
> 
> On the other hand, if we return error always when the network interface
> is up, it will help catching bugs in userspace programs.

Sure.

> > It appears that is because the station is already scanning; I would
> > argue that if d80211 is already scanning, the driver should silently
> > return success from the SIWSCAN handler because scan result
> > notifications will come along to every application eventually anyway via
> > netlink, and each application that cares about scans can get the results
> > then.
> 
> Makes sense.

Dan