Return-path: Received: from mail8.sea5.speakeasy.net ([69.17.117.10]:40785 "EHLO mail8.sea5.speakeasy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754086AbXK0Den (ORCPT ); Mon, 26 Nov 2007 22:34:43 -0500 Date: Mon, 26 Nov 2007 19:34:08 -0800 From: Jouni Malinen To: dragoran Cc: Johannes Berg , linux-wireless , Dan Williams , ipw3945-devel , Zhu Yi Subject: Re: mac80211 / iwl3945 + dynamic wep (again) Message-ID: <20071127033408.GB5698@jm.kir.nu> (sfid-20071127_033447_334083_934C2CC5) References: <47494851.4070504@gmail.com> <1195987773.4149.214.camel@johannes.berg> <474955E1.30603@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-wireless-owner@vger.kernel.org List-ID: On Mon, Nov 26, 2007 at 03:50:00PM +0100, dragoran wrote: > btw would it make sense to ratelimit > > "WEP decrypt failed (ICV)" messages? > they are a bit annoying when connected to this network... > > dmesg | grep ICV | wc -l > 3489 > > after some minutes. While I fully agree that these messages should be rate limited, it is somewhat surprising to see this large a number of reported ICV failures. Does the ipw3945 not filter out FCS errors before passing the frame for WEP decryption? Or is there something odd about this network/client configuration that makes the client try to decrypt frames that are not really for it? I can think of one valid case (VLAN with separate broadcast domains using the same BSS), all other cases seem like waste of CPU power since I would have expected the frames to be filtered out before reaching WEP decryption if this STA is not the correct destination for them. -- Jouni Malinen PGP id EFC895FA