On 31 May 2010, at 16:23, Rui Paulo wrote: > > On 29 May 2010, at 15:24, [email protected] wrote: > >>> What driver/chipset are you using? SMP or UP kernel? What AP are you >>> connecting to? >> >> atheros. SMP kernel. The AP is a Billion ADSL2+ router. It should be noted >> that in every OS other than FBSD/Dragonfly ive tried - windows and linux - >> it works fine. >> >> I should also note that Sepherosa once made a patch for me that got >> commited but probably got blasted away during the wlan update. Its >> referenced in this thread but its no longer in Sephe's directory. >> >> http://leaf.dragonflybsd.org/mailarchive/bugs/2007-06/msg00012.html >> >> I should note that, this only improved the situtation, it did not fix it. >> Connections were still dropping out, just not as often. >> > > Revision 1.21 / (download) - annotate - [select for diffs], Fri Jun 15 > 12:04:45 2007 UTC (2 years, 11 months ago) by sephe > Branch: MAIN > CVS Tags: DragonFly_RELEASE_1_12_Slip, DragonFly_RELEASE_1_12, > DragonFly_RELEASE_1_10_Slip, DragonFly_RELEASE_1_10 > Changes since 1.20: +1 -1 lines > Diff to previous 1.20 (colored) > > 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 <[email protected]> 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 <[email protected]> > > > Try doing something like this: > http://cvsweb.dragonflybsd.org/cvsweb/src/sys/netproto/802_11/wlan/ieee80211_input.c.diff?r1=1.20&r2=1.21 > > If it works, I'll commit it in FreeBSD.
I've fixed this in FreeBSD. Regards, -- Rui Paulo
