From owner-freebsd-wireless@FreeBSD.ORG Sun Nov 18 20:52:57 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D6A9F33 for ; Sun, 18 Nov 2012 20:52:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2EBA58FC12 for ; Sun, 18 Nov 2012 20:52:56 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so3061307pab.13 for ; Sun, 18 Nov 2012 12:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=/eztKhV+RuWD/ktdUo6V+3mRYrLGF12tcxng/ihINqQ=; b=stSMEuLfqo0BxAtBUHv6H+2tgwUemHMtaNu5lBPiiEizhapVEr6IASKnHT8xSTpJdD u1+fld9N5LgZ+H//5Jw+dpAS8+XwlxA91lcj3OsBYYu16BZNbhWBtxwoKjkof9KW43GP 0rVH41G/fWT8Ecc3nmH+Ye7xhZ0GBp1QptPmI/A8SStYS4zUEalkK4Zk0q93L1cnyPd5 6bQsbXBBIEQu11AYyAwzYNXXGdVahkgfG0yzMutla2B91bNdBIvm//fNuZAlNgu/KUA8 kO25f9TvyvgMRL4X0QInIqHXmWRZP8DhUNU3HKtLkedsHRMEAZefZFabr4fQSCuFBX1r arRA== MIME-Version: 1.0 Received: by 10.68.251.197 with SMTP id zm5mr33292226pbc.30.1353271976496; Sun, 18 Nov 2012 12:52:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Sun, 18 Nov 2012 12:52:56 -0800 (PST) Date: Sun, 18 Nov 2012 12:52:56 -0800 X-Google-Sender-Auth: UrqNcQjSEnJTNwhDK1HneLF4hOo Message-ID: Subject: Fixing the encryption keycache handling for the AR5210, or "things I do to avoid going out.." From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Nov 2012 20:52:57 -0000 Hi, I noticed that the AR5210 NIC I have here wasn't associating to WPA networks. Now, the AR5210 only implements WEP (and clear!) so it should be punting the non-WEP frames to the net80211 stack for software encryption/decryption handling. However, it was erroring out. The net80211 stack was getting an error from the driver whenever it tried installing an encryption key via drv_key_set(). After hunting around a bit, I discovered: * There's a driver flag - sc_hasclrkey - which only gets used in some older code pathway; * net80211 directly calls a driver method to set an encryption key - and this calls ath_key_set(); * .. and ath_key_set() doesn't check whether sc_hasclrkey is 1 or not; it just quite happily tries to program in a CLR key to the AR5210; * .. then the AR5210 HAL keycache code would error out, as it only knows about WEP keys. After fixing that up, I discovered the hardware was returning invalid looking frames. Ie, they didn't at all match what was going on in the air. Then it dawned on me - since CCMP frames also have the WEP bit set in the header, the hardware was trying to decode them using the WEP keys! Once I disabled all of the hardware encryption/decryption handling, the AR5210 can now successfully associate to my 802.11n access points (protected, of course, with WPA2 + AES-CCMP.) Now, the hacky patch is here: http://people.freebsd.org/~adrian/ath/20121118-ar5210-hack-to-enable-non-wpa-crypt.diff I post this mostly so I don't forget (and I'll file a bug soon about it) - but the patch disables hardware encryption entirely on the AR5210. If you then try to use WEP, it'll assume the hardware encryption is enabled and it'll all quite happily fail. So if someone's after a bit of an introductory ath/hal project, I'd love to find a way to tidy this up and make it generic enough to enable hardware encryption for WEP, but disable hardware encryption (and do software encryption) for non-WEP. Even if that just ends up disabling hardware encryption for the AR5210, I could live with that. But there has to be a slightly cleaner way to do it. Adrian