Jouni Malinen wrote:
punishing the vast majority of cases where the AP is perfectly fine
with higher MCS rates
First make it work (everywhere), then make it fast (where possible).
//Peter
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to
On 26 February 2015 at 02:20, Jouni Malinen j...@w1.fi wrote:
On Wed, Feb 25, 2015 at 10:14:45AM -0800, Linus Torvalds wrote:
While I realize that people may disagree about the exact details of
how to fix this in the long run, may I suggest that in the meantime we
at least get the two
On 02/26/15 06:55, Linus Torvalds wrote:
Because it looks like the brcmsmac driver has*exactly* the same
behavior with this AP (in an Apple Macbook air). I assume brcmsmac
uses the net/80211/tx.c logic too.
That makes sense as brcmsmac is a mac80211 driver that uses the
minstrel-ht rate
On Wed, Feb 25, 2015 at 10:14:45AM -0800, Linus Torvalds wrote:
While I realize that people may disagree about the exact details of
how to fix this in the long run, may I suggest that in the meantime we
at least get the two workaround patches applied?
Does anybody hate Jouni's two patches
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
On Tue, Feb 24, 2015 at 11:38:02PM +0100, Thomas Hühn wrote:
Minstrel_HT does only set mrr[0..2] and does not touch the fourth mrr[3],
assumed chips with 4 mrr stages.
In function minstrel_ht_update_rates() the rate table struct
ieee80211_sta_rates is set for the first 3 out of 4 rates and
On Wed, Feb 25, 2015 at 6:47 AM, Jouni Malinen j...@w1.fi wrote:
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
Linus Torvalds wrote:
Last time I had connection issues with this laptop, nothing ended up
happening in the end, and I had people pipe up saying they had had
similar problems. I'd hate for the same nothing to happen this time
just because people aren't 100% sure what the final right thing is
On 25 February 2015 at 10:14, Linus Torvalds
torva...@linux-foundation.org wrote:
While I realize that people may disagree about the exact details of
how to fix this in the long run, may I suggest that in the meantime we
at least get the two workaround patches applied?
I'm talking about the
On Thu, Feb 26, 2015 at 7:22 AM, Adrian Chadd adr...@freebsd.org wrote:
On 25 February 2015 at 10:14, Linus Torvalds
torva...@linux-foundation.org wrote:
While I realize that people may disagree about the exact details of
how to fix this in the long run, may I suggest that in the meantime we
On Wed, Feb 25, 2015 at 10:14 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
I'm talking about the two from Jouni - the don't encrypt EAPOL
frames one, and the one-liner that makes all EAPOL frames go at the
lowest data rate.
So I just found out and confirmed that this is not
On Tue, Feb 24, 2015 at 2:26 AM, Jouni Malinen j...@w1.fi wrote:
On Tue, Feb 24, 2015 at 01:29:27PM +1100, Andrew McGregor wrote:
Over the weekend I found a bug in minstrel-ht that might well be
implicated here.
The last retransmit rate is meant to be a 'get the packet there
reliably' rate;
Hi Jouni,
Currently Minstrel_HT just skips EAPOL packets for its rate sampling on non-mrr
chips by testing: (info-control.flags IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
On mrr hardware it uses them for probing.
But the general MRR-chain should look like this for ath5k and ath9k chips that
support 4
On Tue, Feb 24, 2015 at 06:54:47PM +0100, Thomas Hühn wrote:
Currently Minstrel_HT just skips EAPOL packets for its rate sampling on
non-mrr chips by testing: (info-control.flags
IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
Yeah, I noticed that when going through the implementation, but it was
indeed
Hi,
I thought about doing this for rate probing with FreeBSD's sample rate
algorithm, but after actually having to use the damned thing in noisy
environments I realised that it just wasn't worth the effort to
optimise rate control selection whilst doing EAPOL frames.
If we did more useful
Hi Jouni,
Where is that mrr[3] part implemented? I did not find it when reviewing
the design (hw-max_rates = 3 is used, but not = 4) and this does not
match my experiments either when printing out all four values from
ath9k. In every single case I observed, the last entry was unused (idx =
On 2015-02-25 07:14, Jouni Malinen wrote:
On Tue, Feb 24, 2015 at 06:54:47PM +0100, Thomas Hühn wrote:
Currently Minstrel_HT just skips EAPOL packets for its rate sampling on
non-mrr chips by testing: (info-control.flags
IEEE80211_TX_CTRL_PORT_CTRL_PROTO)
Yeah, I noticed that when going
On Sun, Feb 22, 2015 at 10:30 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Sun, Feb 22, 2015 at 10:24 AM, Adrian Chadd adr...@freebsd.org wrote:
Just a wild shot - try disabling fast authentication and see if that
makes a difference?
wpa_supplicant.conf:
fast_reauth=0
I
On Sun, Feb 22, 2015 at 4:54 PM, Kyle Bassett kylebass...@gmail.com wrote:
On Sun, Feb 22, 2015 at 4:45 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Sun, Feb 22, 2015 at 10:58 AM, Dave Taht dave.t...@gmail.com wrote:
Hint: Several unifi (and most ubnt) products are well
On Sun, Feb 22, 2015 at 10:58 AM, Dave Taht dave.t...@gmail.com wrote:
Hint: Several unifi (and most ubnt) products are well supported by
openwrt directly,
I want Linux to just work. None of this oh, you can change
something else and it probably works. I want to fix the problem in
*linux*.
Linus Torvalds wrote:
14:07:23.542927: wlp1s0: Event DEAUTH (12) received
14:07:23.542946: wlp1s0: Deauthentication notification
14:07:23.542964: wlp1s0: * reason 2
14:07:23.542982: wlp1s0: * address 20:9f:db:e7:80:80
14:07:23.542997: Deauthentication frame IE(s) - hexdump(len=0): [NULL]
Sujith Manoharan wrote:
'iw dev wlp1s0 set bitrates ht-mcs-2.4 1' would choose a lower
rate for the key-exchange frames.
Or 'iw dev wlp1s0 set bitrates ht-mcs-2.4 0' to choose the lowest
HT rate.
Sujith
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a
22 matches
Mail list logo
