On 29 May 2010, at 15:24, elekktrett...@exemail.com.au 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 <elekktrett...@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 <elekktrett...@exemail.com.au> 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. Regards, -- Rui Paulo
