From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98BBBC43603 for ; Sat, 14 Dec 2019 16:01:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6929B2073D for ; Sat, 14 Dec 2019 16:01:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ODeXure6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726072AbfLNQBt (ORCPT ); Sat, 14 Dec 2019 11:01:49 -0500 Received: from mail-ot1-f68.google.com ([209.85.210.68]:45194 "EHLO mail-ot1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725900AbfLNQBt (ORCPT ); Sat, 14 Dec 2019 11:01:49 -0500 Received: by mail-ot1-f68.google.com with SMTP id 59so3055608otp.12 for ; Sat, 14 Dec 2019 08:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k5n26h5aUGynjAqQqkXs+oOQEbeY7Busq7aVKwZv934=; b=ODeXure6jQF/dq3PW1o9+jB3aEO0KJwMWTteksoKCh0yRp8GbygEpVabOYcB+IUfhG 14lox5LNc8rvyY+84+Ca/HuKoMmghzfqai+GI5ouKEp5dWTKeLSW5EctgTdiGss1JBNh Ak7CaWvDcuoNrVcMIt1XT1wvrhVguQUSErevTkoWudsxSC/m5kTHa3P3hLDfAImr/9Yk D8V18JwqAxXFCm3qr4eLwiSaFhbJL7hy5oYhtbOT4TnkAehE5TqP8iJKJWQYet4U7g4K U9417WAZstehJf5N7r6TUzb5xZDUn0HpfHHbXPxxvQWTCTsvbPZcufkSEkzARLP+YkEY Iy3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k5n26h5aUGynjAqQqkXs+oOQEbeY7Busq7aVKwZv934=; b=ejyyVBE71JQ20PnkGASHZz5dbrpLF4p6Q1c556Sls+pR/2dsSuuzwal6E7j91nj9h7 fCv+WGxi4sXtQSjhEsjKmq6QdgPAug4SX56c+LWBnVYrIKLg8ryzNWo2t6uVsJ/Ao7tq nMu5OUx6/7Ajca+rzRkhEos3FuVEFFevBG6lOyB7MflLUno3p+Ncp3sXKW/cr1APHM3S RFhHnjP3UUUAKnynfnHVYEqne5B/ITQT7cHz07v2nMl2t7YjFvyRbeLkXejHPEvIhDWL OPpKG+HX2xyp7XPR14AzGBh6Q1yVco/aoSJtBTTwOXUpNuHaII8L+LybU8sq60An0I+6 35jA== X-Gm-Message-State: APjAAAW4mEp91oqlkqyUfDVsTTpuZKBUHtTvfGO8rbmPZUQ3IARGEz5Z qIL7fkEPKrLecmqL8K86WihBEvXvubNlKPZPf0A= X-Google-Smtp-Source: APXvYqz+H/j/TFBlFdrIIgynXYxj+oOM32TkJIpVcK9KgF3QxZVmQoV31wWAW+azEY9okJhHTF2/7JXaOXxRQchrkH4= X-Received: by 2002:a9d:6b03:: with SMTP id g3mr1132014otp.200.1576339308565; Sat, 14 Dec 2019 08:01:48 -0800 (PST) MIME-Version: 1.0 References: <0101016eaadee57a-54500c6d-4751-423f-8bab-5acd8fad2175-000000@us-west-2.amazonses.com> <0101016eb61d9520-b0306a23-c9b9-4b57-b708-9f80ac47eef1-000000@us-west-2.amazonses.com> In-Reply-To: From: Justin Capella Date: Sat, 14 Dec 2019 08:01:33 -0800 Message-ID: Subject: Re: [PATCH] ath10k: set WMI_PEER_AUTHORIZE after a firmware crash To: Ben Greear , Wen Gong Cc: ath10k , linux-wireless@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org If you have time to spare I'd be interested in hearing a little more about your stances on this... I'm trying to learn more about this stuff and not at all qualified to say one way or the other if it is a good idea, but my intuition is this is going to lead to inconsistent state/behaviors. I have been wondering if maybe this change may be related to some of the fw crash reports coming in--- perhaps marking the station as authorized before the fw is fully started and/or the device is present On Mon, Dec 2, 2019 at 10:17 AM Ben Greear wrote: > > On 12/1/19 8:45 PM, Justin Capella wrote: > > Are there security concerns here? Was the peer known to be authorized > > beforehand? Would it be better to just trash the peer in the event of > > a fw crash? > > I think you should completely re-associate the peer(s) when firmware > crashes. The driver does not cache all possible changes, so it cannot > exactly rebuild the config to the previous state. > > Thanks, > Ben > > > > > On Thu, Nov 28, 2019 at 11:46 PM Kalle Valo wrote: > >> > >> Wen Gong wrote: > >> > >>> After the firmware crashes ath10k recovers via ieee80211_reconfig(), > >>> which eventually leads to firmware configuration and including the > >>> encryption keys. However, because there is no new auth/assoc and > >>> 4-way-handshake, and firmware set the authorize flag after > >>> 4-way-handshake, so the authorize flag in firmware is not set in > >>> firmware without 4-way-handshake. This will lead to a failure of data > >>> transmission after recovery done when using encrypted connections like > >>> WPA-PSK. Set authorize flag after installing keys to firmware will fix > >>> the issue. > >>> > >>> This was noticed by testing firmware crashing using simulate_fw_crash > >>> debugfs file. > >>> > >>> Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1. > >>> > >>> Signed-off-by: Wen Gong > >>> Signed-off-by: Kalle Valo > >> > >> Patch applied to ath-next branch of ath.git, thanks. > >> > >> 382e51c139ef ath10k: set WMI_PEER_AUTHORIZE after a firmware crash > >> > >> -- > >> https://patchwork.kernel.org/patch/11263357/ > >> > >> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches > >> > > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-ot1-x343.google.com ([2607:f8b0:4864:20::343]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1ig9rZ-0004yD-UG for ath10k@lists.infradead.org; Sat, 14 Dec 2019 16:01:51 +0000 Received: by mail-ot1-x343.google.com with SMTP id g18so3060316otj.13 for ; Sat, 14 Dec 2019 08:01:49 -0800 (PST) MIME-Version: 1.0 References: <0101016eaadee57a-54500c6d-4751-423f-8bab-5acd8fad2175-000000@us-west-2.amazonses.com> <0101016eb61d9520-b0306a23-c9b9-4b57-b708-9f80ac47eef1-000000@us-west-2.amazonses.com> In-Reply-To: From: Justin Capella Date: Sat, 14 Dec 2019 08:01:33 -0800 Message-ID: Subject: Re: [PATCH] ath10k: set WMI_PEER_AUTHORIZE after a firmware crash List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Ben Greear , Wen Gong Cc: linux-wireless@vger.kernel.org, ath10k If you have time to spare I'd be interested in hearing a little more about your stances on this... I'm trying to learn more about this stuff and not at all qualified to say one way or the other if it is a good idea, but my intuition is this is going to lead to inconsistent state/behaviors. I have been wondering if maybe this change may be related to some of the fw crash reports coming in--- perhaps marking the station as authorized before the fw is fully started and/or the device is present On Mon, Dec 2, 2019 at 10:17 AM Ben Greear wrote: > > On 12/1/19 8:45 PM, Justin Capella wrote: > > Are there security concerns here? Was the peer known to be authorized > > beforehand? Would it be better to just trash the peer in the event of > > a fw crash? > > I think you should completely re-associate the peer(s) when firmware > crashes. The driver does not cache all possible changes, so it cannot > exactly rebuild the config to the previous state. > > Thanks, > Ben > > > > > On Thu, Nov 28, 2019 at 11:46 PM Kalle Valo wrote: > >> > >> Wen Gong wrote: > >> > >>> After the firmware crashes ath10k recovers via ieee80211_reconfig(), > >>> which eventually leads to firmware configuration and including the > >>> encryption keys. However, because there is no new auth/assoc and > >>> 4-way-handshake, and firmware set the authorize flag after > >>> 4-way-handshake, so the authorize flag in firmware is not set in > >>> firmware without 4-way-handshake. This will lead to a failure of data > >>> transmission after recovery done when using encrypted connections like > >>> WPA-PSK. Set authorize flag after installing keys to firmware will fix > >>> the issue. > >>> > >>> This was noticed by testing firmware crashing using simulate_fw_crash > >>> debugfs file. > >>> > >>> Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1. > >>> > >>> Signed-off-by: Wen Gong > >>> Signed-off-by: Kalle Valo > >> > >> Patch applied to ath-next branch of ath.git, thanks. > >> > >> 382e51c139ef ath10k: set WMI_PEER_AUTHORIZE after a firmware crash > >> > >> -- > >> https://patchwork.kernel.org/patch/11263357/ > >> > >> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches > >> > > > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k