iwlmvm crashes when connecting to a WPA-Enterprise network

each time I connect to the corporate wpa-enterprise network, iwlmvm crashes distro is ArchLinux - kernel is 4.19.0-rc8+ - networkmanager 1.14.1dev+13+g0d3234478-1 - wpa_supplicant 1:2.6-12 [ 1257.940526] BUG: scheduling while atomic: irq/133-iwlwifi/388/0x0403 [ 1257.940535] Modules linked

Mwifiex_pcie issues while connecting to access point.

Hi All, We use the mwifiex driver for wifi from kernel-backports-4.2.6.1 for kernel version 3.2.26 and mwifiex driver from kernel tree 4.1.8 without backporting for kernel 4.1.8. We are having issues connecting to the access point and looks like authenticating issues during the initial

[PATCH 11/26] iwlwifi: mvm: fix the recovery flow while connecting

From: Emmanuel Grumbach In BSS mode in the disconnection flow, mac80211 removes the AP station before the vif is set to unassociated. Our firmware wants it the other way around: first set the vif as unassociated, and then remove the AP station. In order to bridge

Re: Problem connecting to wifi on libertas_cpio (sd8686)

On Sat, 2016-07-23 at 06:26 -0700, Christopher Williamson wrote: > Quick follow-up - I suspected the issue may be with wpa_supplicant > rather than udev / kernel config. > > Since this does connect properly on open wireless networks the issue > is now only with WPA/WPA2. > > It seems even the

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Quick follow-up - I suspected the issue may be with wpa_supplicant rather than udev / kernel config. Since this does connect properly on open wireless networks the issue is now only with WPA/WPA2. It seems even the latest dev builds of Ubuntu are still stuck using wpa_supplicant 2.4.x rather

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Just to follow up on this - I performed a minimal ubuntu server install (16.04.1), commented out the crda udev rule (since that was setting the weird country: 98 issue) and tried again and it still didn’t work. I did confirm that the md5 sums for the firmware included with Arch is the exact same

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Hi all, So I decided to have another fiddle with this and managed to get the WiFi working perfectly first time on an ArchLinux LiveCD so it looks like this issue is Ubuntu specific. I’m going to copy the firmware files and check if they’re responsible and work my way through the various

Re: Problem connecting to wifi on libertas_cpio (sd8686)

I haven’t managed to get connected to a WPA network either so it looks like open only at the moment but I fear that may just have been a fluke. A big problem I’m facing is that editing /etc/default/crda to REGDOMAIN=GB wasn’t enough to set the wifi regulation mode to GB and I have to set it

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Disregard - I have actually managed to get this to connect to a open network! # iw reg set GB # iw reg get country GB: DFS-ETSI (2402 - 2482 @ 40), (N/A, 20), (N/A) (5170 - 5250 @ 80), (N/A, 20), (N/A) (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS (5490 - 5710 @ 160),

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Ok so I created a guest wifi network without any encryption enabled at all and the client still refuses to connect. Again, the connection is made perfectly using the USB dongle I have but not the built in libertas sd8686 chipset. I do currently use pfSense as a firewall box behind my wireless

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Hi Dan, I will check out the WPA2 vs WPA vs open wireless thing in a few mins. For now though - the iwlist scan results for both a USB device and the libertas device: USB: http://termbin.com/hdwl Libertas: http://termbin.com/jxh7 Will follow up shortly with WPA and Open network configs.

Re: Problem connecting to wifi on libertas_cpio (sd8686)

> > > > > > > > the > > > > > > > > > > following results: > > > > > > > > > > > > > > > > > > > > http://termbin.com/j8ea > > > > > > > > > > > > > &

Re: Problem connecting to wifi on libertas_cpio (sd8686)

irectly and get > > >>>>>>> the > > >>>>>>> following results: > > >>>>>>> > > >>>>>>> http://termbin.com/j8ea > > >>>>>>> > > >>>>&g

Re: Problem connecting to wifi on libertas_cpio (sd8686)

gt; Can you try with "-D nl80211" instead of using the WEXT > >>>>>> supplicant > >>>>>> driver? NM is likely going to use nl80211 since the driver has > >>>>>> some > >>>>>> support

Re: Problem connecting to wifi on libertas_cpio (sd8686)

>>> support for cfg80211/nl80211 and only does WEXT through the glue >>>>>> layer. >>>>>> >>>>>> Dan >>>>>> >>>>>>> >>>>>>> Christopher Williamson >>>>>>>

Re: Problem connecting to wifi on libertas_cpio (sd8686)

; > > > > > > > > On 20 July 2016 at 22:50:34, Dan Williams > > > > > > (d...@redhat.com(mailto:d...@redhat.com)) wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >

Re: Problem connecting to wifi on libertas_cpio (sd8686)

> > > > > > > > > > > > > > > > > > On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi Dan, &

Re: Problem connecting to wifi on libertas_cpio (sd8686)

> Hi Dan, > > > > > > > > > > > > Ah - yeah I hadn’t thought it may be a kernel build option. > > > > > > I’ve > > > > > > now > > > > > > built that and dmesg is a much more lively place! > > > >

Re: Problem connecting to wifi on libertas_cpio (sd8686)

> > > > now > > > > > built that and dmesg is a much more lively place! > > > > > > > > > > I’ve provided output logs for both when the device is connected > > > > > and > > > > > when a connection attempt is

Re: Problem connecting to wifi on libertas_cpio (sd8686)

n’t thought it may be a kernel build option. I’ve > > > > now > > > > built that and dmesg is a much more lively place! > > > > > > > > I’ve provided output logs for both when the device is connected > > > > and > > > > when a connec

Re: Problem connecting to wifi on libertas_cpio (sd8686)

is useful. > > > > > > The card is scanning and only finds 'shaunthesheep' 20 seconds > > after > > you "connect for the first time". The logs stop 3 seconds later. > > Are > > you connecting with wicd or something else? > > > >

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Tried a few more things worth mentioning: - Tried connecting with wpa_supplicant & dhclient only but sadly wpa_supplicant still cannot seem to hold a connection to the base station. It looks like the relevant errors here may be: ioctl[SIOCSIWENCODEEXT]: Invalid argument wlan0: Tr

Re: Problem connecting to wifi on libertas_cpio (sd8686)

I’ve provided output logs for both when the device is connected and > > when a connection attempt is made - hopefully this is useful. > > > > The card is scanning and only finds 'shaunthesheep' 20 seconds after > you "connect for the first time". The logs stop 3 second

Re: Problem connecting to wifi on libertas_cpio (sd8686)

gt; when a connection attempt is made - hopefully this is useful. The card is scanning and only finds 'shaunthesheep' 20 seconds after you "connect for the first time".  The logs stop 3 seconds later.  Are you connecting with wicd or something else? Can you run wpa_supplicant with the &quo

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Hi Dan, Ah - yeah I hadn’t thought it may be a kernel build option. I’ve now built that and dmesg is a much more lively place! I’ve provided output logs for both when the device is connected and when a connection attempt is made - hopefully this is useful. When I first connect the device:

Re: Problem connecting to wifi on libertas_cpio (sd8686)

oing something more than > > just asking for the password again like it did with NetworkManager > > but so far no further progress on getting this working properly. > > > > Christopher Williamson > > > > > > > > On 19 July 2016 at 18:03:16, Christop

Re: Problem connecting to wifi on libertas_cpio (sd8686)

gt; on getting this working properly. > > Christopher Williamson > > > > On 19 July 2016 at 18:03:16, Christopher Williamson > (h...@chrisaw.com(mailto:h...@chrisaw.com)) wrote: > > > Absolutely! > > > > With the debug logging enabled I got the

Re: Problem connecting to wifi on libertas_cpio (sd8686)

but so far no further progress on getting this working properly. Christopher Williamson On 19 July 2016 at 18:03:16, Christopher Williamson (h...@chrisaw.com(mailto:h...@chrisaw.com)) wrote: > Absolutely! > > With the debug logging enabled I got the following: > > Connecting the d

Re: Problem connecting to wifi on libertas_cpio (sd8686)

Absolutely! With the debug logging enabled I got the following: Connecting the device initially with debug enabled: [  205.302685] libertas_sdio: Libertas SDIO driver [  205.302698] libertas_sdio: Copyright Pierre Ossman [  205.503465] cfg80211: World regulatory domain updated: [  205.503478

Re: Problem connecting to wifi on libertas_cpio (sd8686)

On Tue, 2016-07-19 at 12:06 -0400, Christopher Williamson wrote: > Hi everyone! > > I’ve just got myself a Viliv N5 and am trying to get the integrated > Wifi chipset working on it. > > I am able to see networks around me but any attempts to connect them > appear to time out and fail. > > I

Problem connecting to wifi on libertas_cpio (sd8686)

Hi everyone! I’ve just got myself a Viliv N5 and am trying to get the integrated Wifi chipset working on it. I am able to see networks around me but any attempts to connect them appear to time out and fail. I have filed a linux kernel bug related to this issue:

RE: rt2800 and BeagleBone Black kernel panic when connecting to access point

Vishal Thanki wrote on 27 April 2016: > On Wed, Apr 27, 2016 at 02:21:36PM +1000, Craig McQueen wrote: > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 > chipset). I've been testing it on a BeagleBone Black running an Ubuntu 16.04 > image (4.4.6 kernel). > > > > 1) Install

Re: iw reg overwritten after connecting to AP

On Fri, Jun 3, 2016 at 2:02 AM, Belisko Marek wrote: > > Hi Krishna, > > On Thu, Jun 2, 2016 at 10:21 PM, Krishna Chaitanya > wrote: > > On Thu, Jun 2, 2016 at 7:34 PM, Belisko Marek > > wrote: > >> > >> Hello, > >> >

Re: iw reg overwritten after connecting to AP

Hi Krishna, On Thu, Jun 2, 2016 at 10:21 PM, Krishna Chaitanya wrote: > On Thu, Jun 2, 2016 at 7:34 PM, Belisko Marek wrote: >> >> Hello, >> >> I'm using kernel 4.1 with option CONFIG_CFG80211_INTERNAL_REGDB >> enabled. I have set one country

Re: iw reg overwritten after connecting to AP

On Thu, Jun 2, 2016 at 7:34 PM, Belisko Marek wrote: > > Hello, > > I'm using kernel 4.1 with option CONFIG_CFG80211_INTERNAL_REGDB > enabled. I have set one country in db.txt which during startup I set > via 'iw reg set XX'. When connected to some AP which sends country

iw reg overwritten after connecting to AP

Hello, I'm using kernel 4.1 with option CONFIG_CFG80211_INTERNAL_REGDB enabled. I have set one country in db.txt which during startup I set via 'iw reg set XX'. When connected to some AP which sends country code (e.g. SK) region is overwritten to 00 (in kernel log there is some timeout message -

Re: rt2800 and BeagleBone Black kernel panic when connecting to access point

On Thu, Apr 28, 2016 at 1:23 AM, Craig McQueen wrote: > Vishal Thanki wrote: >> On Wed, Apr 27, 2016 at 7:56 AM, Craig McQueen >> wrote: >> > Vishal Thanki wrote: >> >> Hi, >> >> >> >> On Wed, Apr 27, 2016 at 02:21:36PM +1000, Craig

RE: rt2800 and BeagleBone Black kernel panic when connecting to access point

Vishal Thanki wrote: > On Wed, Apr 27, 2016 at 7:56 AM, Craig McQueen > wrote: > > Vishal Thanki wrote: > >> Hi, > >> > >> On Wed, Apr 27, 2016 at 02:21:36PM +1000, Craig McQueen wrote: > >> > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based > >> >

Re: rt2800 and BeagleBone Black kernel panic when connecting to access point

On Wed, Apr 27, 2016 at 7:56 AM, Craig McQueen wrote: > Vishal Thanki wrote: >> Hi, >> >> On Wed, Apr 27, 2016 at 02:21:36PM +1000, Craig McQueen wrote: >> > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 >> chipset). I've been testing it on a

RE: rt2800 and BeagleBone Black kernel panic when connecting to access point

Vishal Thanki wrote: > Hi, > > On Wed, Apr 27, 2016 at 02:21:36PM +1000, Craig McQueen wrote: > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 > chipset). I've been testing it on a BeagleBone Black running an Ubuntu 16.04 > image (4.4.6 kernel). > > > > 1) Install Ubuntu

Re: rt2800 and BeagleBone Black kernel panic when connecting to access point

Hi, On Wed, Apr 27, 2016 at 02:21:36PM +1000, Craig McQueen wrote: > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 > chipset). I've been testing it on a BeagleBone Black running an Ubuntu 16.04 > image (4.4.6 kernel). > > 1) Install Ubuntu 16.04 on a BeagleBone Black. >

RE: rt2800 and BeagleBone Black kernel panic when connecting to access point

I previously wrote: > > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 > chipset). I've been testing it on a BeagleBone Black running an Ubuntu 16.04 > image (4.4.6 kernel). > > 1) Install Ubuntu 16.04 on a BeagleBone Black. > 2) Add lines to /etc/network/interfaces for the

rt2800 and BeagleBone Black kernel panic when connecting to access point

I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 chipset). I've been testing it on a BeagleBone Black running an Ubuntu 16.04 image (4.4.6 kernel). 1) Install Ubuntu 16.04 on a BeagleBone Black. 2) Add lines to /etc/network/interfaces for the device to connect to a WPA2

Re: PROBLEM: System hang when connecting USB modem (GCT/Yota LU150)

Alex writes: > Apr 01 11:33:24 arch kernel: BUG: unable to handle kernel NULL pointer > dereference at 0003 > Apr 01 11:33:24 arch kernel: IP: [] > usbnet_generic_cdc_bind+0x171/0x710 [cdc_ether] .. > Apr 01 11:33:24 arch kernel: Call Trace: > Apr 01 11:33:24

[PATCH v2 02/15] wil6210: AP: prevent connecting to already connected station

wmi_evt_connect doesn't check if the connect event is received for an already connected station. This can lead to memory leak as a new vring is allocated without freeing the previously allocated vring and to unexpected behavior of nl80211 layer due to unexpected notification of a new station. Add

[PATCH 02/15] wil6210: AP: prevent connecting to already connected station

wmi_evt_connect doesn't check if the connect event is received for an already connected station. This can lead to memory leak as a new vring is allocated without freeing the previously allocated vring and to unexpected behavior of nl80211 layer due to unexpected notification of a new station. Add

[PATCH RESEND 04/70] staging: wilc1000: handle connecting error

If connection fails, wilc1000_connecting needs to be set false also and return immediately because goto lable 'done' doesn't do anything. Remove lable 'done' as well. Signed-off-by: Glen Lee --- drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 13 ++--- 1 file

[PATCH V2 18/26] staging: wilc1000: handle connecting error

If connection fails, wilc1000_connecting needs to be set false also and return immediately because goto lable 'done' doesn't do anything. Remove lable 'done' as well. Signed-off-by: Glen Lee --- drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 13 ++--- 1 file

Connecting

Connecting GNUnet with Openwrt Is this the right place to forward this email? Kind regards Demos Weitergeleitete Nachricht Betreff: Re: [GNUnet-developers] EDN Datum: Tue, 14 Apr 2015 22:33:50 +0200 Von: Christian Grothoff groth...@gnunet.org An: demos de...@posteo.de, gnunet

Re: [PATCH v2 2/2] cfg80211: add support for connecting to PBSS network type

On Sun, 2015-02-08 at 15:52 +0200, Dedy Lansky wrote: @@ -961,6 +961,12 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev, memcpy(wdev-ssid, connect-ssid, connect-ssid_len); wdev-ssid_len = connect-ssid_len; + wdev-conn_bss_type = IEEE80211_BSS_TYPE_ESS; +

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 -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to

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

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

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

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

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

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 and

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

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

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 is

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

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

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

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

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

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

Re: 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 flaky

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

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;

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 4

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 indeed

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

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 (idx =

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

connecting, that leaves in low rates in the retry chain anyway. 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. - Felix -- To unsubscribe from

Re: 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: 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. In

Re: AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 05:41:25PM -0800, Linus Torvalds wrote: Nope, everything else I have seems to be intel wireless. I think one of the kids machines is a Mac Mini with an ath5k thing, but I'm hoping the wpa_supplicant.log is sufficient to give somebody an idea. It looks like there are two

Re: 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 out

Re: 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 j...@w1.fi 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

Re: AR9462 problems connecting again..

On Mon, Feb 23, 2015 at 9:17 AM, Jouni Malinen j...@w1.fi 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,

Re: AR9462 problems connecting again..

On Mon, Feb 23, 2015 at 12:06 PM, Linus Torvalds torva...@linux-foundation.org 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

Re: AR9462 problems connecting again..

On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen j...@w1.fi 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

Re: AR9462 problems connecting again..

On 23 February 2015 at 13:53, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Feb 23, 2015 at 1:30 PM, Jouni Malinen j...@w1.fi 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

Re: 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 torva...@linux-foundation.org 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

Re: AR9462 problems connecting again..

On Mon, Feb 23, 2015 at 2:43 PM, Jouni Malinen j...@w1.fi 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

Re: 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_ht

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

Re: 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 j...@w1.fi 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

Re: AR9462 problems connecting again..

On Sat, Feb 21, 2015 at 10:50 PM, Sujith Manoharan suj...@msujith.org 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.

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

recall having issues with fast_reauth once, but I never stuck around that location long enough to debug it. Nope. Did that, killed wpa_supplicant (which restarts it), tried connecting, still failed. Hint: Several unifi (and most ubnt) products are well supported by openwrt directly, which

Re: AR9462 problems connecting again..

having issues with fast_reauth once, but I never stuck around that location long enough to debug it. Nope. Did that, killed wpa_supplicant (which restarts it), tried connecting, still failed. Hm, can you enable wpa debugging to log everything whilst it's associating / reassociating? (maybe

Re: AR9462 problems connecting again..

enough to debug it. Nope. Did that, killed wpa_supplicant (which restarts it), tried connecting, still failed. Linus -- To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to majord...@vger.kernel.org More majordomo info

Re: AR9462 problems connecting again..

On 21 February 2015 at 15:34, Linus Torvalds torva...@linux-foundation.org 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

Re: AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 11:39 AM, Adrian Chadd adr...@freebsd.org 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

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

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

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

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

Re: AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 1:50 PM, Linus Torvalds torva...@linux-foundation.org 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

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

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

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

Re: AR9462 problems connecting again..

On Sun, Feb 22, 2015 at 5:55 PM, Adrian Chadd adr...@freebsd.org 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: AR9462 problems connecting again..

: External notification - portEnabled=1 14:07:19.503818: EAPOL: SUPP_PAE entering state CONNECTING 14:07:19.503828: EAPOL: enable timer tick 14:07:19.503838: EAPOL: SUPP_BE entering state IDLE 14:07:19.503852: wlp1s0: Setting authentication timeout: 10 sec 0 usec 14:07:19.503864: wlp1s0: Cancelling scan

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

Re: AR9462 problems connecting again..

On 22 February 2015 at 15:00, Linus Torvalds torva...@linux-foundation.org wrote: On Sun, Feb 22, 2015 at 1:50 PM, Linus Torvalds torva...@linux-foundation.org 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.

[PATCH v2 2/2] cfg80211: add support for connecting to PBSS network type

in wdev (conn_bss_type). This field is used later (e.g. in __cfg80211_connect_result) when calling cfg80211_get_bss() for finding the BSS we are connecting to. Signed-off-by: Dedy Lansky dlan...@codeaurora.org --- include/net/cfg80211.h | 2 ++ net/wireless/sme.c | 12 +--- 2 files

[PATCH 03/22] wil6210: print more information when connecting

when connecting, print some info about BSS Signed-off-by: Vladimir Kondratiev qca_vkond...@qca.qualcomm.com --- drivers/net/wireless/ath/wil6210/cfg80211.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c b/drivers/net/wireless

  1   2   >