On Wed, 15 Mar 2006 15:58:45 -0800, Jouni Malinen wrote: > Neither did I at first, but after some debugging, I would assume that > you actually meant to return from ieee80211_ioctl_siwap() if the > previous address is identical to the new one, not if it has changed.. In > other words: > > [...] > - ETH_ALEN) != 0) > + ETH_ALEN) == 0)
Thanks! > This was enough to fix wds.peer address and get rid of the old STA > entry. However, new STA entry was not added for the new peer address. It's not added when using PRISM2_HOSTAPD_UPDATE_IF as well. Needs to be fixed. > I have now tested AP mode up to and including patch 5/13. This was > still allowing multi-BSSID to be used successfully. Patch 6/13 breaks > multi-BSSID configuration since our low-level driver needs bssid_mask > and bss_count to be configured. I need to take a closer look at how this > can be avoided with the new add_interface notification and automatic > BSSID mask calculation at the low-level driver. bss_count is easy, just increment/decrement number of interfaces in add_interface/remove_interface. bss_mask is harder, it needs to be calculated in the driver, but right now there is no way to get needed information for the driver. I'm going to post a patch in a moment. > Patch 7/13 breaks everything since we currently start with radio > disabled by default.. I can change that to be the other way around to > avoid this, The radio should be unconditionaly disabled when all interfaces are down. I see no reason why not to enable radio when an interface is brought up. > but there are still some cases that need to be resolved > (e.g., need to stop TX/RX when a radar is detected for the duration of > scan for a new channel). I don't want to bring down all network > interfaces for that, so some kind of mechanism for temporarily disabling > TX/RX would be useful to have. Yes. But this is another problem - you want to disable TX queue, but not the whole radio. -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
