On Fri, Mar 22, 2013 at 11:08 AM, Luis R. Rodriguez
rodri...@qca.qualcomm.com wrote:
On Fri, Mar 22, 2013 at 10:13:42AM +0100, Stanislaw Gruszka wrote:
On Thu, Mar 21, 2013 at 12:33:31PM -0700, Luis R. Rodriguez wrote:
OK how about this for stable for now:
diff --git
Hello,
My WiFi connection drops while running the AR9280 on a Freescale
MPC8315E platform in AP mode with hostapd. I get the following error
within 15 seconds and the WiFi connection drops. However, I do not
observe any issues when using the AR9382. Can you let me know what could
be causing
On 2013-03-24 5:26 PM, Pannirselvam Kanagaratnam wrote:
Hello,
My WiFi connection drops while running the AR9280 on a Freescale
MPC8315E platform in AP mode with hostapd. I get the following error
within 15 seconds and the WiFi connection drops. However, I do not
observe any issues when
The messages are currently hard coding 1ms, which does not match
the actual timeout being used.
---
drivers/net/wireless/ath/ath9k/ar9002_calib.c |9 ++---
drivers/net/wireless/ath/ath9k/ar9003_calib.c |3 ++-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git
I've done some more testing on this and it looks like the auth packets
aren't delayed, they're never sent. The TX Complete messages are
from the queue being purged before a reset due to channel change.
It only gets in this state when it's unable to change the channel due
to the timeout on
On 24 March 2013 11:55, Robert Shade robert.sh...@gmail.com wrote:
I've done some more testing on this and it looks like the auth packets
aren't delayed, they're never sent. The TX Complete messages are
from the queue being purged before a reset due to channel change.
Ew, ok.
It only gets
Hm, so it's doing some fast channel changes?
Yes, the fastcc does seem to work, it's just that sometimes the chip
can get in a bad state when it's not cold reset.
Just disable fast channel change entirely and re-test? And why not
just force a cold reset always? Why bother checking for the
(Added Marco and me in the CC - please keep it)
On Sunday, March 24, 2013 11:40:27 PM Robert Shade wrote:
Hm, so it's doing some fast channel changes?
Yes, the fastcc does seem to work, it's just that sometimes the chip
can get in a bad state when it's not cold reset.
Just disable fast
Let me just be really clear.
Fast channel change is notoriously unreliable and really only fully
debugged on some very later chips.
The correct thing to do is something like this:
* if you meet the fast cc requirements (same channel width, same
frequency band, etc) then change channel;
* if you
Also, would you please make sure you file a bugzilla.kernel.org ticket
so this gets tracked?
It's good to know that some combination of fast channel change and
warm versus cold reset is making things better/worse.
And although a cold reset is likely a good thing to _fix_ the problem,
it still
Ok, I'm sure this is something people have seen before, but it has me stumped.
I'm on the road for a couple of days with my google ChromeBook pixel,
which worked perfectly fine in the previous location I was at, and
works fine at home. But in the current condo, the machine simply
*cannot* connect
bad firmware load on a crappy wireless AP probably, I just flashed the
latest firmware on a new Netgear, and had exactly the same issue
flashed back to the original firmware and the issue goes away, question is
whats the router and version? Ive seen it before also occasionally
using OpenWRT on
Can you try disabling network manager from the init scripts (I am not
sure which distro you are using as a base but
/etc/init.d/network-manager stop ) tends to work for a percentage of
machines.
Then running wpa_supplicant manually.
i.e:
create a hashed passphrase config snippit with :
On 24 March 2013 21:06, Linus Torvalds torva...@linux-foundation.org wrote:
Ok, I'm sure this is something people have seen before, but it has me stumped.
wlan0: authenticate with 50:46:5d:02:85:08
wlan0: send auth to 50:46:5d:02:85:08 (try 1/3)
wlan0: authenticated
wlan0: associate
14 matches
Mail list logo
