Re: Wireless must bee kept alive by simultaneous pings

[Rui Paulo <rpaulo@xxxxxxxxxxx>]

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