Search Linux Wireless

Re: [ath9k-devel] AR9462 problems connecting again..

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 25, 2015 at 06:00:08PM +1300, Felix Fietkau wrote:
> Minstrel_ht does *NOT* use mrr[3], nor should it. For normal data
> packets, a little packet loss under tough conditions is good, otherwise
> we risk lots of wasted airtime and bufferbloat.

I agree for normal data packets, but EAPOL frames are not really normal
data packet even though they happen to be transmitted as Data frames.
EAPOL frames are rare enough to not wast much airtime (and recovery from
an issue would anyway use way more airtime) and bufferbloat is
irrelevant for EAPOL frames. For EAPOL frames, little packet loss is not
good. Especially for EAPOL-Key msg 4/4, the only recovery option in many
cases is to reassociate with the AP and start from scratch.

> > That mrr[3]:= basic_rate is the part I was really asking for as far as
> > EAPOL frames are concerned.
> I don't think we need that. If we just exclude EAPOL from both probing
> and aggregation, it should be safe. While it's connecting, that leaves
> in low rates in the retry chain anyway.

Not low enough IMHO. EAPOL is a special case and needs to be addressed
as such. It is special for at least two reasons: being very early in the
association (well, the very _first_ Data frames using rate control) and
being critical for maintaining the connection (AP will disconnect if it
does not reply response).

What happens now is way too optimistic:
- one try at MCS 2 followed by four tries at MCS 0 for EAPOL-Key msg 2/4
- one try at MCS 9 (or so) followed by four tries at MCS 0 for EAPOL-Key
  msg 4/4 (this being the most critical frame in the connection sequence
  due to not having a good recovery mechanism)

Dropping probing from these would allow one more attempt at the first
rate and I guess it would also drop the first rate to somewhat lower.

I'm fine with using these MCS rates as the first option, but I do think
that we have to add one more rate to the end (or change the 3rd rate if
that is easier for implementation) to be non-MCS and I think one of the
basic rates (say, 6 Mbps on 5 GHz and maybe 2 or 5.5 Mbps on 2.4 GHz)
with number of tries (say, 4).

There have been way too many cases reported where "strange issues" with
4-way exchange (those EAPOL-Key frames) result in connection failing.
While not all of these can be explained with the TX rate, I'm pretty
sure large portion of these issues are indeed caused by too optimistic
TX rate selection. Such policies may be acceptable for other Data
frames, but not for EAPOL.

> If it still fails often enough to be noticeable under normal conditions,
> there must be something seriously wrong outside of rate control, and we
> should not paper over it with a crude band-aid workaround.

There may be something else wrong (say, some kind of interference), but
there is no way we can assume normal users to be able to fix such
issues. If we make EAPOL frames go through more robustly, the connection
can be established in more cases and this can result in relatively
functional network connection and rate control can handle the less
critical data frames through whatever means to get optimal throughput
from the network. As such, I do think we do need to "paper over" this
for EAPOL frames.

-- 
Jouni Malinen                                            PGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux