Re: Wireless must bee kept alive by simultaneous pings
On 31 May 2010, at 16:23, Rui Paulo wrote:
>
> On 29 May 2010, at 15:24, elekktretterr@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 <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>
>
>
> 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
討論串 (同標題文章)
完整討論串 (本文為第 7 之 9 篇)：