On Tue, 2010-06-01 at 22:53 +0300, Maxim Levitsky wrote: > > This won't quite work. monitor interfaces are always slaves in the sense > > that their channel setting never takes precedence over anything, so if > > you add another interface and do something there, the hardware will > > happily channel switch away from the monitor channel, but it will still > > report the old channel here that you set. > > > > I have no idea how to _properly_ fix this though, since eventually we'll > > have a situation where you can have multiple interfaces active on > > different channels, so that monitors don't have a fixed channel anyway. > > > > Maybe this patch is sufficient since it works in the case people care > > about when they _only_ have a monitor interface, but I think it'd be > > nicer if it wouldn't report anything in the other cases. > > Why? > > We don't have any wireless devices that actually support using 2 > channels independently. ath9k already supports this with its virtual wiphy concept, and that will be moved in the medium term to do channel switching between multiple virtual interfaces. It's perfectly possible to do this with two station interfaces, for instance, since you can pretend to be in powersave while you go to the other channel. So we actually _do_ have devices that support multiple channels independently, just not the way you think of it. > Therefore user should be aware that if he sets channel on one interface, > and then on other, the last setting matters. Like I said, this is not true. > Of course the right fix would to make channel a global property of card > rather that of interface. No, see above ... my recent patches have moved exactly in the other direction for this reason! However, This obviously only works for certain special cases like 2 stations. Monitor interfaces are sort of a second class citizen, if you have two stations on different channels and add a monitor interface, its channel setting won't matter at all. However, in that case, when you set a channel on the monitor interface, with this patch it will report that channel, irregardless of what channel it is currently on. And if you have 2 channel switching station mode interfaces, there's no sensible channel to report at all. Again however though, very likely you don't care about that situation. But I still think we shouldn't report a bogus channel then. So maybe in that situation we should just fall back to reporting nothing, i.e. return -EINVAL? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
