From owner-freebsd-wireless@freebsd.org Sun Oct 23 06:28:47 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D69BBC1E63B for ; Sun, 23 Oct 2016 06:28:47 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id AF427A36 for ; Sun, 23 Oct 2016 06:28:47 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-24-5-143-190.hsd1.ca.comcast.net [24.5.143.190]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id u9N6SdIw036551 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 22 Oct 2016 23:28:40 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-5-143-190.hsd1.ca.comcast.net [24.5.143.190] claimed to be yuri.doctorlan.com To: freebsd-wireless From: Yuri Subject: run0 USB NIC doesn't create the network interface on 11 Message-ID: <78513be8-b387-1fdf-45f8-7cf59bb33627@rawbw.com> Date: Sat, 22 Oct 2016 23:28:38 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 06:28:47 -0000 I upgraded the system from 10.3 to 11 and the network interface isn't created any more for this TP-Link / N600 card: > run0 on uhub3 > run0: <1.0> on usbus3 > run0: MAC/BBP RT5592 (rev 0x0222), RF RT5592 (MIMO 2T2R), address 60:xx:xx:xx:xx:xx What changed in 11? Yuri From owner-freebsd-wireless@freebsd.org Sun Oct 23 06:44:27 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94BF0C1E943 for ; Sun, 23 Oct 2016 06:44:27 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E135FBD for ; Sun, 23 Oct 2016 06:44:27 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id c78so51905372wme.0 for ; Sat, 22 Oct 2016 23:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7pBVUxwT1h8OQ6qhPT/PEXrUPCs7AEMciRX0vdyH5lM=; b=wlBJeqo6gvNunYNxgYQqGWQoqupsqs3ssAYdgn6tEahdIEIPqyTD/KSNR/x2yQ9536 1JjOlpd4W4Jh0DOqmuJhrSe6AN/mQkQsiVY9hKijPQwUUVLELqmUkFZttw4+chsj1M4i +3zDf7e363clsUtrGBOV62cxKj/7ub+WX/aIfc/CIWgZ8yA5qrslogfntl/H4pzpvrTA lNdtHzfW6yx473KBQpqGs6sWejAqPR+sOINbOhA0PouY/abY5u6iDodOHGwbBh1R547R qNL63bo1VYuOdzFKyRgN8XRww2dWu6+N1UnF0ZhDUSKMHlGycDiGjyT/w/XqqehjALg9 +f/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7pBVUxwT1h8OQ6qhPT/PEXrUPCs7AEMciRX0vdyH5lM=; b=ELFRkEGvJqAusGgsKN4EoPlHnnftMhn5HYl2nIWOiidkOiQ8T95o/8kfUiTLql9MSp cOZxG86+7eO0YR5ZGe2wCnDx30+9T/8t7nym2fvgjb4kG+jGXXxY5aDuuFAgYaoLrjUD 568NrajjgOIJrgaevwyPbb7s8ARuOOcOXrlGfC7gE8f/DZ25Es1XOJkkPym8JiTZOfbS ILIxZZbwreMboaqlCATZsapaWnSjAUlGYAHuzLoE/U/6qN48y9XUqBLZppTHGKZgchND HnQTiZnYE9Y1NjwawupUI1rHMnapheW4Y8UXCtROg8Bp4DKkWLx2ytz+wbinYpP3WW10 Z2Cg== X-Gm-Message-State: AA6/9RnRXS6zG05o0ktQhfv72uj+Qw1VpXDGyXCCVv01NoFRqYmdx13X2WRGhbB/pu2lcj2k+qE/fYsv7JDBEA== X-Received: by 10.28.132.130 with SMTP id g124mr17340114wmd.37.1477205065294; Sat, 22 Oct 2016 23:44:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.12.196 with HTTP; Sat, 22 Oct 2016 23:44:24 -0700 (PDT) In-Reply-To: <78513be8-b387-1fdf-45f8-7cf59bb33627@rawbw.com> References: <78513be8-b387-1fdf-45f8-7cf59bb33627@rawbw.com> From: Michael Zhilin Date: Sun, 23 Oct 2016 09:44:24 +0300 Message-ID: Subject: Re: run0 USB NIC doesn't create the network interface on 11 To: Yuri Cc: freebsd-wireless Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 06:44:27 -0000 Hi, Since 11- there is no network interface for wireless devices. To list wireless devices, please use: "sysctl net.wlan.devices". To create network interface, use: "ifconfig wlan0 create wlandev run0" (or via /etc/rc.conf, but I don't remember exact command). Thanks! On Sun, Oct 23, 2016 at 9:28 AM, Yuri wrote: > I upgraded the system from 10.3 to 11 and the network interface isn't > created any more for this TP-Link / N600 card: > > > run0 on uhub3 > > run0: <1.0> on usbus3 > > run0: MAC/BBP RT5592 (rev 0x0222), RF RT5592 (MIMO 2T2R), address > 60:xx:xx:xx:xx:xx > > > What changed in 11? > > > Yuri > > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org > " > From owner-freebsd-wireless@freebsd.org Sun Oct 23 09:11:41 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB179C1E532 for ; Sun, 23 Oct 2016 09:11:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C21C5378 for ; Sun, 23 Oct 2016 09:11:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u9N9BfdM065583 for ; Sun, 23 Oct 2016 09:11:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 213621] WIFI connection is lost periodically on ath0 Date: Sun, 23 Oct 2016 09:11:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kpect@protonmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 09:11:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213621 --- Comment #14 from Sergey --- Hello. I haven't seen those replays before, only yesterday, due to the messages fi= le it happened at 15:48 and 21:59. That's it. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-wireless@freebsd.org Sun Oct 23 21:00:06 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9311EC1E361 for ; Sun, 23 Oct 2016 21:00:06 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89B5463B for ; Sun, 23 Oct 2016 21:00:06 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u9NL01Ag036946 for ; Sun, 23 Oct 2016 21:00:06 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201610232100.u9NL01Ag036946@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-wireless@FreeBSD.org Subject: Problem reports for freebsd-wireless@FreeBSD.org that need special attention Date: Sun, 23 Oct 2016 21:00:06 +0000 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 21:00:06 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 206801 | iwn(4) page fault on netif restart Open | 154598 | [ath] Atheros 5424/2424 can't connect to WPA netw Open | 163312 | [panic] [ath] kernel panic: page fault with ath0 Open | 166190 | [ath] TX hangs and frames stuck in TX queue Open | 166357 | [ath] 802.11n TX stall when the first frame in th Open | 169362 | [ath] AR5416: radar pulse PHY errors sometimes in Open | 169433 | [iwn] iwn(4) doesn't support 6235 chip. Open | 211689 | panic with lagg failover wireless ath and iwm 8 problems total for which you should take action. From owner-freebsd-wireless@freebsd.org Mon Oct 24 14:21:15 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EBC3C1E00E for ; Mon, 24 Oct 2016 14:21:15 +0000 (UTC) (envelope-from cathie.den@performance-based-marketing.com) Received: from node1.gcmworldwidegroupasia.info (node1.gcmworldwidegroupasia.info [198.100.31.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1E288A58 for ; Mon, 24 Oct 2016 14:21:14 +0000 (UTC) (envelope-from cathie.den@performance-based-marketing.com) Received: from ManishKGRF (unknown [122.177.184.254]) by node1.gcmworldwidegroupasia.info (Postfix) with ESMTPA id 716AC141E5D for ; Mon, 24 Oct 2016 18:21:05 +0400 (MSD) From: "Cathie Den" To: Subject: Performance based Google Ranking Solution! Date: Mon, 24 Oct 2016 19:34:06 +0530 Message-ID: <16fd01d22e01$d5171370$7f453a50$@performance-based-marketing.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdIt/1RZYujEH538QgKFdy1h3pW34w== Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 14:21:15 -0000 Hey, Get into action! Google's top page is waiting for you! Are you wasting your time on conventional SEO? The New Age Performance SEO is here. Forget about investing money for your SEO efforts. It's time to THINK DIFFERENT. Intrigued? Give us a hand and let us take you to your destination, i.e., Top of Search Results. Who are we? We are ResultFirst, a 10-year-old company that has never fallen short of success stories to tell. Our unique SEO model attracts customers from all geographies of the world, and we are proud to cater to the needs of every type of business belonging to whichever industry, scale, or region. What we do? We do "Pay-For-Performance SEO." You are the boss here! You get to pay only when we rank your keywords on top searches. Yes, you heard it right! - No monthly fee / No contractual payout - FREE website analysis report. - Dedicated 24*7 support. - Only one time set up fee Why us? We are a bad business. We don't know how to earn. We believe in delivering results and helping businesses grow. Our goal is YOUR SUCCESS. Trust us, dropping a reply won't cost you a bit! We help everyone who calls up and we give a FREE website analysis report to every caller. Wanna give us a shot? Just reply to this email with your contact number and an expert will call you up. Warm Regards, Cathie Den Marketing Manager ResultFirst Inc. Head Office: San Jose, CA 95120 In case you are NOT INTERESTED, reply with "UNSUBSCRIBE" and you will be removed from our database within 2 business days, don't worry! From owner-freebsd-wireless@freebsd.org Mon Oct 24 16:36:10 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7F61C1F0EC for ; Mon, 24 Oct 2016 16:36:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6934676E for ; Mon, 24 Oct 2016 16:36:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-yb0-x229.google.com with SMTP id f97so80565343ybi.1 for ; Mon, 24 Oct 2016 09:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=J+/sN+bitASdhYr+/yvVClf1iazU2sLiIch6mqUR6+M=; b=seIsV4NXSjBrbjMmdg4Fo0ko0LWs7wmCxX1bSay/AY0ENWuv+VAjUW3G/8pvUNcZhW hPBxGr/kEQ3qdbypaIZ9kRpnDt48jANURKLRBZU98ZakKbkbQzjXusIe4TfM5RuTQ39V 14+ibPNlPs6v5wC53pWB+cTePvNXWrtdpfwc789mqUQvRxjiUz5TB5+7EvdEy2cRxWsc lbUdeVmfBPHadV4ylLyCTesYAWmi86tN906oLWTY6XMHKs0S88/hI2Ogg6R1y8pGQGih 9bUmkE9/zZdMj7SzNXQpPFFgjfP/sxzdHQGgsEKpKFV3JQO9282J1foyk03nuQbuGVs3 FVVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=J+/sN+bitASdhYr+/yvVClf1iazU2sLiIch6mqUR6+M=; b=e9QcsjvgTQGtQSfLolWGkLNPYrUySKmBhChCoJvofnB1+nOvk8/PJ5c1GPbHUanelI cTZfYvDWJaszBEuzMQKEcpTADLGe6K83QsVHiPJLt9esYHL1caP02zzBuiU+fiTtSnJO Xo23KuzXOU8ykVoGP+ZU74TpMS7WVmWgMOEMFHzPnpDbG169s0vri3ipWWVKAkeorgXE 9atpHRWHB7SGPkKJrsg3UoayvRJfBji1HEJ49Fc4N121IQPNp07IrbEyXDkEwK8pUVwg IbiFFx60aj+8X/z4+Z8SFUzYVbKw/0OoX7oAhJrcGLTT5y3RsoDr1ffx+MRb5E/M3P3F QmeQ== X-Gm-Message-State: ABUngvfRzZ2JlVZGOhpvGh3gPz+keY80nVsv0na0fL+9fumbmryCRaCjQZ/YFELoe38mcaswH4ehabdMY1nqFw== X-Received: by 10.36.220.130 with SMTP id q124mr2954767itg.78.1477326969179; Mon, 24 Oct 2016 09:36:09 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.36.141.129 with HTTP; Mon, 24 Oct 2016 09:36:08 -0700 (PDT) From: Adrian Chadd Date: Mon, 24 Oct 2016 09:36:08 -0700 X-Google-Sender-Auth: VyQb-CirsaRDTTVi7Dvs5LnJZ9E Message-ID: Subject: net80211 offload, crypto offload pieces To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 16:36:10 -0000 hiya, So I have my ath10k driver port up and running in 11abg (not n/ac) mode. The hardware is .. highly offload-y. There are three/four data pipelines - "raw" mode, "native wifi" mode, "ethernet" mode, and "management TX/RX" mode. * "raw" mode is raw, untouched 802.11 frames. This is the most flexible but it means we have to do software encryption and A-MSDU encap/decap. * "native wifi" mode is microsoft 802.11 framing. This is like 802.11, but there's no QoS field. Yes, the QoS field is in the descriptor field and the hardware will add/delete it for you. * "ethernet" mode is 802.3 encap/decap ethernet. * "management" mode is a separate TX/RX pipeline for management frames (eg beacons, probe requests, etc.) The firmware is the normal target for management frames and it takes care of sending up frames that the stack needs to see. Now, this makes crypto a bit of a pain to implement. Notably: * There's no hardware key index that we see. It's all done per-peer. So, each peer has the 0..4 wep key slot, then I think 0..4 for pairwise keys (even though we only support keyidx 0 for now) with flags to say "current TX key (for WEP), "pairwise", "group" keys. * The group key is per-peer - so no, you don't program it in with an address of ff:ff:ff:ff:ff:ff. It needs to be the BSS MAC. * For raw mode, you don't need any keys, just send frames. * For native wifi (and I'm guessing ethernet) you have to add a CLEAR GTK/PMK key to a peer before it'll start transmitting traffic to said peer - the firmware buffers frames until the four-way handshake is done. * For QoS traffic the hardware/firmware seems to corrupt software encryption. Which, if you think about it, makes sense - the hardware has to insert the QoS header into the frame and then transmit it, which means if it makes /any/ change to make the packet contents not line up, it won't decrypt right. The mac80211/ath10k paths do software encryption/decryption for GCMP, which we currently don't support. So there /is/ some way to do completely software encryption/decryption, as long as it's non-QoS management frame style traffic. So those are the annoying bits. The net80211 bits that need to change are: * The encryption hardware doesn't want an IV, FCS or MIC - it instead will add the IV, MIC and WEP FCS itself. So during encap we shouldn't provide it. * .. and for management traffic, it depends. Sometimes it does, sometimes it doesn't. * For decryption, the hardware will fully decrypt the frame, including stripping IV/MIC/WEPFCS. It instead passes up flags in the descriptor to say "decrypted ok", "MIC failed", "CRC/FCS failed", etc. So a lot of the decap path can't run - there's no IV to get a keyindex from, and there's no MIC to check against / strip. * There's no hardware keyindex - right now we have some kooky pointer magic to check if a given key is a global key (0..3) or not, rather than having a separate keyidx to hw_keyidx / hw_keyidx_rx. I think we should fix that up. And like other parts, key programming requires sleeping, which our current net80211 key management code doesn't let us do. So I'll have to teach the driver about a key update taskqueue + queue like urtwn, etc has - but ideally net80211 would do this for us. So, I do have it up and running with net80211 hacks to do the above. It's not very pretty, but it does work. But I'd like to start thinking about how to support these crypto offload modes in a more useful fashion. Notably: * per-key flags to say "don't add IV for non-mgmt", "don't add IV for mgmt" - which is backwards compatible with what we currently do, but is the exact opposite of what linux does. I'd kinda like to instead add flags that say "add IV" and "add MIC" for "mgmt" or "non-mgmt", and then teach the handful of drivers about it as appropriate. * the input paths need to know about the encrypted offload flags. There's no FC1_PROTECTED set for hardware-decrypted frames, they look exactly like decrypted frames do normally. * the input paths also need to know about stripped IV, MIC and FCSWEP. Ie, none of the normal crypto_decap module paths can run as we can't verify things - only that the frame was initially encrypted. So: * ieee80211_crypto_decap() has to be able to say "this frame is fine, but there's no key, so don't treat that as an error"; and * ieee80211_crypto_demic() has to be able to take a NULL key, and run the demic check against the RX flags - and if it fails, call the mic failure notify path directly. Yes, this also means there's no RSC/TSC PN tracking for CCMP/TKIP paths. So with all of that - I'd appreciate some feedback/comments. I'm going to start undoing my hacks and turning them into a set of cleanish pieces, but the real "hm!" is what to do about default flag behaviour for keys and whether to do what mac80211 does. Thanks! -adrian From owner-freebsd-wireless@freebsd.org Mon Oct 24 17:38:15 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9AC1CC1EE7C for ; Mon, 24 Oct 2016 17:38:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89ED1FAB for ; Mon, 24 Oct 2016 17:38:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u9OHcF84058190 for ; Mon, 24 Oct 2016 17:38:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 213621] WIFI connection is lost periodically on ath0 Date: Mon, 24 Oct 2016 17:38:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kpect@protonmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 17:38:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213621 --- Comment #15 from Sergey --- Something new in dmesg: ath0: ath_tx_aggr_comp_aggr: AR5416 bug: hasba=3D0; txok=3D1, isaggr=3D1, s= eq_st=3D3882 Q1[ 0] (nseg=3D2) (DS.V:0xfffffe01b3125700 DS.P:0xbfe3f700) I: 168cc117 L:bfe66300 F:1014 (D[0] =3D 47062e5e(002c0000), D[1] =3D 4746d580(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 63168 swtry: 0 ADDBAW?: 1 DOBAW?: 1 cff98d15 4068006a 60008000 04348000 00898a8b 80918078 000080c7 88f0048e 00903def 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b314c300 DS.P:0xbfe66300) I: 168cc117 L:bfe64f00 F:0004 (D[0] =3D 4706275e(002c0000), D[1] =3D 471a1780(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 63184 swtry: 0 ADDBAW?: 1 DOBAW?: 1 cffab3e8 4028006a 60008000 04348000 008c8d8e 808d8082 000080ae 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b314af00 DS.P:0xbfe64f00) I: 168cc117 L:bfe7cb00 F:0004 (D[0] =3D 474e255e(002c0000), D[1] =3D 47111b80(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 63200 swtry: 0 ADDBAW?: 1 DOBAW?: 1 cffb3228 4028006a 60008000 24348000 898d8e8f 802c802c 803a8030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3162b00 DS.P:0xbfe7cb00) I: 168cc117 L:00000000 F:0004 (D[0] =3D 4719ce5e(002c0000), D[1] =3D 0774cc80(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 63216 swtry: 0 ADDBAW?: 1 DOBAW?: 1 cffcc170 4028006a 40008000 04348000 008a8b8c 80d5809c 0000810f 08000000 00000000 20000000 00000000 00000000 00000000 [end] ath0: ath_tx_aggr_comp_aggr: AR5416 bug: hasba=3D0; txok=3D1, isaggr=3D1, s= eq_st=3D3892 Q1[ 0] (nseg=3D2) (DS.V:0xfffffe01b3107200 DS.P:0xbfe21200) I: 168cc117 L:bfe74400 F:1004 (D[0] =3D 0774a25e(002c0000), D[1] =3D 474ba080(00690000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64736 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d05b6dbe 4068009f 60008000 04348000 00858687 80458041 00008048 88f00202 70903def 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b315a400 DS.P:0xbfe74400) I: 168cc117 L:00000000 F:0004 (D[0] =3D 4706b35e(002c0000), D[1] =3D 0416e000(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64752 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d05cb67f 4028006a 40008000 04348000 008d8e8f 802c802c 00008030 08000000 00000000 20000000 00000000 00000000 00000000 [end] ath0: ath_tx_aggr_comp_aggr: AR5416 bug: hasba=3D0; txok=3D1, isaggr=3D1, s= eq_st=3D3984 Q1[ 0] (nseg=3D2) (DS.V:0xfffffe01b3107200 DS.P:0xbfe21200) I: 168cc117 L:bfe74400 F:1004 (D[0] =3D 0774a25e(002c0000), D[1] =3D 474ba080(00690000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64736 swtry: 1 ADDBAW?: 1 DOBAW?: 1 d05b6dbe 4068009f 60008000 04348000 00858687 809f8094 000080ad 88f007eb 70903def 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b315a400 DS.P:0xbfe74400) I: 168cc117 L:bfe07300 F:0004 (D[0] =3D 4706b35e(002c0000), D[1] =3D 0416e000(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64752 swtry: 1 ADDBAW?: 1 DOBAW?: 1 d05ce95f 4028006a 60008000 04348000 008d8e8f 802c802c 00008030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b30ed300 DS.P:0xbfe07300) I: 168cc117 L:bfe96500 F:0004 (D[0] =3D 47060d5e(002c0000), D[1] =3D 01d63000(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64784 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d05e8327 4028006a 60008000 24348000 898c8d8e 802c802c 80378030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b317c500 DS.P:0xbfe96500) I: 168cc117 L:bfe84800 F:0004 (D[0] =3D 07752a5e(002c0000), D[1] =3D 471a5580(00690000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64800 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d05fae8e 4028009f 60008000 24348000 888a8b8c 80338030 80498033 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b316a800 DS.P:0xbfe84800) I: 168cc117 L:bfe8c000 F:0004 (D[0] =3D 4706c35e(002c0000), D[1] =3D 4719f180(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64816 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d0609aeb 4028006a 60008000 24348000 888a8b8c 80338030 80498033 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3172000 DS.P:0xbfe8c000) I: 168cc117 L:00000000 F:0004 (D[0] =3D 474a6d5e(002c0000), D[1] =3D 0412c000(00690000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64832 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d06150f3 4028009f 40008000 24348000 888a8b8c 80338030 80498033 08000000 00000000 20000000 00000000 00000000 00000000 [end] ath0: ath_tx_aggr_comp_aggr: AR5416 bug: hasba=3D0; txok=3D1, isaggr=3D1, s= eq_st=3D3989 Q1[ 0] (nseg=3D2) (DS.V:0xfffffe01b3107200 DS.P:0xbfe21200) I: 168cc117 L:bfe74400 F:1004 (D[0] =3D 0774a25e(002c0000), D[1] =3D 474ba080(00690000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64736 swtry: 2 ADDBAW?: 1 DOBAW?: 1 d05b6dbe 4068009f 60008000 04348000 00858687 80f980e3 00008112 88f00dd2 70903def 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b315a400 DS.P:0xbfe74400) I: 168cc117 L:bfe07300 F:0004 (D[0] =3D 4706b35e(002c0000), D[1] =3D 0416e000(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64752 swtry: 2 ADDBAW?: 1 DOBAW?: 1 d05ce95f 4028006a 60008000 04348000 008d8e8f 802c802c 00008030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b30ed300 DS.P:0xbfe07300) I: 168cc117 L:bfe96500 F:0004 (D[0] =3D 47060d5e(002c0000), D[1] =3D 01d63000(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64784 swtry: 1 ADDBAW?: 1 DOBAW?: 1 d05e8327 4028006a 60008000 24348000 898c8d8e 802c802c 80378030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b317c500 DS.P:0xbfe96500) I: 168cc117 L:bfe84800 F:0004 (D[0] =3D 07752a5e(002c0000), D[1] =3D 471a5580(00690000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64800 swtry: 1 ADDBAW?: 1 DOBAW?: 1 d05fae8e 4028009f 60008000 24348000 888a8b8c 80338030 80498033 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b316a800 DS.P:0xbfe84800) I: 168cc117 L:bfe8c000 F:0004 (D[0] =3D 4706c35e(002c0000), D[1] =3D 4719f180(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64816 swtry: 1 ADDBAW?: 1 DOBAW?: 1 d0609aeb 4028006a 60008000 24348000 888a8b8c 80338030 80498033 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3172000 DS.P:0xbfe8c000) I: 168cc117 L:bfe5aa00 F:0004 (D[0] =3D 474a6d5e(002c0000), D[1] =3D 0412c000(00690000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64832 swtry: 1 ADDBAW?: 1 DOBAW?: 1 d061bad9 4028009f 60008000 24348000 888a8b8c 80338030 80498033 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3140a00 DS.P:0xbfe5aa00) I: 168cc117 L:bfe81600 F:0004 (D[0] =3D 472c145e(002c0000), D[1] =3D 47068580(00690000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64864 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d063d631 4028009f 60008000 04348000 008a8b8c 8091806d 000080b1 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3167600 DS.P:0xbfe81600) I: 168cc117 L:bfe14500 F:0004 (D[0] =3D 474adc5e(002c0000), D[1] =3D 47413980(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64880 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d064814f 4028006a 60008000 04348000 008a8b8c 813380dc 0000818d 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b30fa500 DS.P:0xbfe14500) I: 168cc117 L:bfe75800 F:0004 (D[0] =3D 474fd85e(002c0000), D[1] =3D 041a7000(00690000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64896 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d06583e8 4028009f 60008000 04348000 008c8d8e 80dc80ca 0000811a 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b315b800 DS.P:0xbfe75800) I: 168cc117 L:00000000 F:0004 (D[0] =3D 472c1d5e(002c0000), D[1] =3D 4746d880(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64912 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d0665c54 4028006a 40008000 04348000 008d8e8f 802c802c 00008030 08000000 00000000 20000000 00000000 00000000 00000000 [end] ath0: ath_tx_aggr_comp_aggr: AR5416 bug: hasba=3D0; txok=3D1, isaggr=3D1, s= eq_st=3D3994 Q1[ 0] (nseg=3D1) (DS.V:0xfffffe01b3184c00 DS.P:0xbfe9ec00) I: 168cc117 L:bfe73a00 F:1004 (D[0] =3D 7059a030(00540000), D[1] =3D 00000000(00000000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64976 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d06ae268 4068005e 60008000 04348000 00858687 807e8074 00008089 88f005b2 70903def 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3159a00 DS.P:0xbfe73a00) I: 168cc117 L:bfe7a300 F:0004 (D[0] =3D 01d64000(00540000), D[1] =3D 00000000(00000000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 64992 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d06b7cb5 4028005e 60008000 24348000 888a8b8c 80338030 80508037 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3160300 DS.P:0xbfe7a300) I: 168cc117 L:bfe85200 F:0014 (D[0] =3D 041b1000(00540000), D[1] =3D 00000000(00000000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 65008 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d06cfdfb 4028005e 60008000 24348000 888a8b8c 80338030 80498033 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b316b200 DS.P:0xbfe85200) I: 168cc117 L:bfe8b600 F:0004 (D[0] =3D 19f1d030(00540000), D[1] =3D 00000000(00000000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 65024 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d06d3802 4028005e 60008000 24348000 888a8b8c 80338030 80498033 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3171600 DS.P:0xbfe8b600) I: 168cc117 L:00000000 F:0004 (D[0] =3D 0412e000(00540000), D[1] =3D 00000000(00000000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 65040 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d06ebc0a 4028005e 40008000 24348000 88898a8b 808a8070 814580b8 08000000 00000000 20000000 00000000 00000000 00000000 [end] ath0: ath_tx_aggr_comp_aggr: AR5416 bug: hasba=3D0; txok=3D1, isaggr=3D1, s= eq_st=3D2029 Q1[ 0] (nseg=3D2) (DS.V:0xfffffe01b316da00 DS.P:0xbfe87a00) I: 168cc117 L:bfe3a200 F:1004 (D[0] =3D bfec3000(002c0000), D[1] =3D 041bf000(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 928 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d0c71def 4068006a 60008000 04348000 008a8b8c 8091806d 000080b1 88f005ee 00903def 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3120200 DS.P:0xbfe3a200) I: 168cc117 L:bfe45100 F:0004 (D[0] =3D 04178000(002c0000), D[1] =3D 47054a80(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 944 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d0c8fe84 4028006a 60008000 24348000 898c8d8e 8030802c 803a8030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b312b100 DS.P:0xbfe45100) I: 168cc117 L:bfe2a800 F:0004 (D[0] =3D 471a525e(002c0000), D[1] =3D 4706a380(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 960 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d0c9c3e5 4028006a 60008000 24348000 898c8d8e 8030802c 803a8030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3110800 DS.P:0xbfe2a800) I: 168cc117 L:bfe96a00 F:0004 (D[0] =3D 47050a5e(002c0000), D[1] =3D 0774fa80(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 976 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d0ca5545 4028006a 60008000 24348000 898c8d8e 8030802c 803a8030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b317ca00 DS.P:0xbfe96a00) I: 168cc117 L:00000000 F:0014 (D[0] =3D 474e245e(002c0000), D[1] =3D 474e2380(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 992 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d0cbae7e 4028006a 40008000 24348000 898c8d8e 8030802c 803a8030 08000000 00000000 20000000 00000000 00000000 00000000 [end] ath0: ath_tx_aggr_comp_aggr: AR5416 bug: hasba=3D0; txok=3D1, isaggr=3D1, s= eq_st=3D4095 Q1[ 0] (nseg=3D2) (DS.V:0xfffffe01b3120200 DS.P:0xbfe3a200) I: 168cc117 L:bfe45100 F:1004 (D[0] =3D 04178000(002c0000), D[1] =3D 47054a80(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 944 swtry: 1 ADDBAW?: 1 DOBAW?: 1 d0c8fe84 4068006a 60008000 04348000 008a8b8c 8091806d 000080b1 88f005ee 00903def 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b312b100 DS.P:0xbfe45100) I: 168cc117 L:bfe2a800 F:0004 (D[0] =3D 471a525e(002c0000), D[1] =3D 4706a380(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 960 swtry: 1 ADDBAW?: 1 DOBAW?: 1 d0c9c3e5 4028006a 60008000 24348000 898c8d8e 8030802c 803a8030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b3110800 DS.P:0xbfe2a800) I: 168cc117 L:bfe96a00 F:0004 (D[0] =3D 47050a5e(002c0000), D[1] =3D 0774fa80(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 976 swtry: 1 ADDBAW?: 1 DOBAW?: 1 d0ca5545 4028006a 60008000 24348000 898c8d8e 8030802c 803a8030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b317ca00 DS.P:0xbfe96a00) I: 168cc117 L:bfe18b00 F:0014 (D[0] =3D 474e245e(002c0000), D[1] =3D 474e2380(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 992 swtry: 1 ADDBAW?: 1 DOBAW?: 1 d0cbf95f 4028006a 60008000 24348000 898c8d8e 8030802c 803a8030 08f00000 00000000 20000000 00000000 00000000 00000000 [end] (DS.V:0xfffffe01b30feb00 DS.P:0xbfe18b00) I: 168cc117 L:00000000 F:0004 (D[0] =3D 07748c5e(002c0000), D[1] =3D 4746da80(00340000) (D[2] =3D 00000000(00000000), D[3] =3D 00000000(00000000) Seq: 1008 swtry: 0 ADDBAW?: 1 DOBAW?: 1 d0cc8d9d 4028006a 40008000 24348000 898c8d8e 8030802c 803a8030 08000000 00000000 20000000 00000000 00000000 00000000 [end] ifa_maintain_loopback_route: deletion failed for interface wlan0: 3 wlan0: link state changed to DOWN --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-wireless@freebsd.org Mon Oct 24 19:02:10 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26E0CC1FFB0 for ; Mon, 24 Oct 2016 19:02:10 +0000 (UTC) (envelope-from andriyvos@gmail.com) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA6F983F; Mon, 24 Oct 2016 19:02:09 +0000 (UTC) (envelope-from andriyvos@gmail.com) Received: by mail-lf0-f45.google.com with SMTP id x79so209836450lff.0; Mon, 24 Oct 2016 12:02:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:subject:references:date:cc:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=KDvnwye7WAikKGqwwXEl628wzE2lzUlxPmuDV4n7bys=; b=Iooa+GawN1B1yWzLrtdxPucMM2Yo9LWk0hq2i/5zfvwzTZE0mhJ24RqFl1VJk79rSR VaQE/ZuBOJ1uOqhODP2YCfed1I2tY/OnFiSIvdoCZ/ozmKuMGYow2QBYMDedbN6a6Fkg 1RZeeSJo8Ka/1WnBzBwO9B2Lo1wWAQBm14NfYFTxmUOc84LPS74efX6urLAVDL2uf2CJ h14pmOiNJoLE7Fvdyaq9iom5Htn15LsnXrtsPvMzt+zPzAty0BSBkGBWNlp3/e/6OXr2 VCuclHiaaoJrvj1eWNfKPoY/Xjbq/VNqEu/NjSW8BoRPwT4g29vZyEbyIpptSNzGsnwi Yn6g== X-Gm-Message-State: ABUngvfR0XWsjWKlKG7HfujN+7QJZKKkAhD6emzuW7i6u+E0jWwRQr+B0QoNeXvFmjYNGw== X-Received: by 10.25.40.74 with SMTP id o71mr8369481lfo.183.1477335305174; Mon, 24 Oct 2016 11:55:05 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id y131sm3278072lfd.26.2016.10.24.11.55.04 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 24 Oct 2016 11:55:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Adrian Chadd" Subject: Re: net80211 offload, crypto offload pieces References: Date: Mon, 24 Oct 2016 21:55:08 +0300 Cc: "freebsd-wireless@freebsd.org" MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 19:02:10 -0000 Mon, 24 Oct 2016 19:36:08 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Adrian Chadd = : Hi! > hiya, > > So I have my ath10k driver port up and running in 11abg (not n/ac) > mode. The hardware is .. highly offload-y. There are three/four data > pipelines - "raw" mode, "native wifi" mode, "ethernet" mode, and > "management TX/RX" mode. > > * "raw" mode is raw, untouched 802.11 frames. This is the most > flexible but it means we have to do software encryption and A-MSDU > encap/decap. > * "native wifi" mode is microsoft 802.11 framing. This is like 802.11,= > but there's no QoS field. Yes, the QoS field is in the descriptor > field and the hardware will add/delete it for you. > * "ethernet" mode is 802.3 encap/decap ethernet. > * "management" mode is a separate TX/RX pipeline for management frames= > (eg beacons, probe requests, etc.) The firmware is the normal target > for management frames and it takes care of sending up frames that the > stack needs to see. > > Now, this makes crypto a bit of a pain to implement. Notably: > > * There's no hardware key index that we see. It's all done per-peer. > So, each peer has the 0..4 wep key slot, then I think 0..4 for > pairwise keys (even though we only support keyidx 0 for now) with > flags to say "current TX key (for WEP), "pairwise", "group" keys. > * The group key is per-peer - so no, you don't program it in with an > address of ff:ff:ff:ff:ff:ff. It needs to be the BSS MAC. That's similar to wpi(4) / iwn(4) crypto: - they has some special 'set global WEP keys 0..3' firmware command; - every node (24 for wpi(4), 16 (?) for iwn(4) has its own Rx key table (8 pairwise + 8 group). - encryption key is set in Tx descriptor. (BTW, that's already implemented in wpi(4) (AES-CCM only)) > * For raw mode, you don't need any keys, just send frames. > * For native wifi (and I'm guessing ethernet) you have to add a CLEAR > GTK/PMK key to a peer before it'll start transmitting traffic to said > peer - the firmware buffers frames until the four-way handshake is > done. > * For QoS traffic the hardware/firmware seems to corrupt software > encryption. Which, if you think about it, makes sense - the hardware > has to insert the QoS header into the frame and then transmit it, > which means if it makes /any/ change to make the packet contents not > line up, it won't decrypt right. > > The mac80211/ath10k paths do software encryption/decryption for GCMP, > which we currently don't support. So there /is/ some way to do > completely software encryption/decryption, as long as it's non-QoS > management frame style traffic. > > So those are the annoying bits. The net80211 bits that need to change = = > are: > > * The encryption hardware doesn't want an IV, FCS or MIC - it instead > will add the IV, MIC and WEP FCS itself. So during encap we shouldn't > provide it. > * .. and for management traffic, it depends. Sometimes it does, > sometimes it doesn't. > * For decryption, the hardware will fully decrypt the frame, including= > stripping IV/MIC/WEPFCS. It instead passes up flags in the descriptor > to say "decrypted ok", "MIC failed", "CRC/FCS failed", etc. So a lot > of the decap path can't run - there's no IV to get a keyindex from, > and there's no MIC to check against / strip. run(4) does something similar - it does not call ieee80211_crypto_encap(= ) for Tx and checks Rx descriptor flags before passing the frame to net802= 11 > * There's no hardware keyindex - right now we have some kooky pointer > magic to check if a given key is a global key (0..3) or not, rather > than having a separate keyidx to hw_keyidx / hw_keyidx_rx. I think we > should fix that up. > > And like other parts, key programming requires sleeping, which our > current net80211 key management code doesn't let us do. So I'll have > to teach the driver about a key update taskqueue + queue like urtwn, > etc has - but ideally net80211 would do this for us. > > So, I do have it up and running with net80211 hacks to do the above. > It's not very pretty, but it does work. But I'd like to start thinking= > about how to support these crypto offload modes in a more useful > fashion. Notably: > > * per-key flags to say "don't add IV for non-mgmt", "don't add IV for > mgmt" - which is backwards compatible with what we currently do, but > is the exact opposite of what linux does. I'd kinda like to instead > add flags that say "add IV" and "add MIC" for "mgmt" or "non-mgmt", > and then teach the handful of drivers about it as appropriate. > > * the input paths need to know about the encrypted offload flags. > There's no FC1_PROTECTED set for hardware-decrypted frames, they look > exactly like decrypted frames do normally. > > * the input paths also need to know about stripped IV, MIC and FCSWEP.= > Ie, none of the normal crypto_decap module paths can run as we can't > verify things - only that the frame was initially encrypted. So: > > * ieee80211_crypto_decap() has to be able to say "this frame is fine, > but there's no key, so don't treat that as an error"; and > * ieee80211_crypto_demic() has to be able to take a NULL key, and run > the demic check against the RX flags - and if it fails, call the mic > failure notify path directly. > > Yes, this also means there's no RSC/TSC PN tracking for CCMP/TKIP path= s. > > So with all of that - I'd appreciate some feedback/comments. I'm going= > to start undoing my hacks and turning them into a set of cleanish > pieces, but the real "hm!" is what to do about default flag behaviour > for keys and whether to do what mac80211 does. > > Thanks! > > > -adrian > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to = > "freebsd-wireless-unsubscribe@freebsd.org" From owner-freebsd-wireless@freebsd.org Mon Oct 24 19:09:15 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C315C1F1E3 for ; Mon, 24 Oct 2016 19:09:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B318C18; Mon, 24 Oct 2016 19:09:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-yb0-x231.google.com with SMTP id 205so6092516ybz.5; Mon, 24 Oct 2016 12:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=KglK8xWYwAcJiZB6i+c6mBMdalKwklCCDdV6T6Iihac=; b=LVb3GgzvLUZHWb582PoO9/UwU/1HazbHegrk76OKf47AQ/l3hPziK3cNFjXfb5OqQw by8ZAnlRfyQiUMd56BkkFE/K8GUAaei6TlZ4VbyAdqPh44ZNmAHrG7IIZycm8dXVL560 TeqKBos3MTDXskOy21KlAbVZ/RbIFcIav6c3QTcf3Lhig8pyzGEOoTPGAMtCEWm5tT/e riw7pL8iEPGZb+p12mZY5YfhyQ/RJN4jkasFGx5gcLRfyuNpJ43dohM/Fx+EOGcFTtD/ 3vNJXvH8HhqDXDTix/uxs3Jhdo5A0UjpVR2lGKV/eUvuuICxPcEo2I4kn32YBCIGQTN0 5AfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=KglK8xWYwAcJiZB6i+c6mBMdalKwklCCDdV6T6Iihac=; b=KPoChlwAM14/cU/hvWPxyw1Dc9wzT/nuzNObbavFZ6jADpXkzZkhivBGnKQcalpkgM ND8GpeFVKmcWWmZr0Zo3z8W4xZ1QcIrrXIDDyVRZkW9bg9Br2+E0YpiP82D8QSW4ipBw P0dEKcoO8th18xsnA53g5hmwyXBnAP1O/0G4tNgpVi2MsW1cANf7RTMjcQB8DQAQP1WQ Gd+LlV42AG98ch3Tm6j0L41y9QQUDNI4xp6ujo3cBlI7fgXhZheI6nti3y07yYWTohv3 FOW9I9QD9BtwV5t7cFA6SVfcy7YTS+1rRlLNbXGvn2ZAxvZEmojrmIiy4blSR3oWJdBD +txg== X-Gm-Message-State: ABUngveUw+L5CArJXzTAu4sajUt0C0F7IDeCDoeR5gp40F0lLnnmDciCcSjbfIz0618RE7dNagM6Lhh9T0m5sA== X-Received: by 10.36.73.19 with SMTP id z19mr3421806ita.29.1477336153807; Mon, 24 Oct 2016 12:09:13 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.36.141.129 with HTTP; Mon, 24 Oct 2016 12:09:13 -0700 (PDT) In-Reply-To: References: From: Adrian Chadd Date: Mon, 24 Oct 2016 12:09:13 -0700 X-Google-Sender-Auth: wylqq_-6e4qLvfbwBdVJqRcqQwQ Message-ID: Subject: Re: net80211 offload, crypto offload pieces To: Andriy Voskoboinyk Cc: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 19:09:15 -0000 On 24 October 2016 at 11:55, Andriy Voskoboinyk wrote: > Mon, 24 Oct 2016 19:36:08 +0300 =D0=B1=D1=83=D0=BB=D0=BE =D0=BD=D0=B0=D0= =BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE Adrian Chadd > : > > Hi! > >> hiya, >> >> So I have my ath10k driver port up and running in 11abg (not n/ac) >> mode. The hardware is .. highly offload-y. There are three/four data >> pipelines - "raw" mode, "native wifi" mode, "ethernet" mode, and >> "management TX/RX" mode. >> >> * "raw" mode is raw, untouched 802.11 frames. This is the most >> flexible but it means we have to do software encryption and A-MSDU >> encap/decap. >> * "native wifi" mode is microsoft 802.11 framing. This is like 802.11, >> but there's no QoS field. Yes, the QoS field is in the descriptor >> field and the hardware will add/delete it for you. >> * "ethernet" mode is 802.3 encap/decap ethernet. >> * "management" mode is a separate TX/RX pipeline for management frames >> (eg beacons, probe requests, etc.) The firmware is the normal target >> for management frames and it takes care of sending up frames that the >> stack needs to see. >> >> Now, this makes crypto a bit of a pain to implement. Notably: >> >> * There's no hardware key index that we see. It's all done per-peer. >> So, each peer has the 0..4 wep key slot, then I think 0..4 for >> pairwise keys (even though we only support keyidx 0 for now) with >> flags to say "current TX key (for WEP), "pairwise", "group" keys. >> * The group key is per-peer - so no, you don't program it in with an >> address of ff:ff:ff:ff:ff:ff. It needs to be the BSS MAC. > > > > That's similar to wpi(4) / iwn(4) crypto: > - they has some special 'set global WEP keys 0..3' firmware command; > - every node (24 for wpi(4), 16 (?) for iwn(4) has its own Rx key table > (8 pairwise + 8 group). > - encryption key is set in Tx descriptor. > (BTW, that's already implemented in wpi(4) (AES-CCM only)) Ok, so good - this work can be used by the other NICs in a mostly immediate fashion. >> * For raw mode, you don't need any keys, just send frames. >> * For native wifi (and I'm guessing ethernet) you have to add a CLEAR >> GTK/PMK key to a peer before it'll start transmitting traffic to said >> peer - the firmware buffers frames until the four-way handshake is >> done. >> * For QoS traffic the hardware/firmware seems to corrupt software >> encryption. Which, if you think about it, makes sense - the hardware >> has to insert the QoS header into the frame and then transmit it, >> which means if it makes /any/ change to make the packet contents not >> line up, it won't decrypt right. >> >> The mac80211/ath10k paths do software encryption/decryption for GCMP, >> which we currently don't support. So there /is/ some way to do >> completely software encryption/decryption, as long as it's non-QoS >> management frame style traffic. >> >> So those are the annoying bits. The net80211 bits that need to change ar= e: >> >> * The encryption hardware doesn't want an IV, FCS or MIC - it instead >> will add the IV, MIC and WEP FCS itself. So during encap we shouldn't >> provide it. >> * .. and for management traffic, it depends. Sometimes it does, >> sometimes it doesn't. >> * For decryption, the hardware will fully decrypt the frame, including >> stripping IV/MIC/WEPFCS. It instead passes up flags in the descriptor >> to say "decrypted ok", "MIC failed", "CRC/FCS failed", etc. So a lot >> of the decap path can't run - there's no IV to get a keyindex from, >> and there's no MIC to check against / strip. > > > > run(4) does something similar - it does not call ieee80211_crypto_encap() > for Tx and checks Rx descriptor flags before passing the frame to net8021= 1 Ok. So we should fix this in the TX encap path in net80211 first, then make sure we call crypto_encap in run. The reason? So when we grow say, GCMP (for management frame protection) we can do hybrid software/hardware crypto schemes. -adrian From owner-freebsd-wireless@freebsd.org Thu Oct 27 23:54:57 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BE57C244A1 for ; Thu, 27 Oct 2016 23:54:57 +0000 (UTC) (envelope-from papowell@astart.com) Received: from astart2.astart.com (wsip-72-214-30-30.sd.sd.cox.net [72.214.30.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 33AC8D8C for ; Thu, 27 Oct 2016 23:54:56 +0000 (UTC) (envelope-from papowell@astart.com) Received: from laptop_103.private (localhost [127.0.0.1]) by astart2.astart.com (8.14.9/8.14.9) with ESMTP id u9RNi7uc056288 for ; Thu, 27 Oct 2016 16:44:07 -0700 (PDT) (envelope-from papowell@astart.com) Reply-To: papowell@astart.com Subject: Re: [Bug 213621] WIFI connection is lost periodically on ath0 References: To: freebsd-wireless@freebsd.org From: Patrick Powell Organization: Astart Technologies Message-ID: Date: Thu, 27 Oct 2016 16:44:07 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 23:54:57 -0000 On 10/22/16 13:30, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213621 > > --- Comment #12 from Adrian Chadd --- > Hiya, > > So the beacon miss / TSFOOR is the driver side. I can go take another look at > fixing that up. > > The CCMP replay attack thing - that we need another NIC to sniff the air in > monitor mode and try to capture the invalid PN showing up in the air. If it's > coming over the air then sure, we can nail it down. If it's not coming over the > air, and instead it's corrupted by the AR9380 NIC, we're in trouble. > > I need to go double / triple-check to see if we pass frames that fail > CRC/FCS/decrypt up to the stack for incorrect processing. I'm kinda worried > that we're processing invalid frames a little too far along the input / > decryption path. > Ummm... I am not familiar with this device, but I have run into similar issues on other IO devices. Do you have a spare/replacement device you can substitute in? It turned out that on one system one of the device chip registers was magically 'losing' a bit. We did not discover the cause of this problem until after much pain and effort and we replaced the motherboard. After that experience, I always try a replacement device first. Also, if is software related then the replacement will continue to show the problem. If it is hardware then you will get NO problems, or if Murphy's Law is active, DIFFERENT problems. Good luck, Adrian, you have solved some REALLY weird problems before. -- Patrick Powell Astart Technologies papowell@astart.com 1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting 858-874-6543 FAX 858-751-2435 Web: www.astart.com From owner-freebsd-wireless@freebsd.org Fri Oct 28 02:17:12 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 652E4C23C15 for ; Fri, 28 Oct 2016 02:17:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EF0E379 for ; Fri, 28 Oct 2016 02:17:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-oi0-x22c.google.com with SMTP id y2so92397338oie.0 for ; Thu, 27 Oct 2016 19:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=VIE5lPuCQcq6ae3tY9b7Amzmuo4Cc67sezftqGBHCTY=; b=L+GZhccwXXk8RZYPl5HuRSGbr0VQRYEInQIQOXEfO2ozZyRdYbgUDCRvI9Q3VJPSLL 1dewvIGXE6uWMcO+RR+1larK7x1JN7APYXHTrSKFskV2iPklZv4TxjB3c/h6WEijDWXy stVp5Y2uaRDBgnEPI8gk5SoLVAf1CxWqy1yyU6Bd2iJ1lSMcZCZKj2qprnL+MPh97xjv F6ET8CQMnJjreS1gEtcJyYV6kkgwMwcLlBWXpkRC+kRFE6UtvjBAz18ryv426mFZNc2z xEmMh6PZTN33fgvQgDKH2J0UXbeAyiPb2VAg5f1pgluuVNlY0OyyTBOKXJ7KqHGG2z0l +YIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=VIE5lPuCQcq6ae3tY9b7Amzmuo4Cc67sezftqGBHCTY=; b=DVCdHUeLrwcQtUeOT8SGOvefbD26dEkP/OTMCWlG09WYlJBHxdblPb59qCwjI1hD0V EGyZfleq062vsh2SdQUSAv1HI5bgIwuELAo9VUZYcsMWrsC6PvXURAamIR8aDfITM2if sI8F2R4fNVYIMrln0JkdO7sRT4mOWEHqOkcJNw14ydwRjLaRZ2NYFu0mbmyJ0YqxjDzT +IDvWa65s7b8y4caBC85Oo2smb1tF2nXLbYUn7x6sUMjNkXGiMM4RMgBgSywVY/QxQN/ SwWDymZFhDCPP7VYWcK756nyBc7aV9ehkq0i/DjjOzj9DoqmfOEWpv2GefQXYtSTz7zU HT2g== X-Gm-Message-State: ABUngvdPKeUREk8ZmMbWzHBKCJR8NOepQ0llOnhaQ1MwC9juoMoH2uKK9R7b7AJLiQd01VeUyFj9ylaEhBKQmQ== X-Received: by 10.107.192.130 with SMTP id q124mr9187454iof.129.1477621031188; Thu, 27 Oct 2016 19:17:11 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.36.39.134 with HTTP; Thu, 27 Oct 2016 19:17:10 -0700 (PDT) From: Adrian Chadd Date: Thu, 27 Oct 2016 19:17:10 -0700 X-Google-Sender-Auth: FKHO0rFb83zoIptlbuSm7ZReBWA Message-ID: Subject: net80211 reviews - 11n IBSS work and crypto offload work To: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 02:17:12 -0000 hiya, I have two new commit reviews: * https://reviews.freebsd.org/D8364 - initial crypto offload for IV/MMIC stripping * https://reviews.freebsd.org/D8365 - IBSS HT awareness The crypto offload is only the initial work - there's some more work to do: * the input path needs to be taught that the ENCRYPTED RX flag is set by FC1_PROTECTED isn't - and that IVs, etc have been stripped * the decrypt modules need to handle key being NULL, so they can just check mbuf flags, etc * the output crypto path needs to be taught to not include CCMP/TKIP IVs. I don't know about WEP IVs yet. The IBSS 11n stuff works well enough in local tests. There are other crashes that happen that happen with normal non-11n - mostly around nodes disappearing/reappearing and states getting out of whack. The ieee80211_ht.c code is just in general missing locking. :( thanks, -adrian