Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 04/11] wil6210: fix PTK re-key race
To:     Denis Kenzior <denkenz@gmail.com>,
        Arend Van Spriel <arend.vanspriel@broadcom.com>,
        Kalle Valo <kvalo@codeaurora.org>,
        Maya Erez <merez@codeaurora.org>
Cc:     Ahmad Masri <amasri@codeaurora.org>,
        linux-wireless@vger.kernel.org, wil6210@qti.qualcomm.com
References: <1567931575-27984-5-git-send-email-merez@codeaurora.org>
 <20190910132315.D7AC7602F2@smtp.codeaurora.org>
 <7b636313-fa4a-5ee4-935a-ba2ed5dde1e5@wetzel-home.de>
 <2c6bc637-62c2-020c-ab83-d2e1677d96b2@gmail.com>
 <5716f475-856e-7fd2-637b-67927f4f78bc@wetzel-home.de>
 <74c0e328-320c-0999-836e-1bfb0fa224ff@broadcom.com>
 <13f699ef-16c2-3ba7-79a0-0934f5e39368@gmail.com>
From:   Alexander Wetzel <alexander@wetzel-home.de>
Message-ID: <46f1141c-929c-9686-017d-fe4305d9c922@wetzel-home.de>
Date:   Fri, 13 Sep 2019 22:48:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.0
MIME-Version: 1.0
In-Reply-To: <13f699ef-16c2-3ba7-79a0-0934f5e39368@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Am 13.09.19 um 16:33 schrieb Denis Kenzior:
> Hi Arend, Alexander,
> 
>> Basically, we now have two bypass methods dealing with the 
>> same/similar issue:
>>
>> 1) bypass the QDISC.
>> 2) bypass network stack entirely with CONTROL_PORT.
> 
> It also raises the question in my mind as to why we have two ways of 
> doing the same thing?  From the discussion so far it also sounds like 
> each requires somewhat different / special handling in the driver. 
> Wouldn't it make sense to deprecate one and encourage drivers to 
> implement the other?
> 

My understanding is, that any control port frame must bypass any queues 
and just send out the frame directly, correct? Any packets send via it 
is directly jumping to the very front and is immediately send out.
And that the intend of it is to replace the "old" path.

So the best way forward here would be to

1) implement the patch here to work around the problem without 
control_port or the theoretical QDISC bypass
2) start implementing control port for the future.

correct?


> CONTROL_PORT was added specifically to take care of the re-keying races 
> and can be extended with additional attributes over time, as needed 
> (perhaps for extended key id, etc).  Also note that in our testing 
> CONTROL_PORT is _way_ faster than PAE socket...
> 

Extended Key ID is pretty robust when rekeying and the driver/card only 
has to take care to not mix KeyIDs within one A-MPDU. It's no problem 
encrypting eapol#4 with the new key. You can even encrypt it at the 
initial connect and it will work. Basically all races the "classical" 
rekey has to work around go away.

For "normal" rekeys it's working pretty well with ath9k and iwlwifi even 
without control_port and just learned some weeks ago that QDISC could 
still cause issues...

Alexander