Wireless must bee kept alive by simultaneous pings

[Rui Paulo]

On 29 May 2010, at 15:24, elekktretterr at 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 at 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 at 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