why does it discard the received frames prior to doing the initial channel change?

Jaeryong Hwang <[email protected]> Thu, 8 Apr 2010 12:05:10 +0900
Newsgroups gmane.linux.drivers.madwifi.user
Message-ID <[email protected]>
I have found that STA discard the received frame during channel switching
I modified the madwif driver to scan periodically, but I have experienced
two or three packet drops during channel switching. STA sends a null frame,
and the associated AP is in power save mode. Then, STA goes off channel and
scans other channel. From the above process, I wonder why the received
frames prior to send a null frame are discarded though STA received the
frames and sent the acknowledgement ?
I can see the following source code on /net80211/ieee802.11_scan.c, but I
don't understand the reasons. Please give me a more detailed explain that.

00479 if ((ic->ic_flags & IEEE80211_F_SCAN) == 0 &&
00480     time_before(jiffies, ic->ic_lastscan + vap->iv_scanvalid)) {
00481 /*
00482 * We&apos;re not currently scanning and the cache is
00483 * deemed hot enough to consult. Lock out others
00484 * by marking IEEE80211_F_SCAN while we decide if
00485 * something is already in the scan cache we can
00486 * use. Also discard any frames that might come
00487 * in while temporarily marked as scanning.
00488 */
00489 SCAN_PRIVATE(ss)->ss_iflags |= ISCAN_DISCARD;


00571 /* NB: flush frames rx&apos;d before 1st channel change */
00572 SCAN_PRIVATE(ss)->ss_iflags |= ISCAN_DISCARD;


00832 /*
00833 * Frames received during startup are discarded to avoid
00834 * using scan state setup on the initial entry to the timer
00835 * callback. This can occur because the device may enable
00836 * rx prior to our doing the initial channel change in the
00837 * timer routine (we defer the channel change to the timer 00838 * code
to simplify locking on linux).
00839 */

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Madwifi-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-users