On 01/31/2011 05:56 AM, Johannes Berg wrote:
However -- I was thinking of something else, not data packets. While
scanning, all received beacons will be handed to the scan code. But if
the mlme code isn't told to stop looking for them, it'll still expect to
see the beacons.
Currently, it seems mlme timers are stopped when we start scanning,
and then started when scanning is complete.
Ok, I wasn't quite sure about that part -- whether it happened when
going off-channel or when starting scan. If it happened while going
off-channel this would've been problematic here.
However, I don't see any similar effort in the work_work() method
when it goes off-channel.
Should we move the timer pause& restart logic into the offchannel_stop_vifs
and offchannel_return methods?
Well, sort of no, and sort of yes -- both will disrupt that code in a
sense, but even scanning on the same channel will disrupt it due to the
beacon diversion, unless we copy the beacons and give them to both sides
(scan and mlme)?
Seems to me both sides should get them. I'll try to figure out how to
do that properly today.
But, if work_work() takes us off-channel often enough, wouldn't that
cause undue beacon loss and/or timed-out tx acks? Are there any guarantees
about how often and how long work_work() can take us off-channel?
Thanks,
Ben
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
