DragonFly commits List (threaded) for 2007-06
DragonFly BSD
DragonFly commits List (threaded) for 2007-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Sepherosa Ziehau <sephe@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 15 Jun 2007 05:04:45 -0700 (PDT)

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

DragonFly src repository

  Modified files:
    sys/netproto/802_11/wlan ieee80211_input.c 
  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


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]