On Tue, Jul 20, 2010 at 3:04 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2010-07-20 at 01:28 +0200, David Gnedt wrote: >> Am 2010-07-19 23:06, schrieb Gábor Stefanik: >> > (BTW, I say that a GIWFREQ on a monitor interface should always return >> > the channel the PHY is tuned to at the moment when it is issued. Most >> > tools seem to expect this behavior.) >> >> I agree, that would be the expected behaviour. >> >> I am not very familar with the entire wireless subsystem yet, but wouldn't that >> imply a interface change in cfg80211 and mac80211 to add an "get_channel" function? > > Yes, I think so. > >> Because if the card is hopping channels (e.g. because of 2 station interfaces on >> different channels), only the driver itself can tell what's really the current >> channel. > > Right. Although in that case I'm not sure we should be telling userspace > what channel the monitor interface is on, since there's no single > channel it is on, and I certainly hope userspace won't be requesting the > channel many times per second! Well, there is no reason why channel-hopping due to multiple virtual PHYs and channel-hopping by userspace control (see Kismet) should behave differently GIWFREQ-wise. Also, userspace (apart from maybe hostapd - I haven't looked into that at all) seems to expect GIWFREQ on a monitor interface to unconditionally return the channel the radio is tuned to at the moment. > >> Nevertheless a default implementation for this new "get_channel" can be written >> at mac80211 level (or even cfg80211?), which tries to find the current channel >> by looking at all virtual interfaces, so only mac80211 drivers which allow >> multiple channels (and non-mac80211 drivers) need to implement it. > > Indeed, but I think mac80211 would be more appropriate than cfg80211 > since the latter won't really have all the information unless it makes a > whole bunch of assumptions that we'll eventually have to reconsider. > > johannes > > -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) -- 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
