On Saturday 01 March 2008 00:09, Johannes Berg wrote: > Hi, > > > For example rt2x00 devices only have one promiscuous mode that covers > > traffic in the same and other BSSes therefore if either of > > FIF_PROMISC_IN_BSS or FIF_OTHER_BSS are set then the driver will set both > > of them in the returned flags value. > > > > It will also for some devices set the FIF_ALLMULTI flag if mc_count is > > non zero. > > > > If this behaviour is considered desirable then I'll keep it working when > > making the change but if not I'll remove it. > > Interesting. I don't think I have an opinion right now. I wanted to be > strict about clearing the flags so that you don't end up with a flag > that we never get traffic for, but I can't imagine any check where you'd > want to know "do I get traffic XY". The only way I think it might be useful is if it allows mac80211 to not bother with checks that it would otherwise do, for example if mac80211 didn't want to pass multicast packets that were not for us up to the higher stack layers it would know that if FIF_ALLMULTI got set it needed to do some filtering but if it wasn't set the hardware had a working multicast address filter. > > How do you keep track of that anyway? Say somebody enables > FIF_PROMISC_IN_BSS and you also set FIF_OTHER_BSS, then when > FIF_PROMISC_IN_BSS is disabled again FIF_OTHER_BSS should be disabled > too but how know that it wasn't set in the meantime? I think that says > that you shouldn't do that... > rt2x00 ignores the changed_flags passed from mac80211 and keeps track for itself of what filter it is applying so it will always recalculate it's own filter based on total_flags and reconfigure the hardware if it changes. This does assume that mac80211 recalculates what it wants total_flags to be each time configure_filter is called rather than just changing the value it got back last time but that appears to be a valid assumption. Adam -- 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
