On Tue, 31 Jul 2007 00:52:05 +0200, Ulrich Kunitz wrote: > What about add_interface/remove_interfaces and monitor interfaces? It depends on the IEEE80211_HW_MONITOR_DURING_OPER flag in hw.flags. If you set the flag in the driver, then monitor interfaces work in the exactly same way as STA or IBSS interfaces - the add_interface callback is called (with conf.type equal to IEEE80211_IF_TYPE_MNTR) whenever user brings up a monitor interface. You are responsible for switching the card to a monitor mode (e.g. turning off hardware packet filtering). If your hardware can't support monitor and regular interfaces concurrently, don't set the IEEE80211_HW_MONITOR_DURING_OPER flag. In this case, the stack calls add_interface with IEEE80211_IF_TYPE_MNTR in conf.type only when there is no other interface active. If the user brings up a monitor interface while he has a regular interface active, the driver is not notified about that and the monitor interface is emulated by the stack with a limited capabilities (this is called "soft monitor mode"). > There seems to be difference between "hard" and "soft" monitor > mode. Currently I'm not sure what the semantics is. You don't need to care about that in a driver, there is no difference for a driver as you will never see a soft monitor interface; it's a mac80211-level thing only. >From the perspective of a user (and user space), the difference is as follows: "Hard monitor mode" is the usual monitor mode, i.e. all incoming frames, regardless of their source/destination MAC addresses, are received through the monitor interface. "Soft monitor mode" is relevant only when the hardware has limited capabilities for filter settings _and_ you have both regular (e.g. STA) and monitor interface active (ifconfig up'ed). In such case, you receive only frames addressed to your MAC address through the monitor interface. This is still useful e.g. for debugging of network problems as you see management frames. > There seems to > be also calls to add_interface/remote_interface with if_id -1. I > guess that means something like all interfaces. The expected > behaviour is not documented for that case. As Michael correctly said, don't care about the value, just store it and hand it back to the stack when the stack wants it. Jiri -- Jiri Benc SUSE Labs - 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
