From patchwork Fri Sep 29 18:40:42 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve deRosier X-Patchwork-Id: 9978513 X-Patchwork-Delegate: kvalo@adurom.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 67FB260365 for ; Fri, 29 Sep 2017 18:40:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5AFE6298A1 for ; Fri, 29 Sep 2017 18:40:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 592AD298B2; Fri, 29 Sep 2017 18:40:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 81937298AE for ; Fri, 29 Sep 2017 18:40:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752633AbdI2Skp (ORCPT ); Fri, 29 Sep 2017 14:40:45 -0400 Received: from mail-vk0-f53.google.com ([209.85.213.53]:45988 "EHLO mail-vk0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752468AbdI2Sko (ORCPT ); Fri, 29 Sep 2017 14:40:44 -0400 Received: by mail-vk0-f53.google.com with SMTP id w23so290272vkw.2 for ; Fri, 29 Sep 2017 11:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=I4KJlUD+ihFncFNMj7WOKuQwZBWHtPt9umux2Gl82CY=; b=NRNa2f6ynmBI52VFDm8QifGuoGVLSzscN84sZI9KouLqUJWs8zXd0qdGyDlYgVbSwB 3NtoQMdhHZfO0ZYP9wTsXS3qrlhEuOynBHHkVjPEBiuhXfMIv1DnI6qUmEHGpGa2smjf OtUg8GZu/hCiJIOSIWDVxBz1hel/HUYj3fCLOMs+acD5Lo+PriDT3uk462P5d3sw2r3N 4bd5rl9s3W2+nIvaDIYKBgLt6hi11IlbVoIS4uzpo+27Dn9VXxhC0zjbzJParLVLaTja K0CXWzMWah7nLu536dgP9ldwm55Igc+ZKRCqy2JguFkwfHB0UVC8Ojjd1IgwEMxI2sEc K+DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=I4KJlUD+ihFncFNMj7WOKuQwZBWHtPt9umux2Gl82CY=; b=eJnFYhf9Htl6UXQ18qlPLxXSizRsr7kBQQs+v7FSGQUxwc3xXu3M3kKwIo2Lm0GeeR JnT+C7P9C1P258y4l6BU+cipL4GWn1vmqijpElfaUFPdcdsXbq7eOBVSq0yFF6wK3OmE p7MR8VHxz4yPXVBGQaLxeCoSK/9JK7vmVL0vLQC37MnoTbz0ImqeeXPUsHmZFzY6NoMf 7h/a9/1ArUmHycNF3NqXdyhGZ7S3mnmWje/nDB7u4Fb/76laMxO2V+oq4piWXKHbG6/f 8mJDH62iAzI5besNZnL42V13wmSG/oamRl6H+gIuQWoU+XoWT2tSR28VHzl+Y6zsjHwZ h4fA== X-Gm-Message-State: AHPjjUg9qF+/wx0Q0G5P2Alyq0NSuFNDQPPfR5n+F95WZaKgYQDE+tAf Dzl9+E9kznAFRXw1KM3kbbewq8MAvzF3W29NjLv/2A== X-Google-Smtp-Source: AOwi7QD9NUXOexFXi2Hwv9aYZFqC/5vtkLKA5kjv8QLVYvtb72SMJDV/iH2pc3ODhXPxalQ4HiRyhL+cBsUonQtW3jo= X-Received: by 10.31.75.196 with SMTP id y187mr5101682vka.120.1506710443112; Fri, 29 Sep 2017 11:40:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.182.16 with HTTP; Fri, 29 Sep 2017 11:40:42 -0700 (PDT) From: Steve deRosier Date: Fri, 29 Sep 2017 11:40:42 -0700 Message-ID: Subject: carl9170 issue with sniffer mode and dropping probe responses To: linux-wireless , Johannes Berg , Christian Lamparter Cc: Kalle Valo Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, A patch went in to the carl9170 driver about 5 years go that addressed an issue with spurious ack noise from the hardware when it was put in sniffer mode. It changed the driver to drop the sniffer mode and instead keep it in STA mode with relaxed RX filtering. Patch [1] Discussion [2] All was thought to be well, but as it turns out it causes a specific problem with injection as reported on the Kali Linux bug list [3]. Turns out it's not an issue with injection as the device transmits the injected packets to the air just fine, but it's an issue with the hardware filtering out the probe responses that are sent back to the fake randomized MAC address that aireplay-ng is using as the sender on the injected packets. aireplay-ng needs to get these probe response packets back but they're getting filtered out by the hardware and never even make it back up to the driver. I've played with every RX filter flag and various attempts to manipulate the MAC filters and I can't get anything to work. Only by putting the AR9170_MAC_SNIFFER_ENABLE_PROMISC flag back in so we have real monitor mode again, I was able to solve the issue. By putting the flag back, the relevant probe responses are able to get back up to the driver and aireplay-ng works again with carl9170. I spent a long time avoiding adding sniffer mode back in due to the explanation comments in the code. I played with the rx_fliter_cmd and turned off the filters. I played with REG_MAC_ADDR, REG_BSSID and REG_FRAMETYPE_FILTER. I attempted to manipulate the MAC filters by playing with REG_GROUP_HASH_TBL. Basically, I thoroughly went through carl9170.h and played with every register and command that looked relevant. If there's any other filter or MAC address filtering I missed, please advise. As mentioned, I put the sniffer back in play. But I chose to keep AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER off. I throughly tested the degradation mentioned that resulted in the earlier patch. With the sniffer flag ON but dropping RX_CTRL_ACK_IN_SNIFFER, I didn't see the channel throughput hit. The second I toggled the RX_CTRL flag back on, the throughput on the channel dropped and I started seeing the effects the previous patch mentioned. So, I think we can add AR9170_MAC_SNIFFER_ENABLE_PROMISC back in with AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER kept off and end up with carl9170 working in true sniffer mode but without getting the earlier problem. Note that this is with the most current firmware, the 1.9.9, which is newer than the original fix. Perhaps changes in firmware behavior are resulting in the differences? For specific point of discussion, I'll put my patch at the end of this email. Please advise to approach or anything that looks wrong and I'll make adjustments and respin. Or if it looks OK, I'll submit the patch. Thanks, - Steve [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=e0509d3bdd7365d06c9bf570bf9f118cae6cbd58 [2] https://marc.info/?l=linux-wireless&m=134517238506033 [3] https://bugs.kali.org/view.php?id=4220 From c46a994dd78befbe94e66771db41c18351be2aae Mon Sep 17 00:00:00 2001 From: Steve deRosier Date: Fri, 29 Sep 2017 10:48:19 -0700 Subject: [PATCH] wireless: carl9170: Enable sniffer mode promisc flag to fix injection The removal of the AR9170_MAC_SNIFFER_ENABLE_PROMISC flag to fix an issue many years ago caused the AR9170 to not be able to pass probe response packets with different MAC addresses back up to the driver. In general operation, this doesn't matter, but in the case of packet injection with aireplay-ng it is important. aireplay-ng specifically injects packets with spoofed MAC addresses on the probe requests and looks for probe responses back to those addresses. No other combination of filter flags seem to fix this issue and so AR9170_MAC_SNIFFER_ENABLE is required to get these packets. This was originally caused by commit e0509d3bdd7365d06c9bf570bf9f11 which removed this flag in order to avoid spurious ack noise from the hardware. In testing for this issue, keeping this flag but not restoring the AR9170_MAC_RX_CTRL_ACK_IN_SNIFFER flag on the rc_ctrl seems to solve this issue, at least with the most current firmware v1.9.9. Signed-off-by: Steve deRosier --- drivers/net/wireless/ath/carl9170/mac.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/wireless/ath/carl9170/mac.c b/drivers/net/wireless/ath/carl9170/mac.c index 7d4a72dc98db..c617e883f47a 100644 --- a/drivers/net/wireless/ath/carl9170/mac.c +++ b/drivers/net/wireless/ath/carl9170/mac.c @@ -309,6 +309,7 @@ int carl9170_set_operating_mode(struct ar9170 *ar) u32 rx_ctrl = AR9170_MAC_RX_CTRL_DEAGG | AR9170_MAC_RX_CTRL_SHORT_FILTER; u32 sniffer = AR9170_MAC_SNIFFER_DEFAULTS; + u32 mac_ftf = AR9170_MAC_FTF_DEFAULTS; int err = 0; rcu_read_lock(); @@ -373,6 +374,9 @@ int carl9170_set_operating_mode(struct ar9170 *ar) if (ar->sniffer_enabled) { enc_mode |= AR9170_MAC_ENCRYPTION_RX_SOFTWARE; + mac_ftf = AR9170_MAC_FTF_MONITOR; + sniffer |= AR9170_MAC_SNIFFER_ENABLE_PROMISC; + mac_addr = NULL; } err = carl9170_set_mac_reg(ar, AR9170_MAC_REG_MAC_ADDR_L, mac_addr); @@ -384,6 +388,7 @@ int carl9170_set_operating_mode(struct ar9170 *ar) return err; carl9170_regwrite_begin(ar); + carl9170_regwrite(AR9170_MAC_REG_FRAMETYPE_FILTER, mac_ftf); carl9170_regwrite(AR9170_MAC_REG_SNIFFER, sniffer); carl9170_regwrite(AR9170_MAC_REG_CAM_MODE, cam_mode); carl9170_regwrite(AR9170_MAC_REG_ENCRYPTION, enc_mode);