Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7a3b6d5c-1d73-1d31-434f-00703c250dd6@denx.de>
Date:   Mon, 7 Nov 2022 14:23:37 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.1
Subject: Re: [PATCH v5] wifi: rsi: Fix handling of 802.3 EAPOL frames sent via
 control port
Content-Language: en-US
To:     Kalle Valo <kvalo@kernel.org>
Cc:     linux-wireless@vger.kernel.org,
        Amitkumar Karwar <amit.karwar@redpinesignals.com>,
        Angus Ainslie <angus@akkea.ca>,
        Jakub Kicinski <kuba@kernel.org>,
        Johannes Berg <johannes@sipsolutions.net>,
        Martin Fuzzey <martin.fuzzey@flowbird.group>,
        Martin Kepplinger <martink@posteo.de>,
        Prameela Rani Garnepudi <prameela.j04cs@gmail.com>,
        Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>,
        Siva Rebbagondla <siva8118@gmail.com>, netdev@vger.kernel.org
References: <20221104163339.227432-1-marex@denx.de>
 <87o7tjszyg.fsf@kernel.org>
From:   Marek Vasut <marex@denx.de>
In-Reply-To: <87o7tjszyg.fsf@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/7/22 13:37, Kalle Valo wrote:
> Marek Vasut <marex@denx.de> writes:
> 
>> When using wpa_supplicant v2.10, this driver is no longer able to
>> associate with any AP and fails in the EAPOL 4-way handshake while
>> sending the 2/4 message to the AP. The problem is not present in
>> wpa_supplicant v2.9 or older. The problem stems from HostAP commit
>> 144314eaa ("wpa_supplicant: Send EAPOL frames over nl80211 where available")
>> which changes the way EAPOL frames are sent, from them being send
>> at L2 frames to them being sent via nl80211 control port.
>>
>> An EAPOL frame sent as L2 frame is passed to the WiFi driver with
>> skb->protocol ETH_P_PAE, while EAPOL frame sent via nl80211 control
>> port has skb->protocol set to ETH_P_802_3 . The later happens in
>> ieee80211_tx_control_port(), where the EAPOL frame is encapsulated
>> into 802.3 frame.
>>
>> The rsi_91x driver handles ETH_P_PAE EAPOL frames as high-priority
>> frames and sends them via highest-priority transmit queue, while
>> the ETH_P_802_3 frames are sent as regular frames. The EAPOL 4-way
>> handshake frames must be sent as highest-priority, otherwise the
>> 4-way handshake times out.
>>
>> Therefore, to fix this problem, inspect the skb control flags and
>> if flag IEEE80211_TX_CTRL_PORT_CTRL_PROTO is set, assume this is
>> an EAPOL frame and transmit the frame via high-priority queue just
>> like other ETH_P_PAE frames.
>>
>> Fixes: 0eb42586cf87 ("rsi: data packet descriptor enhancements")
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> ---
>> NOTE: I am really unsure about the method of finding out the exact
>>        place of ethernet header in the encapsulated packet and then
>>        extracting the ethertype from it. Is there maybe some sort of
>>        helper function for that purpose ?
>> ---
>> V2: - Turn the duplicated code into common function
>> V3: - Simplify the TX EAPOL detection (Johannes)
>> V4: - Drop the double !!() from test
>>      - Update commit message
>> V5: - Inline the rsi_is_tx_eapol() again, undoes V2 change completely
> 
> BTW did you test this on a real device?

Yes, SDIO RS9116 on next-20221104 and 5.10.153 .

What prompts this question ?