From patchwork Thu Jun 8 23:17:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ben Greear X-Patchwork-Id: 9776803 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 B3D88601C3 for ; Thu, 8 Jun 2017 23:17:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9D8E0285E7 for ; Thu, 8 Jun 2017 23:17:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8FCD6285E9; Thu, 8 Jun 2017 23:17:47 +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.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI 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 0B707285E7 for ; Thu, 8 Jun 2017 23:17:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751416AbdFHXRV (ORCPT ); Thu, 8 Jun 2017 19:17:21 -0400 Received: from mail2.candelatech.com ([208.74.158.173]:43542 "EHLO mail2.candelatech.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751132AbdFHXRU (ORCPT ); Thu, 8 Jun 2017 19:17:20 -0400 Received: from [192.168.100.149] (firewall.candelatech.com [50.251.239.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail2.candelatech.com (Postfix) with ESMTPSA id 38984409D92; Thu, 8 Jun 2017 16:17:19 -0700 (PDT) To: "linux-wireless@vger.kernel.org" , "hostap@lists.infradead.org" From: Ben Greear Subject: Question on setting key right after the EAPOL 4/4 is sent. Organization: Candela Technologies Message-ID: <4982156c-5325-8021-dcd3-f13e02c63c72@candelatech.com> Date: Thu, 8 Jun 2017 16:17:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 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 I believe I found a problem that may be larger than my little sandbox. The problem I see is that sometimes (and quite often when I am using lots of vdevs and thus the NIC is busy), the keys are set before the EAPOL 4/4 hits the air. When the key is set, the NIC will no longer transmit the frame because of key-length issues in the tx-descriptor (ath10k wave-2 in this case). If I add a sleep before setting the key, then it works much more reliably. I suspect that there is a fundamental race between the EAPOL packet-tx logic and the key-set logic, but supplicant appears to act as though they are natually synchronized. So, any suggestions on how to do this right? Thanks, Ben greearb@v-f24-64 hostap]$ git diff diff --git a/src/rsn_supp/wpa.c b/src/rsn_supp/wpa.c index 8a1d164..50a3006 100644 --- a/src/rsn_supp/wpa.c +++ b/src/rsn_supp/wpa.c @@ -1423,6 +1423,11 @@ static void wpa_supplicant_process_3_of_4(struct wpa_sm *sm, sm->renew_snonce = 1; if (key_info & WPA_KEY_INFO_INSTALL) { + /* Well now...what if the NIC hasn't actually put the 4/4 on the air + * yet? If we set the key too soon, it is liable to corrupt the pkt being + * sent.. I don't know a good fix, but here is a hack. + */ + os_sleep(0, 10000); /* sleep 10ms */ if (wpa_supplicant_install_ptk(sm, key)) goto failed; }