All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"hostap@lists.shmoo.com" <hostap@lists.shmoo.com>
Subject: Re: Strange problem with ath9k and ASUS N66U AP.
Date: Tue, 24 Apr 2012 23:23:55 -0700	[thread overview]
Message-ID: <4F97987B.7050600@candelatech.com> (raw)
In-Reply-To: <20120425060853.GA3324@w1.fi>

On 04/24/2012 11:08 PM, Jouni Malinen wrote:
> On Tue, Apr 24, 2012 at 05:26:07PM -0700, Ben Greear wrote:
>> On 04/24/2012 03:50 PM, Ben Greear wrote:
>>> I am trying some ath9k virtual clients against an ASUS N66U.
>
>>> Here is part of the N66U wifi log showing that it
>>> thinks sta11 is not authorized:
>>>
>>> 00:95:95:00:00:0C  associated
>>> 00:95:95:00:00:0D  associated authorized
>
>> Here's a better log.  Makes me think supplicant might be at fault???
>
> Looks more like an AP bug to me..
>
>> sta8 failed, sta9 works fine.  The difference appears to be the extra
>> RX EAPOL packet that sta8 receives...
>
>> 1335313181.999422: sta8: WPA: RX message 3 of 4-Way Handshake from c8:60:00:e8:88:b0 (ver=2)
>> 1335313181.999465: sta8: WPA: Sending EAPOL-Key 4/4
>
>> 1335313182.063695: sta8: WPA: RX message 3 of 4-Way Handshake from c8:60:00:e8:88:b0 (ver=2)
>> 1335313182.063745: sta8: WPA: Sending EAPOL-Key 4/4
>
> Either the AP did not receive the first EAPOL-Key 4/4 or processed it
> only after retransmitting 3/4. Supplicant side will need to to reply to
> retransmitted 3/4 to complete the 4-way handshake. If the AP received
> either of these 4/4 messages, it should be fine with the result. If it
> didn't receive either, it should disconnect the station. It does not
> look like either of those happened.

Ok, it seems strange they would have such a lame
bug, but maybe they never tried associating several stations at once.
(I see around 30% failure rate when using just 15 stations).

We have several off-the-shelf APs and home-grown ones (using ath9k) that work fine,
even when associating 100+ stations, so at the least the N66U is weird...

That said, I'll probably need to attempt a work-around for this.  The only
obvious thing I see is the extra RX EAPOL (in all error cases I looked at, and none
where it associated properly), and the fact that DHCP just fails to acquire a lease.

I'll try adding a hack to detect the duplicate RX EAPOL and bounce the connection
if that hits, and see if that helps any...

Thanks,
Ben



-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

  reply	other threads:[~2012-04-25  6:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-24 22:50 Strange problem with ath9k and ASUS N66U AP Ben Greear
2012-04-25  0:26 ` Ben Greear
2012-04-25  6:08   ` Jouni Malinen
2012-04-25  6:23     ` Ben Greear [this message]
2012-04-25  8:18       ` Nicolas Cavallari
2012-04-25 17:21         ` Ben Greear

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F97987B.7050600@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=hostap@lists.shmoo.com \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.