[PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Larry Finger]

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 <Larry.Finger@lwfinger.net>
---

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;
 	}
 

Re: [PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Ivo van Doorn]

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

Re: [PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Larry Finger]

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

Re: [PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Michael Wu]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Larry Finger]

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

Re: [PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Ivo van Doorn]

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

Re: [PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Larry Finger]

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

Re: [PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH V3] mac80211: Turn off meaningless TKIP message when software WEP encryption is used

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]