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

On 26 February 2015 at 02:20, Jouni Malinen 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 workaround p

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

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 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org htt

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

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

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

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 co

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

On Wed, Feb 25, 2015 at 10:14 AM, Linus Torvalds 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 Atheros-specific in any way - i

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

On Thu, Feb 26, 2015 at 7:22 AM, Adrian Chadd wrote: > On 25 February 2015 at 10:14, 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 patc

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

Hi Jouni, >> In case of ath9k, the driver in xmit.c allocates in function >> ath_tx_fill_desc() a struct ath_tx_info info by memset(&info, 0, >> sizeof(info)) .. so all info->rates[xy].Rate == 0. >> Than function ath_buf_set_rate() sets all info->rates[xy].Rate to those >> values specified in

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

On 25 February 2015 at 10:14, 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? > > I'm talking about the two from Jouni - the "do

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

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

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

On Wed, Feb 25, 2015 at 6:47 AM, Jouni Malinen 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 established in m

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

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 an

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

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

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

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 w

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

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 softwar

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

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 (id

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

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 in

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

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

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

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 prob

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

On Tue, Feb 24, 2015 at 2:26 AM, Jouni Malinen 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;

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

(sorry to send HTML the first time... oops) 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; minstrel-ht doesn't do that right, and can pick a fairly flaky rate instead. Can't generat

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

Ah, I see. It's probably the time limit then (segment_size in Minstrel terms). But we don't want to change that for general packets... I will think about the right way to do that. On Tue, Feb 24, 2015 at 9:26 PM, Jouni Malinen wrote: > On Tue, Feb 24, 2015 at 01:29:27PM +1100, Andrew McGregor

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

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; minstrel-ht doesn't do that right, and can pick a fairly flaky rate instead. Can't generate a proper patch right now, so this diff migh

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

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; minstrel-ht doesn't do that right, and can pick a > fairly fl

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

Jouni Malinen wrote: > Even I think that this goes a bit too far especially on 2.4 GHz band, > but I would actually consider limiting EAPOL frames to using non-HT/VHT > (e.g., 6 Mbps OFDM at least for EAPOL-Key frames) to avoid some > interoperability issues. I would say that the current minstrel_h

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

On Mon, Feb 23, 2015 at 03:00:39PM -0800, Linus Torvalds wrote: > On Mon, Feb 23, 2015 at 2:43 PM, Jouni Malinen wrote: > > > > This did not get exactly supportive response when this was proposed last > > time (Sep 2013). Anyway, for a quick test, this can be done with the > > following one-liner:

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

On Mon, Feb 23, 2015 at 2:43 PM, Jouni Malinen wrote: > > This did not get exactly supportive response when this was proposed last > time (Sep 2013). Anyway, for a quick test, this can be done with the > following one-liner: fwiw, that one-liner seems to work fine for me. Which I guess is not a

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

On Mon, Feb 23, 2015 at 02:22:32PM -0800, Adrian Chadd wrote: > On 23 February 2015 at 13:53, Linus Torvalds > wrote: > > So the theory that the driver starts at too high a transmit rate, and > > then does not handle failures well, might be true. Of course, "not > > handle failures well" is someth

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

On 23 February 2015 at 13:53, Linus Torvalds wrote: > On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen wrote: >> >> How far is the station from the AP? Would it be possible to see whether >> the behavior changes if you were within, say, five meters or so? > > Well, it was pretty much within five me

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

On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen wrote: > > How far is the station from the AP? Would it be possible to see whether > the behavior changes if you were within, say, five meters or so? Well, it was pretty much within five meters already, but there was a thin wall in between (and the o

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

On Mon, Feb 23, 2015 at 12:06:09PM -0800, Linus Torvalds wrote: > On Mon, Feb 23, 2015 at 9:17 AM, Jouni Malinen wrote: > > mac80211: Do not encrypt EAPOL frames before peer has used the key > > Hmm. This patch does not seem to make a difference. I thought it did > at first, but then removed the

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

On Mon, Feb 23, 2015 at 12:06 PM, Linus Torvalds wrote: > > This machine has a fairly minimal kernel config. Does that "type > monitor" interface perhaps need some debug infrastructure that I > haven't added? Nope. Same behavior with a F21 kernel (which means that the touchpad doesn't work, but t

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

On Mon, Feb 23, 2015 at 9:17 AM, Jouni Malinen wrote: > > mac80211: Do not encrypt EAPOL frames before peer has used the key Hmm. This patch does not seem to make a difference. I thought it did at first, but then removed the wpa_supplicant debugging, and got the same failures. On Sun, Feb 22, 20

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

If it is the case that the 4-way handshake fails, then I have seen this issue before. The problem is that messages 1 to 4 are sent with the previous key. However, right after sending message 4/4, does wpa_supplicant set the new key. In some cases, such as in a high throughput environment, this

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

On Mon, Feb 23, 2015 at 11:55:30AM +0100, wim torfs wrote: > If it is the case that the 4-way handshake fails, then I have seen > this issue before. The problem is that messages 1 to 4 are sent with > the previous key. However, right after sending message 4/4, does > wpa_supplicant set the new key.

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

On Sun, Feb 22, 2015 at 05:41:25PM -0800, Linus Torvalds wrote: > Ok. Attached is what seems to be the relevant part of the > wpa_supplicant.log file. > > The datestamp has been changed so that it can be matched up with the > dmesg, and I added empty lines for pauses when I was trying to figure >

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

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 ___ ath9k-devel mailing list ath9k-devel@lists

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

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

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

So the interesting part thus far: 14:07:23.513500: RTM_NEWLINK: operstate=1 ifi_flags=0x1003 ([UP]) 14:07:23.513662: RTM_NEWLINK, IFLA_IFNAME: Interface 'wlp1s0' added 14:07:23.513842: nl80211: if_removed already cleared - ignore event 14:07:23.536309: nl80211: Event message available 14:07:23.536

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

On Sun, Feb 22, 2015 at 5:55 PM, Adrian Chadd wrote: > > Do you have a 5GHz SSID setup on this access point? Is this kind of > messed up diassociation-to-steer-you-to-another-band thing? Nope. That's the older single-band UniFi UAP - 2.4GHz only. Linus

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

On 22 February 2015 at 17:41, Linus Torvalds wrote: > On Sun, Feb 22, 2015 at 4:54 PM, Adrian Chadd wrote: >> >> I /think/ it's okay? The removed stuff is the pre-shared key pieces. > > Ok. Attached is what seems to be the relevant part of the > wpa_supplicant.log file. > > The datestamp has been

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

On Sun, Feb 22, 2015 at 4:54 PM, Adrian Chadd wrote: > > I /think/ it's okay? The removed stuff is the pre-shared key pieces. Ok. Attached is what seems to be the relevant part of the wpa_supplicant.log file. The datestamp has been changed so that it can be matched up with the dmesg, and I added

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

Linus Torvalds wrote: > I've got the wpa supplicant log for this timeframe, but I'd rather not > send it out in public. I see "[REMOVED] for what looks like the key > data, but there's a lot of other hex data. Is any of it sensitive? Unless the '-K' option is used with wpa_s, the keys are not disp

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

On 22 February 2015 at 15:00, Linus Torvalds wrote: > On Sun, Feb 22, 2015 at 1:50 PM, Linus Torvalds > wrote: >> >> Ugh. When I add "-dd" to the command line, it has now worked three >> times in a row, when before it worked once out of ten tries. >> >> So my guess is that it's something timing-d

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

On Sun, Feb 22, 2015 at 1:50 PM, Linus Torvalds wrote: > > Ugh. When I add "-dd" to the command line, it has now worked three > times in a row, when before it worked once out of ten tries. > > So my guess is that it's something timing-dependent. So it stays working with -dd, but I do get *occasio

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

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 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

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

On Sun, Feb 22, 2015 at 11:39 AM, Adrian Chadd wrote: > > Hm, can you enable wpa debugging to log everything whilst it's > associating / reassociating? Ugh. When I add "-dd" to the command line, it has now worked three times in a row, when before it worked once out of ten tries. So my guess is t

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

On Sun, Feb 22, 2015 at 10:58 AM, Dave Taht 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*. There's clearl

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

On 22 February 2015 at 10:30, Linus Torvalds wrote: > On Sun, Feb 22, 2015 at 10:24 AM, Adrian Chadd wrote: >> >> Just a wild shot - try disabling fast authentication and see if that >> makes a difference? >> >> wpa_supplicant.conf: >> >> fast_reauth=0 >> >> I recall having issues with fast_reaut

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

On Sun, Feb 22, 2015 at 10:30 AM, Linus Torvalds wrote: > On Sun, Feb 22, 2015 at 10:24 AM, Adrian Chadd wrote: >> >> Just a wild shot - try disabling fast authentication and see if that >> makes a difference? >> >> wpa_supplicant.conf: >> >> fast_reauth=0 >> >> I recall having issues with fast_r

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

On Sun, Feb 22, 2015 at 10:24 AM, Adrian Chadd wrote: > > Just a wild shot - try disabling fast authentication and see if that > makes a difference? > > wpa_supplicant.conf: > > fast_reauth=0 > > I recall having issues with fast_reauth once, but I never stuck around > that location long enough to

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

On 21 February 2015 at 15:34, Linus Torvalds wrote: > So I've had problems connecting to some networks before on my > Chromebook Pixel, but now I'm testing a new Ubiquiti network at home, > and can see this issue at home too. > > I know the wireless works, because other devices work fine on that >

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

On Sat, Feb 21, 2015 at 10:50 PM, Sujith Manoharan wrote: > > Can you please post the output of 'iw dev wlp1s0 scan' ? Attached. It's the "UniFi-home" SSID that doesn't work. The 1gnoraNT one is the old working one that I'm obviously associated with, and that has multiple AP's. (The UniFi-home

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

Linus Torvalds wrote: > So I've had problems connecting to some networks before on my > Chromebook Pixel, but now I'm testing a new Ubiquiti network at home, > and can see this issue at home too. Can you please post the output of 'iw dev wlp1s0 scan' ? Sujith _

[ath9k-devel] AR9462 problems connecting again..

So I've had problems connecting to some networks before on my Chromebook Pixel, but now I'm testing a new Ubiquiti network at home, and can see this issue at home too. I know the wireless works, because other devices work fine on that network. Also, I know the AR9462 works, because I still have my