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'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'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® 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