Re: rt2x00/rt2500 support

[Jiri Benc <jbenc suse cz>]

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.

> 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).

> That
> hasn't been the case until now with d80211, and it seems somewhat wrong
> to me.  I'm somewhat ambiguous here though, somebody could probably make
> a case to convince me that we have to change the behavior of userspace
> apps to require a down and then mode change.

This is the case, sorry. When you change the mode, you fundamentally
change the nature of that network interface. It's not the same interface
anymore - it behaves differently, send different types of frames, have
another limitations, etc. It is indeed more similar to removing the
interface completely and creating a new one. It is even implemented in
this way (though interface is not unregistered and registered so you
don't receive unexpected events in userspace).

> 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.

> 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.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs