From patchwork Mon Aug 8 16:58:29 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin O'Connor X-Patchwork-Id: 9268797 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 028D0607D6 for ; Mon, 8 Aug 2016 16:58:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E5C382815E for ; Mon, 8 Aug 2016 16:58:36 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DA701283F7; Mon, 8 Aug 2016 16:58:36 +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.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID 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 97A862815E for ; Mon, 8 Aug 2016 16:58:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752196AbcHHQ6c (ORCPT ); Mon, 8 Aug 2016 12:58:32 -0400 Received: from mail-qk0-f182.google.com ([209.85.220.182]:36250 "EHLO mail-qk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752159AbcHHQ6c (ORCPT ); Mon, 8 Aug 2016 12:58:32 -0400 Received: by mail-qk0-f182.google.com with SMTP id v123so195445185qkh.3 for ; Mon, 08 Aug 2016 09:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=koconnor-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=ozX6vJWNTflBMqV82VG7VWGSrOhPsq1FKWnwuJyxtqY=; b=ELm6KmsOy73IFVgmVT6xRA2kv+Wy9GrCiLFPU1YD6T2+ZqexSo8eacQKL/FIPRY77Y RhMPzMrz0IWJr6ukCCd5pV+AFvq+opOGBoRdGeBgmeXpsE+LVIkOLsNnxiQ4oXgUvkZT 7XJVH5OdWAsVL3w0K2mng0rl2fKWg98FzsOgPir0znwc0J7Njl5unE+/a8APnmFA4tQs 4it5vTvG3p3qbUvd/L9R1L3x4EiZukacMceQdQlSVV8934xcUX2T/14xbshpI9o98yik El8RIpj6U/zm+kTMyPfA6KjY/AHDRmxcLyaOmeVCs2oL/ue0pif+8Fb2EtQIrNMsfdse toLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=ozX6vJWNTflBMqV82VG7VWGSrOhPsq1FKWnwuJyxtqY=; b=S/rdVbW+GWRipR7kdlnwhJUl+0N2/tsw0YPKgAx5MFmUD0sykY5xv4XtqLoBKrVtYY r2er832ROLt32R5rhBI7InOpia4RuFdBMpFqtA8KObYX49rxlpuitjzYsBBnO0Z/zAVq E/ZX24P51rWoGvw7tagU2RfAKLhIq+8eUQisWiNBpa8MbQaV8keFPKheFHNUvn2NWmja b3n2Fk23zWHt/xv9hrqBxpRrGkP5WTgtqycv9Poq6p/PmrHaIihO1TEqwmgj+vz8/+nv ylPiotBjXZ90q+AKTG39RHxvTNnFc/Dka85bwBk9ylmeytDtMe4Y2HuRTZ5JBhlFNSmf 40UQ== X-Gm-Message-State: AEkoouvZ67yPJoD0DrrHGmEB1UHlAjCoyH03qhy+F1i4bKunLoY5j/FLXgq/+csdbs7/JQ== X-Received: by 10.233.235.143 with SMTP id b137mr28941308qkg.115.1470675510773; Mon, 08 Aug 2016 09:58:30 -0700 (PDT) Received: from localhost ([147.75.206.137]) by smtp.gmail.com with ESMTPSA id n128sm17964695qkc.36.2016.08.08.09.58.29 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Aug 2016 09:58:29 -0700 (PDT) Date: Mon, 8 Aug 2016 12:58:29 -0400 From: Kevin O'Connor To: linux-wireless@vger.kernel.org Subject: mac80211: AP changed bandwidth in a way we can't support - disconnect Message-ID: <20160808165829.GA10471@morn.lan> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.6.2 (2016-07-01) 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, I am getting periodic wifi disconnects. The logs show the following messages when I receive the disconnect: Sun Aug 7 16:12:59 2016 kern.info kernel: [321982.209148] wlan0: AP ... changed bandwidth, new config is 5500 MHz, width 1 (5500/0 MHz) Sun Aug 7 16:12:59 2016 kern.info kernel: [321982.218868] wlan0: AP ... changed bandwidth in a way we can't support - disconnect After the above messages, the connection immediately reconnects. It will typically stay up for a few hours and then go through the cycle again. The client (which I control) is a tp-link archer c7 router running openwrt (ath10k, QCA9880-BR4A, linux v4.1.23, mac80211.ko from compat-wireless-2016-01-10). The AP (which I do not have admin access to) appears to be a "Ruckus Wireless ZoneFlex 802.11ac wave 2 4x4 access point" To try and debug this, I altered the mac80211 code to display some additional debugging data and to not force a disconnect (see debugging patch below). With the altered code the client now stays connected. I occasionally see periodic debugging messages like the following: Sun Aug 7 17:52:54 2016 kern.info kernel: [327977.219622] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0 Sun Aug 7 17:53:02 2016 kern.info kernel: [327985.206823] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0 And then every few hours I'll get: Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.076091] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 1 (5500/0 MHz) 1024 Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.086633] wlan0: AP ... changed bandwidth, new config is 5500 MHz, width 1 (5500/0 MHz) Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.096362] wlan0: AP ... changed bandwidth in a way we can't support 1024 132 1 - ignore Sun Aug 7 18:13:04 2016 kern.info kernel: [329187.383324] wlan0: AP ... changed bandwidth, orig new config is 5500 MHz, width 3 (5530/0 MHz) 0 The above message sequence would have forced a disconnect in the past. The "width 3" message always immediately follows the "width 1" messages. If I'm interpreting the sequence correctly, the AP and client initially negotiate an 80mhz connection and then at some point the AP requests a 20mhz connection that is immediately followed by an 80mhz request. What is the best way to proceed with this error? I no longer have the disconnect issue with the debugging patch (which ignores the unsupported request instead of disconnecting), but it would be good to get a real fix upstream. Thanks. I'm not subscribed to the linux-wireless mailing list, so please CC me on replies. -Kevin Debugging patch: --- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- mlme.c~ 2016-06-30 14:51:00.999254180 -0400 +++ mlme.c 2016-08-03 18:31:08.938869667 -0400 @@ -345,6 +345,10 @@ ht_cap, ht_oper, vht_oper, &chandef, true); + sdata_info(sdata, + "AP %pM changed bandwidth, orig new config is %d MHz, width %d (%d/%d MHz) %d\n", + ifmgd->bssid, chandef.chan->center_freq, chandef.width, + chandef.center_freq1, chandef.center_freq2, flags); /* * Downgrade the new channel if we associated with restricted * capabilities. For example, if we associated as a 20 MHz STA @@ -377,9 +381,9 @@ IEEE80211_STA_DISABLE_160MHZ)) || !cfg80211_chandef_valid(&chandef)) { sdata_info(sdata, - "AP %pM changed bandwidth in a way we can't support - disconnect\n", - ifmgd->bssid); - return -EINVAL; + "AP %pM changed bandwidth in a way we can't support %d %d %d - ignore\n", + ifmgd->bssid, flags, ifmgd->flags, cfg80211_chandef_valid(&chandef)); + return 0; } switch (chandef.width) {