From owner-freebsd-wireless@freebsd.org Fri Jan 13 18:11:24 2017 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 2E134CAE928 for ; Fri, 13 Jan 2017 18:11:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 C559111C2 for ; Fri, 13 Jan 2017 18:11:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id r126so76169211wmr.0 for ; Fri, 13 Jan 2017 10:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=LjjZJ2hOYuklaobCmtCVdgcYj3NLCOOjTAvYkpIoxbk=; b=XYKG4rMqZwCetihvc/anxcJqIazriSx582haI/tVO3O4hSK5y5jjQIWLertpvbTrui 1vMxtCbv0o85eE+CUM/atvuSjJ+GRW5xXb7qb9v5WlSY4kiphaA9pI165ZIlCP87UFY1 5VKVln4Jkny74YWXzYOAemHlHWHNLWrApka+XdQJgMn/pvh4yAswUqcJPgfJ8eBrR8cr BNy0cK8uSbOuH9n15FIoNuKBOvEbIJPhLq7oh78lOiedbEpKnu+2LSkIOTr1JHXfeKkM PUMwT4fU18tCQ7eWji7CUthdbPk5+IuTOPiara7GBBD5UDAdGLElBXICB41YqEamF/hx djZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=LjjZJ2hOYuklaobCmtCVdgcYj3NLCOOjTAvYkpIoxbk=; b=cTwxBBFrxjicf9en2E4Oe+eS82JwlrK7KetwzaLAx4mjW3W9kmAxXf+4mTWYj8PorW zwv5HaELOgDJBOW1pOmdiwK6fAqOgi2Q56ka1FHhUiK4vkhzqzkbpok9+LnAnG9a25N0 f6F6ssyIl0J+KEM1UZdOJNblaDP8RdRlf7IFMeDGOiDZN+ukL2E74BBs2s63iF1VbpEV ebLIa4yYUp2SkudEvWkXLSZXZzQWPVmaeV1cXUNgLVW/jITLrBsuMOWzlGuMmhOiY+OL 8NWC3B7ojPjUNDT0x311FJ+GAnKymuQ3KXHAf+sM/WZczTz3WKKR0PVORiVbM7RxrD4+ Ao/Q== X-Gm-Message-State: AIkVDXKQ/W69CGDZ/mUQBqUM8M2RWgDR/6GBjLTA01KPG08HBa5aIOx98PJx7IM8PnssSVaxSWDCQn+H99DB2w== X-Received: by 10.223.151.205 with SMTP id t13mr13137975wrb.9.1484331081753; Fri, 13 Jan 2017 10:11:21 -0800 (PST) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.194.82.162 with HTTP; Fri, 13 Jan 2017 10:11:20 -0800 (PST) From: Adrian Chadd Date: Fri, 13 Jan 2017 10:11:20 -0800 X-Google-Sender-Auth: feKIu5UnOf5sljFOk3p9SEMSgvo Message-ID: Subject: first pass of VHT support has landed; next up is sequence number handling; rate control/station mode changes 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, 13 Jan 2017 18:11:24 -0000 hiya, I've just landed the first part of VHT support. It's enough for me to continue my ath10k driver port without maintaining thousands of lines of diffs in sys/net80211/ . Hopefully Andriy and I can continue chipping away at this whilst we add 11ac support to our drivers over the next little while. For everyone else this SHOULD be a glorified no-op. If something changes then please let me know, preferably via the mailing list. Next up - there are a few things in net80211 which need addressing as part of VHT support. * We need GCMP encryption for 11ac and protected management frames; i'll talk with andriy a bit more about that and general encryption key handling so we can figure out how to get that going. * I'd like to get protected management frames implemented this year in net80211. THat means peoplec an't just spoof disconnect/reauth/etc frames at you to disconnect you or get you to reassociate so they can crack your passphrase. * Sequence number handling - right now net80211 does it in most cases, and this is why there's the IEEE8021_TX_LOCK() / IEEE80211_TX_UNLOCK() around the encap-and-transmit-to-driver path. The drivers need to be queued frames that are both in the same sequence for allocated sequence numbers /and/ crypto sequence numbers that get assigned by a call to iee80211_crypto_encap(). Now, this is the tricky one, because I /think/ I also have to do the same for mesh sequence number allocation. I'll worry about improving mesh support later - right now the whole mesh gateway and sequence number handling is just plain broken. * Rate control and station notifications need to be addressed. Right now the only 11n notification is "channel width", which is done on the whole NIC rather than the node. Ideally it and a bunch of other notifications (like ERP changes) would be done like mac80211 does it - per node - with a channel change done if the NIC is software driven like ath(4). * Channel configuration - right now it's done globally, which doesn't really work well for the firmware NICs that can have per-VAP channel configuration with channel changes driven by the VAP. I'll have a think about this and maybe do something like mac80211 with it's per-VAP channel contexts. Ideally drivers would not at all ever check ic->ic_curchan and net80211 wouldn't set it for firmware NICs - instead, there'd be a per-VAP channel that's set up whenever things change, and the firmware would track that per VAP. * Rate control - right now the rate control API barely does 11n and needs to grow to do 11ac. I'll talk with Andriy about this a bit more again to get it more in shape for what the rtwn NICs need for 11ac. iwm will also need 11ac rate control as it's partially done in the driver/stack. (ath10k does rate control in firmware, so I have been able to completely ignore this piece.) Thanks for testing! -adrian