Le 05/05/2010 15:25, Johannes Berg a écrit :
Currently (all tested with hwsim) you can do stupid
things like setting up an AP on a certain channel,
then adding another virtual interface and making
that associate on another channel -- this will make
the beaconing to move channel but obviously without
the necessary IEs data update.
In order to improve this situation, first make the
configuration APIs (cfg80211 and nl80211) aware of
multi-channel operation -- we'll eventually need
that in the future anyway. There's one userland API
change and one API addition. The API change is that
now SET_WIPHY must be called with virtual interface
index rather than only wiphy index in order to take
effect for that interface -- luckily all current
users (hostapd) do that. For monitor interfaces, the
old setting is preserved, but monitors are always
slaved to other devices anyway so no guarantees.
Real hardware are not capable of listening on multiple channels (except
2 ht20 channels in ht40 mode, maybe?). So I don't understand why we
should have a per-interface channel.
I think we should either have two strategies :
- "first one is the winner" : once a channel has been set, it cannot be
changed. For instance, if you create an AP interface (with hostapd) and
latter a STA interface, the STA interface can only scan on the channel
the AP is.
- "last one is the winner" : in this case, the last call to set the
channel is always successful. Of course, this will change channel on
existing interfaces which might change their IE accordingly, through an
appropriate API.
I might be wrong, but I don't see this multi-channel usage...
Regards,
Benoit
--
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
