Wireless must bee kept alive by simultaneous pings
rpaulo at FreeBSD.org
Mon May 31 08:25:48 PDT 2010
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.
> 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
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
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
Reported-by: Petr Janda <elekktretterr at exemail.com.au>
Try doing something like this:
If it works, I'll commit it in FreeBSD.
More information about the Kernel