ath5k and ap mode

ath5k and ap mode

[tomek]

Hi.

When ap-mode will working in driver ath5k?

Re: ath5k and ap mode

[Bob Copeland]

On Tue, Jul 7, 2009 at 5:39 AM, tomek<paladyn11@gmail.com> wrote:
> Hi.
>
> When ap-mode will working in driver ath5k?

It will be enabled in 2.6.31... whether it works then or not is
anyone's guess :)

(fyi, I'm currently waiting on some hw to arrive to do thorough
testing of ath5k AP mode; some people say it works for them, but I'm
still seeing some bugs here.)

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k and ap mode

[Pavel Roskin]

On Tue, 2009-07-07 at 10:19 -0400, Bob Copeland wrote:
> On Tue, Jul 7, 2009 at 5:39 AM, tomek<paladyn11@gmail.com> wrote:
> > Hi.
> >
> > When ap-mode will working in driver ath5k?
> 
> It will be enabled in 2.6.31... whether it works then or not is
> anyone's guess :)

I've just tested the mainline Linux git
(git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git)
and indeed, the AP support is there, so it will be in 2.6.31.

> (fyi, I'm currently waiting on some hw to arrive to do thorough
> testing of ath5k AP mode; some people say it works for them, but I'm
> still seeing some bugs here.)

My testing shows that ath5k is very unreliable in the AP mode, unlike
MadWifi.  Sometimes hostapd reports this:

wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: associated (aid 1)
wlan3: STA 00:17:c4:3b:fc:88 WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
wlan3: STA 00:17:c4:3b:fc:88 WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
wlan3: STA 00:17:c4:3b:fc:88 RADIUS: starting accounting session 4A538811-00000003
wlan3: STA 00:17:c4:3b:fc:88 WPA: pairwise key handshake completed (WPA)
wlan3: STA 00:17:c4:3b:fc:88 WPA: received EAPOL-Key 4/4 Pairwise with unexpected replay counter
wlan3: STA 00:17:c4:3b:fc:88 WPA: group key handshake completed (WPA)

At other times, it prints stuff like this:

wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: authenticated
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: associated (aid 1)
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: associated (aid 1)
wlan3: STA 00:17:c4:3b:fc:88 IEEE 802.11: deauthenticated due to local deauth request

wpa_supplicant on the client side reports strange messages too, for
instance:

Authentication with 00:00:00:00:00:00 timed out.

or

WPA: Countermeasures - dropped EAPOL request.

I'm using WPA-PSK (WPA1 only) to simplify the configuration.  My
impression is that we need a serious effort to weed out such problems.

Also, I'm running the current wireless-testing.git on the client side,
and it take some time for wpa_supplicant to start, as it reports:

ioctl[SIOCSIWSCAN]: Device or resource busy
Failed to initiate AP scan.

It looks like the station spends too much time in the busy state.  It
used to work better in the 2.6.30-rcX-wl days.

That's not meant to be a bugreport, more like a summary of all issues
I've seen.

-- 
Regards,
Pavel Roskin

Re: ath5k and ap mode

[Bob Copeland]

On Tue, Jul 7, 2009 at 3:25 PM, Pavel Roskin<proski@gnu.org> wrote:
>
> WPA: Countermeasures - dropped EAPOL request.
>
> I'm using WPA-PSK (WPA1 only) to simplify the configuration.  My
> impression is that we need a serious effort to weed out such problems.

Hmm, does the same happen with nohwcrypt=1?

ISTR ath9k had a patch sometime last year having to do with the key
cache and AP mode, probably applies here too.

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k and ap mode

[Pavel Roskin]

On Tue, 2009-07-07 at 15:43 -0400, Bob Copeland wrote:
> On Tue, Jul 7, 2009 at 3:25 PM, Pavel Roskin<proski@gnu.org> wrote:
> >
> > WPA: Countermeasures - dropped EAPOL request.
> >
> > I'm using WPA-PSK (WPA1 only) to simplify the configuration.  My
> > impression is that we need a serious effort to weed out such problems.
> 
> Hmm, does the same happen with nohwcrypt=1?

"Pairwise with unexpected replay counter" is still there.  But the
timeouts (deauthenticated due to local deauth request" in hostapd and
"Authentication with 00:00:00:00:00:00 timed out" in wpa_supplicant) are
gone, so the association happens quicker, after a few complaints about
the counters.

I tried CCMP and WPA2, and "Pairwise with unexpected replay counter"
still happens.

I'm using the current hostapd from git, but it's working with MadWifi
without such issues.

-- 
Regards,
Pavel Roskin