Bug#659521: [3.1 -> 3.2.4 regression] ath9k: no packets are transmitted or received with WEP
Hello, Jonathan
i did all the steps you asked:
Booting the laptop with the 3.2.6 kernel built from the git cloned tree shows the exact same problem:
no network traffic over the wireless connection (ath9k module).
applying the patch, rebuilding the kernel and running the laptop with this new kernel solves the problem
and so far i haven't seen any problem with the network connection.
=============================================
command log
=============================================
schippes@miniguru:~$ uname -a
Linux miniguru 3.2.6+ #2 SMP Tue Feb 14 23:18:50 CET 2012 i686 GNU/Linux
schippes@miniguru:~$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=1.87 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=3.71 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=1.90 ms
64 bytes from 192.168.0.1: icmp_req=4 ttl=64 time=1.89 ms
^C
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.875/2.347/3.717/0.791 ms
schippes@miniguru:~$
=============================================
end command log
=============================================
may be we will see the patch applied in a future debian testing kernel update?
Thank you very much for your support !
stefan
On 02/14/2012 02:18 AM, Jonathan Nieder wrote:
> stefan schippers wrote:
>
>> # ping 192.168.0.1
>> PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
>> From 192.168.0.78 icmp_seq=1 Destination Host Unreachable
>> From 192.168.0.78 icmp_seq=2 Destination Host Unreachable
>> From 192.168.0.78 icmp_seq=3 Destination Host Unreachable
>> From 192.168.0.78 icmp_seq=4 Destination Host Unreachable
>> From 192.168.0.78 icmp_seq=5 Destination Host Unreachable
>> From 192.168.0.78 icmp_seq=6 Destination Host Unreachable
>> ^C
> Thanks. Can you try this patch?
>
> It works like this:
>
> 0. Prerequisites:
> apt-get install git build-essential
>
> 1. Get a copy of the linux-stable tree:
>
> git clone -o stable \
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git \
> linux
> cd linux
>
> Or, if you already have a clone of the kernel:
>
> cd linux
> git remote add -f stable \
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git \
>
> 2. Make sure you can still reproduce the bug:
>
> git checkout stable/linux-3.2.y
> cp /boot/config-$(uname -r) .config; # current configuration
> make localmodconfig; # optional: minimize configuration
> make deb-pkg; # optionally with -j<num> for parallel build
> dpkg -i ../<name of package>
> reboot
>
> 3. Apply the patch and see if it fixes it:
>
> git apply --index <thepatch>
> make deb-pkg; # maybe with -j4
> dpkg -i ../<name of package>
> reboot
>
> commit f88373fa47f3
> Author: Felix Fietkau <nbd@openwrt.org>
> Date: Sun Feb 5 21:15:17 2012 +0100
>
> ath9k: fix a WEP crypto related regression
>
> commit b4a82a0 "ath9k_hw: fix interpretation of the rx KeyMiss flag"
> fixed the interpretation of the KeyMiss flag for keycache based lookups,
> however WEP encryption uses a static index, so KeyMiss is always asserted
> for it, even though frames are decrypted properly.
> Fix this by clearing the ATH9K_RXERR_KEYMISS flag if no keycache based
> lookup was performed.
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> Cc: stable@vger.kernel.org
> Reported-by: Laurent Bonnans <bonnans.l@gmail.com>
> Reported-by: Jurica Vukadin <u.ra604@googlemail.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> index 0e666fbe0842..7e1a91af1497 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -822,6 +822,14 @@ static bool ath9k_rx_accept(struct ath_common *common,
> (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
> ATH9K_RXERR_KEYMISS));
>
> + /*
> + * Key miss events are only relevant for pairwise keys where the
> + * descriptor does contain a valid key index. This has been observed
> + * mostly with CCMP encryption.
> + */
> + if (rx_stats->rs_keyix == ATH9K_RXKEYIX_INVALID)
> + rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
> +
> if (!rx_stats->rs_datalen)
> return false;
> /*
Reply to: