nohwcrypt=1 module parameter can now be used to disable hardware
crypto in ath9k. While the hardware acceleration handles most cases,
it may be useful to be able to force mac80211 software implementation
to be used for some tests, e.g., with virtual interface combinations
that may not yet be supported in the key cache configuration. In
addition, this allows management frame protection to be tested with
older hardware revisions.
Signed-off-by: Jouni Malinen <[email protected]>
---
drivers/net/wireless/ath9k/main.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- wireless-testing.orig/drivers/net/wireless/ath9k/main.c 2009-02-24 13:34:44.000000000 +0200
+++ wireless-testing/drivers/net/wireless/ath9k/main.c 2009-02-24 13:35:01.000000000 +0200
@@ -26,6 +26,10 @@ MODULE_DESCRIPTION("Support for Atheros
MODULE_SUPPORTED_DEVICE("Atheros 802.11n WLAN cards");
MODULE_LICENSE("Dual BSD/GPL");
+static int modparam_nohwcrypt;
+module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
+MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption");
+
/* We use the hw_value as an index into our private channel structure */
#define CHAN2G(_freq, _idx) { \
@@ -1587,7 +1591,7 @@ int ath_attach(u16 devid, struct ath_sof
IEEE80211_HW_SUPPORTS_PS |
IEEE80211_HW_PS_NULLFUNC_STACK;
- if (AR_SREV_9160_10_OR_LATER(sc->sc_ah))
+ if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || modparam_nohwcrypt)
hw->flags |= IEEE80211_HW_MFP_CAPABLE;
hw->wiphy->interface_modes =
@@ -2468,6 +2472,9 @@ static int ath9k_set_key(struct ieee8021
struct ath_softc *sc = hw->priv;
int ret = 0;
+ if (modparam_nohwcrypt)
+ return -ENOSPC;
+
mutex_lock(&sc->mutex);
ath9k_ps_wakeup(sc);
DPRINTF(sc, ATH_DBG_KEYCACHE, "Set HW Key\n");
--
Jouni Malinen PGP id EFC895FA
On Tue, Feb 24, 2009 at 05:49:07AM -0800, Johannes Berg wrote:
> On Tue, 2009-02-24 at 13:42 +0200, Jouni Malinen wrote:
> > In
> > addition, this allows management frame protection to be tested with
> > older hardware revisions.
>
> This is odd, shouldn't older revisions refuse the hw key setup and use
> software anyway? Or are they unable to distinguish between management
> and data frames and thus it all goes wrong?
The exact behavior depends on the hardware revision, but some older
versions would likely end up using the Data frame rules for decrypting
the management frames and as such, would require software workaround
that re-encrypt the frame using Data frame rules and then make the frame
go the normal software decryption. While this is possible to implement,
I have not bothered to do so yet and don't know how much interest there
would be for such a feature at this point. This would also require some
new APIs from mac80211 to allow re-use of CCMP code.
--
Jouni Malinen PGP id EFC895FA
On Tue, Feb 24, 2009 at 09:24:32AM -0500, pat-lkml wrote:
> With this patch, and nohwcrypt=1, I get the following in hostapd (this
> system runs as an access point) when I try to associate with a client.
>
> I can't say whether this is a hostapd problem or an ath9k problem yet,
> but it's a different behavior than with nohwcrypt=0 or without this
> patch. With this patch, wpa2 works perfectly, as without it, as well
> as wep working perfectly.
Are you saying that you get different behavior from hostapd when
comparing nohwcrypt=0 and nohwcrypt=1 (i.e., no changes in the driver
code, just the module parameter change)?
> I wouldn't call this report a 'ACK/NACK' report as it has caused no
> new problems, nor fixed any old problems. Unfortunately I don't have
> a log around of the old behavior right now, for comparison. I just
> wanted to report what I've found based on this patch.
> wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
> wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
> wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
> wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
> wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
> wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key frame (2/4 Pairwise)
> wlan0: STA 00:1f:a7:70:2d:8d WPA: invalid MIC in msg 2/4 of 4-Way Handshake
> wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
> wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
> wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
Which client are you using? Are you sure that the passphrase/PSK is set
correctly? The nohwcrypt patch should make absolutely no difference for
this part (this is key handshake which in the initial phase is sent
without encrypted EAPOL-Key frames, so neither sw nor hw crypto used).
--
Jouni Malinen PGP id EFC895FA
pat-lkml wrote:
> Jouni Malinen wrote:
>> On Tue, Feb 24, 2009 at 09:24:32AM -0500, pat-lkml wrote:
>>
>>> With this patch, and nohwcrypt=1, I get the following in hostapd (this
>>> system runs as an access point) when I try to associate with a client.
>>>
>>> I can't say whether this is a hostapd problem or an ath9k problem yet,
>>> but it's a different behavior than with nohwcrypt=0 or without this
>>> patch. With this patch, wpa2 works perfectly, as without it, as well
>>> as wep working perfectly.
>> Are you saying that you get different behavior from hostapd when
>> comparing nohwcrypt=0 and nohwcrypt=1 (i.e., no changes in the driver
>> code, just the module parameter change)?
>
> Yes.
>
>>> I wouldn't call this report a 'ACK/NACK' report as it has caused no
>>> new problems, nor fixed any old problems. Unfortunately I don't have
>>> a log around of the old behavior right now, for comparison. I just
>>> wanted to report what I've found based on this patch.
>>> wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
>>> wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
>>> wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
>>> wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
>>> wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
>>> wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key frame (2/4 Pairwise)
>>> wlan0: STA 00:1f:a7:70:2d:8d WPA: invalid MIC in msg 2/4 of 4-Way Handshake
>>> wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
>>> wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
>>> wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
>> Which client are you using? Are you sure that the passphrase/PSK is set
>> correctly? The nohwcrypt patch should make absolutely no difference for
>> this part (this is key handshake which in the initial phase is sent
>> without encrypted EAPOL-Key frames, so neither sw nor hw crypto used).
>
> I've tried 3 different clients with identical behavior:
>
> 1. Playstation 3
> 2. Dell Axim / WM6
> 3. ath5k Laptop
>
> I get that (afore mentioned invalid MIC in msg 2/4) with nohwcrypt=1, while
> nohwcrypt=0 I get 'STA Detected Michael MIC error' during stage 3 I believe.
>
> I'll have more time after about 6:00PM EST to test this and provide the full
> logs of each client associating, along with wpa_supplicant logs. I'm running
> git hostapd, and I've NEVER had wpa1 work correctly with it, which is why I said
> that that report wasn't an 'ACK/NACK' just reporting that I see a difference in
> behavior with it.
>
> Pat
Ok, I feel VERY sheepish now. In doing further testing, I discovered a typo in my
hostapd.conf for the wpa config, specifically, an extra char that snuck into my wpa
pass phrase. Use nohwcrypt=1, hostapd now works perfectly with wep/wpa/wpa2, while
with nohwcrypt=0, I get errors (that I'll need physical access to my computer to
debug/log) in wpa only. I'm testing with my usual, rate limited scp transfer over
wireless right now, as previous 'issues' have arisen when a re-key occurs during a
transfer.
Pat Erley
On Tue, 2009-02-24 at 16:06 +0200, Jouni Malinen wrote:
> On Tue, Feb 24, 2009 at 05:49:07AM -0800, Johannes Berg wrote:
> > On Tue, 2009-02-24 at 13:42 +0200, Jouni Malinen wrote:
> > > In
> > > addition, this allows management frame protection to be tested with
> > > older hardware revisions.
> >
> > This is odd, shouldn't older revisions refuse the hw key setup and use
> > software anyway? Or are they unable to distinguish between management
> > and data frames and thus it all goes wrong?
>
> The exact behavior depends on the hardware revision, but some older
> versions would likely end up using the Data frame rules for decrypting
> the management frames and as such, would require software workaround
> that re-encrypt the frame using Data frame rules and then make the frame
> go the normal software decryption. While this is possible to implement,
> I have not bothered to do so yet and don't know how much interest there
> would be for such a feature at this point. This would also require some
> new APIs from mac80211 to allow re-use of CCMP code.
Ok, that makes sense, I probably wouldn't bother implementing that
either. I know Broadcom doesn't touch management frames, they explicitly
check for that before running crypto stuff on a frame. :)
johannes
pat-lkml wrote:
> Jouni Malinen wrote:
>> On Tue, Feb 24, 2009 at 03:07:20PM -0500, pat-lkml wrote:
>>> pass phrase. Use nohwcrypt=1, hostapd now works perfectly with wep/wpa/wpa2, while
>>> with nohwcrypt=0, I get errors (that I'll need physical access to my computer to
>>> debug/log) in wpa only.
>> Thanks, I was able to reproduce this and figure out what was happening.
>> It looks like I have not tested TKIP in AP mode before (I've been mainly
>> testing HT and that does not allow TKIP..). Anyway, the Michael MIC
>> TX/RX keys are set incorrectly for the group key which will trigger
>> Michael MIC errors on every broadcast frame.
>>
>> I have more complete cleanup of the key configuration for ath9k in
>> progress, but as far as this particular issue is concerned, the
>> following change should resolve it. So far, I've only tested this with
>> the current hardware revision, but I will test this with older design,
>> too, and submit a proper patch later. Anyway, you may want to test this
>> as a fix for TKIP in AP mode.
>>
>>
> I had to make some changes to get it to build, am going to test shortly.
>
> The relevant changes were adding:
>
> struct ieee80211_vif *vif;
> vif = sc->vifs[0];
>
> to the 'else' condition, like the if(key->keyidx) condition.
That should have read 'below' the else condition.
And it appears to be working. I have it set to 10 minute rekeying, so I'll
have more success/failure for you then (and am waiting to send this e-mail
until then).
Well, it rekey'd with no interruption in service. I'd call it a success.
Thanks!
Pat Erley
On Tue, Feb 24, 2009 at 05:15:49PM +0100, Michael Buesch wrote:
> On Tuesday 24 February 2009 12:42:01 Jouni Malinen wrote:
> > #define CHAN2G(_freq, _idx) { \
> > @@ -1587,7 +1591,7 @@ int ath_attach(u16 devid, struct ath_sof
> > IEEE80211_HW_SUPPORTS_PS |
> > IEEE80211_HW_PS_NULLFUNC_STACK;
> >
> > - if (AR_SREV_9160_10_OR_LATER(sc->sc_ah))
> > + if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || modparam_nohwcrypt)
> > hw->flags |= IEEE80211_HW_MFP_CAPABLE;
>
> Are you sure this is correct?
I have no reason to believe otherwise.
> The hardware capability doesn't magically change by switching a modparam.
Of course not.
> Either the HW is MFP capable or it isn't.
It is not that simple. Hardware is MFP capable with software
encryption/decryption in all cases; it just may not work correctly if
hardware acceleration is used with older hardware revisions.
> If hwcrypto is disabled (set_key returns error), mac80211 should be smart
> enough to do crypto (including MFP) in software anyway.
Yes and that is exactly what the patch is doing.. If nohwcrypt=1,
mac80211 takes care of crypto and MFP can be used. If nohwcrypt=0, MFP
is disabled for older hardware revisions (but enabled for new ones that
handle MFP without issues in hw crypto).
--
Jouni Malinen PGP id EFC895FA
Jouni Malinen wrote:
> nohwcrypt=1 module parameter can now be used to disable hardware
> crypto in ath9k. While the hardware acceleration handles most cases,
> it may be useful to be able to force mac80211 software implementation
> to be used for some tests, e.g., with virtual interface combinations
> that may not yet be supported in the key cache configuration. In
> addition, this allows management frame protection to be tested with
> older hardware revisions.
>
With this patch, and nohwcrypt=1, I get the following in hostapd (this
system runs as an access point) when I try to associate with a client.
I can't say whether this is a hostapd problem or an ath9k problem yet,
but it's a different behavior than with nohwcrypt=0 or without this
patch. With this patch, wpa2 works perfectly, as without it, as well
as wep working perfectly.
I wouldn't call this report a 'ACK/NACK' report as it has caused no
new problems, nor fixed any old problems. Unfortunately I don't have
a log around of the old behavior right now, for comparison. I just
wanted to report what I've found based on this patch.
Pat Erley
---
Configuration file: ./hostapd-wpa.conf
Using interface wlan0 with hwaddr 00:11:50:f6:c1:f0 and ssid 'FooBarCafeWPA'
wlan0: STA 00:1f:a7:70:2d:8d IEEE 802.11: authentication OK (open system)
wlan0: STA 00:1f:a7:70:2d:8d MLME: MLME-AUTHENTICATE.indication(00:1f:a7:70:2d:8d, OPEN_SYSTEM)
wlan0: STA 00:1f:a7:70:2d:8d MLME: MLME-DELETEKEYS.request(00:1f:a7:70:2d:8d)
wlan0: STA 00:1f:a7:70:2d:8d IEEE 802.11: authenticated
wlan0: STA 00:1f:a7:70:2d:8d IEEE 802.11: association OK (aid 1)
wlan0: STA 00:1f:a7:70:2d:8d IEEE 802.11: associated (aid 1)
wlan0: STA 00:1f:a7:70:2d:8d MLME: MLME-ASSOCIATE.indication(00:1f:a7:70:2d:8d)
wlan0: STA 00:1f:a7:70:2d:8d MLME: MLME-DELETEKEYS.request(00:1f:a7:70:2d:8d)
wlan0: STA 00:1f:a7:70:2d:8d WPA: event 1 notification
wlan0: STA 00:1f:a7:70:2d:8d WPA: start authentication
wlan0: STA 00:1f:a7:70:2d:8d IEEE 802.1X: unauthorizing port
Could not set station 00:1f:a7:70:2d:8d flags for kernel driver (errno=17).
wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key frame (2/4 Pairwise)
wlan0: STA 00:1f:a7:70:2d:8d WPA: invalid MIC in msg 2/4 of 4-Way Handshake
wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key frame (2/4 Pairwise)
wlan0: STA 00:1f:a7:70:2d:8d WPA: invalid MIC in msg 2/4 of 4-Way Handshake
wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
wlan0: STA 00:1f:a7:70:2d:8d IEEE 802.1X: unauthorizing port
Could not set station 00:1f:a7:70:2d:8d flags for kernel driver (errno=17).
wlan0: STA 00:1f:a7:70:2d:8d IEEE 802.11: deauthenticated due to local deauth request
wlan0: STA 00:1f:a7:70:2d:8d IEEE 802.11: authentication OK (open system)
wlan0: STA 00:1f:a7:70:2d:8d MLME: MLME-AUTHENTICATE.indication(00:1f:a7:70:2d:8d, OPEN_SYSTEM)
wlan0: STA 00:1f:a7:70:2d:8d MLME: MLME-DELETEKEYS.request(00:1f:a7:70:2d:8d)
<at which point the log repeats over and over>
On Wed, Feb 25, 2009 at 07:10:21PM -0500, pat-lkml wrote:
> pat-lkml wrote:
> > I had to make some changes to get it to build, am going to test shortly.
Ah.. I had made the patch on top of number of other changes and did not
remember to rebase it on top of wireless-testing.
> And it appears to be working. I have it set to 10 minute rekeying, so I'll
> have more success/failure for you then (and am waiting to send this e-mail
> until then).
>
> Well, it rekey'd with no interruption in service. I'd call it a success.
Thanks, nice to hear. I was also able to complete testing on this with
both the newer and older hardware revisions and both for AP and STA
modes.
--
Jouni Malinen PGP id EFC895FA
Jouni Malinen wrote:
> On Tue, Feb 24, 2009 at 03:07:20PM -0500, pat-lkml wrote:
>> pass phrase. Use nohwcrypt=1, hostapd now works perfectly with wep/wpa/wpa2, while
>> with nohwcrypt=0, I get errors (that I'll need physical access to my computer to
>> debug/log) in wpa only.
>
> Thanks, I was able to reproduce this and figure out what was happening.
> It looks like I have not tested TKIP in AP mode before (I've been mainly
> testing HT and that does not allow TKIP..). Anyway, the Michael MIC
> TX/RX keys are set incorrectly for the group key which will trigger
> Michael MIC errors on every broadcast frame.
>
> I have more complete cleanup of the key configuration for ath9k in
> progress, but as far as this particular issue is concerned, the
> following change should resolve it. So far, I've only tested this with
> the current hardware revision, but I will test this with older design,
> too, and submit a proper patch later. Anyway, you may want to test this
> as a fix for TKIP in AP mode.
>
>
I had to make some changes to get it to build, am going to test shortly.
The relevant changes were adding:
struct ieee80211_vif *vif;
vif = sc->vifs[0];
to the 'else' condition, like the if(key->keyidx) condition.
Pat
On Tuesday 24 February 2009 12:42:01 Jouni Malinen wrote:
> #define CHAN2G(_freq, _idx) { \
> @@ -1587,7 +1591,7 @@ int ath_attach(u16 devid, struct ath_sof
> IEEE80211_HW_SUPPORTS_PS |
> IEEE80211_HW_PS_NULLFUNC_STACK;
>
> - if (AR_SREV_9160_10_OR_LATER(sc->sc_ah))
> + if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || modparam_nohwcrypt)
> hw->flags |= IEEE80211_HW_MFP_CAPABLE;
Are you sure this is correct?
The hardware capability doesn't magically change by switching a modparam.
Either the HW is MFP capable or it isn't.
If hwcrypto is disabled (set_key returns error), mac80211 should be smart
enough to do crypto (including MFP) in software anyway.
--
Greetings, Michael.
On Tue, Feb 24, 2009 at 03:07:20PM -0500, pat-lkml wrote:
> pass phrase. Use nohwcrypt=1, hostapd now works perfectly with wep/wpa/wpa2, while
> with nohwcrypt=0, I get errors (that I'll need physical access to my computer to
> debug/log) in wpa only.
Thanks, I was able to reproduce this and figure out what was happening.
It looks like I have not tested TKIP in AP mode before (I've been mainly
testing HT and that does not allow TKIP..). Anyway, the Michael MIC
TX/RX keys are set incorrectly for the group key which will trigger
Michael MIC errors on every broadcast frame.
I have more complete cleanup of the key configuration for ath9k in
progress, but as far as this particular issue is concerned, the
following change should resolve it. So far, I've only tested this with
the current hardware revision, but I will test this with older design,
too, and submit a proper patch later. Anyway, you may want to test this
as a fix for TKIP in AP mode.
--- wireless-testing.orig/drivers/net/wireless/ath9k/main.c 2009-02-25 20:09:14.000000000 +0200
+++ wireless-testing/drivers/net/wireless/ath9k/main.c 2009-02-25 20:11:19.000000000 +0200
@@ -648,8 +648,8 @@ static int ath_keyset(struct ath_softc *
}
static int ath_setkey_tkip(struct ath_softc *sc, u16 keyix, const u8 *key,
- struct ath9k_keyval *hk,
- const u8 *addr)
+ struct ath9k_keyval *hk, const u8 *addr,
+ bool authenticator)
{
const u8 *key_rxmic;
const u8 *key_txmic;
@@ -659,7 +659,13 @@ static int ath_setkey_tkip(struct ath_so
if (addr == NULL) {
/* Group key installation */
- memcpy(hk->kv_mic, key_rxmic, sizeof(hk->kv_mic));
+ if (authenticator) {
+ memcpy(hk->kv_mic, key_txmic, sizeof(hk->kv_mic));
+ memcpy(hk->kv_txmic, key_txmic, sizeof(hk->kv_mic));
+ } else {
+ memcpy(hk->kv_mic, key_rxmic, sizeof(hk->kv_mic));
+ memcpy(hk->kv_txmic, key_rxmic, sizeof(hk->kv_mic));
+ }
return ath_keyset(sc, keyix, hk, addr);
}
if (!sc->splitmic) {
@@ -826,7 +832,8 @@ static int ath_key_config(struct ath_sof
}
if (key->alg == ALG_TKIP)
- ret = ath_setkey_tkip(sc, idx, key->key, &hk, mac);
+ ret = ath_setkey_tkip(sc, idx, key->key, &hk, mac,
+ vif->type == NL80211_IFTYPE_AP);
else
ret = ath_keyset(sc, idx, &hk, mac);
--
Jouni Malinen PGP id EFC895FA
pat-lkml wrote:
> pat-lkml wrote:
>> pat-lkml wrote:
>>> Jouni Malinen wrote:
>>> Which client are you using? Are you sure that the passphrase/PSK is set
>>> correctly? The nohwcrypt patch should make absolutely no difference for
>>> this part (this is key handshake which in the initial phase is sent
>>> without encrypted EAPOL-Key frames, so neither sw nor hw crypto used).
>> I've tried 3 different clients with identical behavior:
>>
>> 1. Playstation 3
>> 2. Dell Axim / WM6
>> 3. ath5k Laptop
>>
>> I get that (afore mentioned invalid MIC in msg 2/4) with nohwcrypt=1, while
>> nohwcrypt=0 I get 'STA Detected Michael MIC error' during stage 3 I believe.
>>
>> I'll have more time after about 6:00PM EST to test this and provide the full
>> logs of each client associating, along with wpa_supplicant logs. I'm running
>> git hostapd, and I've NEVER had wpa1 work correctly with it, which is why I said
>> that that report wasn't an 'ACK/NACK' just reporting that I see a difference in
>> behavior with it.
>>
>> Pat
>
> Ok, I feel VERY sheepish now. In doing further testing, I discovered a typo in my
> hostapd.conf for the wpa config, specifically, an extra char that snuck into my wpa
> pass phrase. Use nohwcrypt=1, hostapd now works perfectly with wep/wpa/wpa2, while
> with nohwcrypt=0, I get errors (that I'll need physical access to my computer to
> debug/log) in wpa only. I'm testing with my usual, rate limited scp transfer over
> wireless right now, as previous 'issues' have arisen when a re-key occurs during a
> transfer.
Here are 2 sets of logs: [linked as they're ~60K total]
http://wireless.erley.org/ath9k-nohwcrypto0.txt
http://wireless.erley.org/ath9k-nohwcrypto1.txt
As can be deduced from the file names, the first one is with nohwcrypto=0
while the second is with nohwcrypto=1.
I set this module param with the modprobe.conf line: options ath9k nohwcrypt=1
I made NO changes in hostapd between these two log runs, only removing and
reloading the ath9k driver. nohwcrypto=0 resulted in the Michael MIC error and
a non functioning client (PS3, in this example) while nohwcrypto=1 resulted in
a working PS3 client. I was able to stream 3 hours of video (in total) today
while working on other things, with hostapd set to 30s re-keying. Any other tests
I could do/log/provide for getting hwcrypto to work in AP mode would be great.
I've done no testing in station mode, as I don't have any interests in using ath9k
in station mode at the moment.
Pat Erley
On Tue, 2009-02-24 at 13:42 +0200, Jouni Malinen wrote:
> In
> addition, this allows management frame protection to be tested with
> older hardware revisions.
This is odd, shouldn't older revisions refuse the hw key setup and use
software anyway? Or are they unable to distinguish between management
and data frames and thus it all goes wrong?
johannes
Jouni Malinen wrote:
> On Tue, Feb 24, 2009 at 09:24:32AM -0500, pat-lkml wrote:
>
>> With this patch, and nohwcrypt=1, I get the following in hostapd (this
>> system runs as an access point) when I try to associate with a client.
>>
>> I can't say whether this is a hostapd problem or an ath9k problem yet,
>> but it's a different behavior than with nohwcrypt=0 or without this
>> patch. With this patch, wpa2 works perfectly, as without it, as well
>> as wep working perfectly.
>
> Are you saying that you get different behavior from hostapd when
> comparing nohwcrypt=0 and nohwcrypt=1 (i.e., no changes in the driver
> code, just the module parameter change)?
Yes.
>> I wouldn't call this report a 'ACK/NACK' report as it has caused no
>> new problems, nor fixed any old problems. Unfortunately I don't have
>> a log around of the old behavior right now, for comparison. I just
>> wanted to report what I've found based on this patch.
>
>> wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
>> wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
>> wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
>> wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
>> wlan0: STA 00:1f:a7:70:2d:8d WPA: sending 1/4 msg of 4-Way Handshake
>> wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key frame (2/4 Pairwise)
>> wlan0: STA 00:1f:a7:70:2d:8d WPA: invalid MIC in msg 2/4 of 4-Way Handshake
>> wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
>> wlan0: STA 00:1f:a7:70:2d:8d WPA: received EAPOL-Key 2/4 Pairwise with unexpected replay counter
>> wlan0: STA 00:1f:a7:70:2d:8d WPA: EAPOL-Key timeout
>
> Which client are you using? Are you sure that the passphrase/PSK is set
> correctly? The nohwcrypt patch should make absolutely no difference for
> this part (this is key handshake which in the initial phase is sent
> without encrypted EAPOL-Key frames, so neither sw nor hw crypto used).
I've tried 3 different clients with identical behavior:
1. Playstation 3
2. Dell Axim / WM6
3. ath5k Laptop
I get that (afore mentioned invalid MIC in msg 2/4) with nohwcrypt=1, while
nohwcrypt=0 I get 'STA Detected Michael MIC error' during stage 3 I believe.
I'll have more time after about 6:00PM EST to test this and provide the full
logs of each client associating, along with wpa_supplicant logs. I'm running
git hostapd, and I've NEVER had wpa1 work correctly with it, which is why I said
that that report wasn't an 'ACK/NACK' just reporting that I see a difference in
behavior with it.
Pat