For drivers that do no hardware encryption/decryption, WEP encryption
works as long as IEEE80211_HW_INCLUDE_IV is not set in the flags variable.
With WPA encryption and IEEE80211_HW_INCLUDE_IV not set, the logs are full
of TKIP decrypt failure messages. Despite the messages, RX is working.
This patch turns off the message for this case.
Signed-off-by: Larry Finger <[email protected]>
---
John,
Your suggestion to net_ratelimit the output is a good one. I hope the 3rd
time is a charm. I cannot believe that I'm still getting & and && confused.
At least I'm now getting = and == right (most of the time). FORTRAN IV didn't
have these complications!!
Larry
wpa.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: wireless-legacy/net/mac80211/wpa.c
===================================================================
--- wireless-legacy.orig/net/mac80211/wpa.c
+++ wireless-legacy/net/mac80211/wpa.c
@@ -516,9 +516,12 @@ ieee80211_rx_h_tkip_decrypt(struct ieee8
skb->len - hdrlen, rx->sta->addr,
hwaccel, rx->u.rx.queue);
if (res != TKIP_DECRYPT_OK || wpa_test) {
- printk(KERN_DEBUG "%s: TKIP decrypt failed for RX frame from "
- MAC_FMT " (res=%d)\n",
- rx->dev->name, MAC_ARG(rx->sta->addr), res);
+ if ((rx->local->hw.flags & IEEE80211_HW_WEP_INCLUDE_IV)
+ && net_ratelimit()) {
+ printk(KERN_DEBUG "%s: TKIP decrypt failed for RX frame from "
+ MAC_FMT " (res=%d)\n",
+ rx->dev->name, MAC_ARG(rx->sta->addr), res);
+ }
return TXRX_DROP;
}
On Mon, 2007-08-13 at 17:13 -0500, Larry Finger wrote:
> For drivers that do no hardware encryption/decryption, WEP encryption
> works as long as IEEE80211_HW_INCLUDE_IV is not set in the flags variable..
> With WPA encryption and IEEE80211_HW_INCLUDE_IV not set, the logs are full
> of TKIP decrypt failure messages. Despite the messages, RX is working.
> This patch turns off the message for this case.
This is a bit strange. What's your actual key configuration? Are you
using TKIP at all? I suspect you're using TKIP for multicast and
CCMP/AES for unicast and something else is actually wrong with TKIP
leading to this.
Thing is, it looks as though all frames that trigger the message are
dropped, and I'm fairly certain we don't actually want that.
Or something in your network is actually sending bogus frames. Could you
capture some packets with wireshark on a secondary monitor interface or
a second device and send me a packet dump?
johannes
On Monday 13 August 2007 16:13, Larry Finger wrote:
> Yes, this empirical behavior does not seem to match one's intuition on what
> the flag should do.
>
The flag means the hardware does the rc4 but doesn't bother to deal with the
IV/ICV. If you're going do software encryption, there's no reason to bother
with that flag, as that says your hardware supports and does rc4 in hardware.
-Michael Wu
Michael Wu wrote:
> On Monday 13 August 2007 16:13, Larry Finger wrote:
>> Yes, this empirical behavior does not seem to match one's intuition on what
>> the flag should do.
>>
> The flag means the hardware does the rc4 but doesn't bother to deal with the
> IV/ICV. If you're going do software encryption, there's no reason to bother
> with that flag, as that says your hardware supports and does rc4 in hardware.
That is fair enough, but why does that flag ever make any difference when the user has not provided
a set_key callback. My interpretation of the code was that this was one means of indicating that we
were never going to do any hardware encryption
It would be very helpful to driver writers if the comments in include/net/mac80211.h we improved.
This flag has none, but I don't think it is that obvious.
Larry
On Tuesday 14 August 2007, Michael Wu wrote:
> On Monday 13 August 2007 16:13, Larry Finger wrote:
> > Yes, this empirical behavior does not seem to match one's intuition on what
> > the flag should do.
> >
> The flag means the hardware does the rc4 but doesn't bother to deal with the
> IV/ICV. If you're going do software encryption, there's no reason to bother
> with that flag, as that says your hardware supports and does rc4 in hardware.
Has this behavior changed recently?
e.g. Has a patch been sent recently which will correctly enforce the rule mentioned
above, but has not yet appeared in wireless-dev?
I have removed the IEEE80211_HW_WEP_INCLUDE_IV flag from rt2x00 because hardware
encryption is not implemented and the result seems to be that WPA connections will
fail. I have already confirmation from 2 users who reported that with the flag set
WPA software encryption will work, while without the WPA the encryption will fail.
I have CC'ed Mattias, so if you need debugtraces he will be able to provide them.
Another thing that is odd in this case is that the name suggests that only WEP is affected
but apparently can break WPA. :S
Ivo
On Wed, 2007-08-15 at 08:16 -0500, Larry Finger wrote:
> AFAIK, I'm using WPA-PSK TKIP. My AP is a Linksys WRT54G V5. On the "Wireless Security" page, I have
> selected "WPA Personal" for the security mode and TKIP for the WPA algorithm. On my laptop, the
> connection is managed by NetworkManager. My key is stored in Kwallet and is supplied automatically,
> but NM asked for a WPA passphrase when I set it up.
Ok.
> That is certainly possible, either in my network or that of my neighbors. A network list shows 5
> APs, two of which are mine. Only the AP in question is using WPA, 3 are using WEP, and one is
> unencrypted.
I don't think the other networks should matter, at least if we got the
BSSID filtering right.
> I'm collecting a packet dump now using Kismet - I don't run X on my second laptop as it
> has too little memory and is slow besides. I'll send you that file off-list. I have filtered out
> beacons. I hope that is OK.
Sounds great, I'll take a look at it then.
johannes
Johannes Berg wrote:
> On Mon, 2007-08-13 at 17:13 -0500, Larry Finger wrote:
>> For drivers that do no hardware encryption/decryption, WEP encryption
>> works as long as IEEE80211_HW_INCLUDE_IV is not set in the flags variable.
>> With WPA encryption and IEEE80211_HW_INCLUDE_IV not set, the logs are full
>> of TKIP decrypt failure messages. Despite the messages, RX is working.
>> This patch turns off the message for this case.
>
> This is a bit strange. What's your actual key configuration? Are you
> using TKIP at all? I suspect you're using TKIP for multicast and
> CCMP/AES for unicast and something else is actually wrong with TKIP
> leading to this.
AFAIK, I'm using WPA-PSK TKIP. My AP is a Linksys WRT54G V5. On the "Wireless Security" page, I have
selected "WPA Personal" for the security mode and TKIP for the WPA algorithm. On my laptop, the
connection is managed by NetworkManager. My key is stored in Kwallet and is supplied automatically,
but NM asked for a WPA passphrase when I set it up.
>
> Thing is, it looks as though all frames that trigger the message are
> dropped, and I'm fairly certain we don't actually want that.
> Or something in your network is actually sending bogus frames. Could you
> capture some packets with wireshark on a secondary monitor interface or
> a second device and send me a packet dump?
That is certainly possible, either in my network or that of my neighbors. A network list shows 5
APs, two of which are mine. Only the AP in question is using WPA, 3 are using WEP, and one is
unencrypted. I'm collecting a packet dump now using Kismet - I don't run X on my second laptop as it
has too little memory and is slow besides. I'll send you that file off-list. I have filtered out
beacons. I hope that is OK.
Thanks,
Larry
Ivo van Doorn wrote:
>
> Not a question regarding the patch itself, but more about the comment
> regarding IEEE80211_HW_WEP_INCLUDE_IV and WEP encryption. ;)
>
> You mean the drivers that require mac80211 to do the encryption/decryption
> must make sure the IEEE80211_HW_WEP_INCLUDE_IV is _not_ set?
> I figured that when device requires software encryption they should set the flag
> since they do not touch the frame and pass it through completely to the stack
> this would also mean that the IV is passed on. Which should suggest that the
> flag should be set to tell mac80211 it can use the IV.
I'm not too up on this myself, but when I ported the frond end of bcm43xx-mac80211 to b43legacy, I
left the flags supplied to mac80211 untouched. Once I got the basic engine running using V3, rather
than V4, firmware, it did WPA encryption just fine. Of course, WPA is done in software in both
instances. WEP encrypt/decrypt is done in hardware in bcm43xx-mac80211, but it does not work in V3.
The only way I could get software-based WEP to work was to get rid of the "set_key" callback, which
sets an internal flag called force_sw_encrypt, and kill that flag. Then both WEP and WPA worked in
software, but the message showed up for WPA.
Yes, this empirical behavior does not seem to match one's intuition on what the flag should do.
Of course my patch is a complete hack that is band-aiding over a deeper flaw/bug in mac80211;
however, my request for a fix has gone unanswered. In addition, this problem is preventing me from
sending b43legacy to John. I originally intended to use my hack only while debugging, but when no
fix was coming, I decided that an awful patch would probably get some action. We'll see,
particularly now that my deep/dark secret is exposed. ;-)
Larry
On Tuesday 14 August 2007, Larry Finger wrote:
> For drivers that do no hardware encryption/decryption, WEP encryption
> works as long as IEEE80211_HW_INCLUDE_IV is not set in the flags variable.
> With WPA encryption and IEEE80211_HW_INCLUDE_IV not set, the logs are full
> of TKIP decrypt failure messages. Despite the messages, RX is working.
> This patch turns off the message for this case.
Not a question regarding the patch itself, but more about the comment
regarding IEEE80211_HW_WEP_INCLUDE_IV and WEP encryption. ;)
You mean the drivers that require mac80211 to do the encryption/decryption
must make sure the IEEE80211_HW_WEP_INCLUDE_IV is _not_ set?
I figured that when device requires software encryption they should set the flag
since they do not touch the frame and pass it through completely to the stack
this would also mean that the IV is passed on. Which should suggest that the
flag should be set to tell mac80211 it can use the IV.
I might be too ignorant about the specifics of the encryption steps, so I am a bit
confused about this. :S
Thanks,
Ivo
On Mon, 2007-08-20 at 19:55 +0200, Ivo van Doorn wrote:
> Has this behavior changed recently?
> e.g. Has a patch been sent recently which will correctly enforce the rule mentioned
> above, but has not yet appeared in wireless-dev?
No, it's still in my patchset. The semantics of that flag are rather
unclear so I've cleaned it up completely. However, key selection is
broken anyway at the moment so multicast/broadcast isn't coming through
on software crypto.
johannes
On Wed, 2007-08-15 at 08:16 -0500, Larry Finger wrote:
> > Thing is, it looks as though all frames that trigger the message are
> > dropped, and I'm fairly certain we don't actually want that.
Looks like I was right. This is really strange, and it plays into the RX
key selection that Volker also complained about.
I've tested this with my network, which is using CCMP for pairwise and
TKIP for group keys, and I started getting the same message as you had
but with "CCMP failed" instead of "TKIP failed". Adding all the
addresses to the debug output got me:
CCMP decrypt failed for RX frame from 00:15:f2:3d:63:97 to 33:33:00:00:00:02
Note how it's sending to that IPv6 multicast address but trying to
decrypt with CCMP although I have TKIP GTK keys. And as expected, I see
*no* multicast traffic on wlan0.
The problem obviously is key selection:
if (rx->sta && rx->sta->key)
use rx->sta->key
well, duh, that's obviously wrong since we have a pairwise (sta) key for
the AP, but it's sending us a multicast frame.
I've been thinking about revamping key selection, I guess this is
something to really look into now... Anyhow, this confirms that the
patch is wrong, it suppresses messages that we failed to decrypt frames
that we should be seeing, in this case multicast and broadcast frames.
johannes