On Wed, 2011-01-26 at 10:39 -0800, Ben Greear wrote:
> The offchannel_stop_beaconing doesn't actually change
> state, it just calls
>
> ieee80211_bss_info_change_notify(
> sdata, BSS_CHANGED_BEACON_ENABLED);
>
> That method will disable beaconing if SCAN_SW_SCANNING is set,
> regardless of current channel.
>
> So, if that work.c logic is happening during a scan, we
> will always disable scanning, but if we are not SW scanning,
> then that offchannel_stop_beaconing won't actually do
> anything useful.
> My first inclination is to add another check in bss_info_change_notify
> to test if we are really off-channel:
>
> if (local->quiescing || !ieee80211_sdata_running(sdata) ||
> (test_bit(SCAN_SW_SCANNING, &local->scanning) &&
> test_bit(SCAN_OFF_CHANNEL, &local->scanning)) {
> sdata->vif.bss_conf.enable_beacon = false;
>
> And either set the SCAN_OFF_CHANNEL flag before calling offchannel_stop_beaconing,
> or perhaps set that flag in offchannel_stop_beaconing. The first might be
> less risky, but that leaves the work.c logic funky in my opinion, since if
> we are not actually scanning, beacons will still be enabled.
Yes, I'm a bit concerned about that too -- that bit really shouldn't be
in the scan bits, and then we can set it in offchannel_stop_beaconing or
whatever the combination ends up being called.
> I could use some suggestions on how to proceed. I am overly tempted to
> start changing everything in sight, but that is likely to cause all sorts
> of bugs, subtle and otherwise....
:)
I've long been tempted to rewrite scanning in terms of off-channel work
items ... Not really sure what to do.
johannes
--
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
