[regression] WPA TKIP broken with HAL 0.9.18.0

Forgot to mention, I'm using NetworkManager 0.6.4 (from FC6) to get my wireless connection going. With the newer SVN version (> 1705) it tries to connect but after a while it asks for the WPA passphrase again. Entering the correct passphrase does not help.

See also bug #922. I've attached two logs from wpa_supplicant, working (r1710) and non-working (r1711).

wpa_supplicant debug output with working r1710

wpa_supplicant debug output with non-working r1711

ACK. I have also reproduced this. The new HAL mentions (chipset specific) keycaching enhancements. Perhaps that is responsible for this awful regression.

This is specific to TKIP cipher, AES only works fine with same setup. Comments in the freebsd keycache patch that accompanied the "release notes" for the HAL seem to be TKIP specific.

Contacted Sam Leffler about this regression, as it is most certainly related to changes in the opaque HAL.

Sam replied promptly, saying it works with NetBSD and FreeBSD and the information provided here and in the email was "useless". There was no comment about what information would be "useful".

I don't care to follow up problems in the opaque HAL any longer. Someone else may be able to provide "useful" info to him please. I am patheticly disappointed that a problem such as this would be dismissed so swiftly.

I recapitulated the available information and tried to be as verbose as possible about the possible causes of this issue. He said it works in NetBSD and FreeBSD, while we obviously have an issue. So the assumption that missing driver support for the "tkip mic keycache support" which has been introduced in HAL v0.9.18.0 could be the culprit has been pointed out again.

I saw the reply, and I agree with Kel: it was a short and quite harsh reply, lacking anything useful to determine what information actually if missing for him to be able to look at this issue. This type of response is annoying and counterproductive. Let's hope that I have better luck with my mail.

Sam tend to redesign hal interface from time to time I tried apply the patch from freebsd, and here it is. try it?(I don't have 5424 right now)

Signed-off-by: Bell Kin <bell_kin@pek.com.tw>

Update: Sam replied to my mail and clarified in greater detail which kind of information is helpful to investigate in that issue. wpa_supplicant log files are not helpful, instead debug messages and/or athstats might give something helpful:

If there is a problem then you should be able to enable crypto debug msgs in the driver and show where the keys are properly installed but cipher operations are not properly done (presumably you'll get crypto errors that athstats will report).

He also states that the TKIP MIC keycache support in the HAL should not be causing any problems if the driver does not enable it. Nevertheless it would be good to make use of that feature, so thanks to Bell for taking care of the patch!

I just quickly tried the newhalbsd.patch, which managed to get me authenticated on a WPA-PSK TKIP network, using r1754 :) Will be able to test it more thoroughly and post more information if necessary tomorrow.

Acked. The patch allowed association to a TKIP access point, which was not possible since introduction of the new 0.9.18.0 HAL in r1711.

Applied in r1755.

Thanks bell!

Will reopen and assign this ticket to myself as a reminder to collect ath/net80211 debug data concerning claimed TKIP cipher regression, so that Sam maybe be of further help.

r1710, TKIP, wpa_supplicant and athdebug +keycache

r1711, TKIP, wpa_supplicant and athdebug +keycache

r1756, TKIP, wpa_supplicant and athdebug +keycache

Quoting Sam leffler:

Ok, I understand what's going on now.  I was able to reproduce things.
The issue is really an API incompatibility I introduced when I added the
new keycache support in the hal.  Before I added the ability to store
TKIP mic keys "combined" the driver would ask the hal if it was capable
of storing TKIP mic keys "together" or "split" using:

if (ath_hal_tkipsplit(ah))
        sc->sc_splitmic = 1;

This always evaluated s.t. the driver thought the mic keys were split
across 2 keycache entries and so did the usual work.  However when I
added the ability to store the mic keys in a single keycache entry I
made the above call return "the truth".  This meant that on parts where
it was possible to store keys either split or combined it said
"together" so sc_splitmic was NOT set to 1.  This broke compatibility
with the old driver/existing code.

Since r1755 madwifi supports the combined tkip entries, so this issue is mostly null and void.

It was agreed there was little point in modifying the HAL at this point.