cvs commit: src/sys/netproto/802_11/wlan ieee80211_input.c

[Sepherosa Ziehau <sephe@xxxxxxxxxxxxxxxxxxxxxxx>]

sephe       2007/06/15 05:04:45 PDT

DragonFly src repository

  Modified files:
    sys/netproto/802_11/wlan ieee80211_input.c 
  Log:
  Some non-802.11e non-standard conforming APs use seperate TX sequences
  for non-beacon frames and beacons.  If local cache of <addr2,seq,fragno>
  tuple is updated when beacons from such kind of AP are received, 802.11
  duplication detection mechanism may decide to discard non-beacon retry
  frames if its sequence is less than or equal to just received beacon's.
  Together with the poor TX rate control algorithm chosen by these kinds
  of APs, i.e. a lot of retry data frames, a TCP connection can be choked
  by STA's duplication detection mechanism.
  
  To handle these kinds of APs (yep, we are in the world of compat):
  Don't update cache of <addr2,seq,fragno> tuple for multicast or broadcast
  802.11 MAC frames.  This does not violate IEEE Std 802.11, 1999 Edition
  subclause 9.2.9, which actually allows us to "omit tuples obtained from
  broadcast/multicast ...".
  
  Thank Petr Janda <elekktretterr@exemail.com.au> for providing all
  necessary 802.11 tcpdumps to track down the problem.
  
  Thank dillon@ for analyzing some tcpdumps which leads me to think that
  the reported problem may be caused by the duplication detection in
  802.11 layer.
  
  Reported-by: Petr Janda <elekktretterr@exemail.com.au>
  Tested-by: Petr Janda <elekktretterr@exemail.com.au>
  
  Revision  Changes    Path
  1.21      +1 -1      src/sys/netproto/802_11/wlan/ieee80211_input.c


http://www.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/wlan/ieee80211_input.c.diff?r1=1.20&r2=1.21&f=u