Re: [PATCH] rsi: Fix TX EAPOL packet handling against iwlwifi AP

From: Marek Vasut <marex@denx.de>
To: Martin Fuzzey <martin.fuzzey@flowbird.group>, netdev@vger.kernel.org
Cc: Angus Ainslie <angus@akkea.ca>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Kalle Valo <kvalo@codeaurora.org>,
	Lee Jones <lee.jones@linaro.org>,
	Martin Kepplinger <martink@posteo.de>,
	Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>,
	Siva Rebbagondla <siva8118@gmail.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH] rsi: Fix TX EAPOL packet handling against iwlwifi AP
Date: Thu, 27 May 2021 19:07:05 +0200	[thread overview]
Message-ID: <2550c80c-471b-4723-4061-a488b8b85fd8@denx.de> (raw)
In-Reply-To: <ba9013a8-38e4-f1ee-05a7-c3cf668bf449@flowbird.group>

On 5/27/21 6:52 PM, Martin Fuzzey wrote:
> Hi Marek,

Hi,

> I've just run into the same problem (on -5.4) and found your (now 
> merged) patch

The patch should already be part of 5.4.y, no ?

> On 15/10/2020 13:16, Marek Vasut wrote:
>> In case RSI9116 SDIO WiFi operates in STA mode against Intel 9260 in 
>> AP mode,
>> the association fails. The former is using wpa_supplicant during 
>> association,
>> the later is set up using hostapd:
>>
>> iwl$ cat hostapd.conf
>> interface=wlp1s0
>> ssid=test
>> country_code=DE
>> hw_mode=g
>> channel=1
>> wpa=2
>> wpa_passphrase=test
>> wpa_key_mgmt=WPA-PSK
>> iwl$ hostapd -d hostapd.conf
>>
>> rsi$ wpa_supplicant -i wlan0 -c <(wpa_passphrase test test)
>>
>> The problem is that the TX EAPOL data descriptor 
>> RSI_DESC_REQUIRE_CFM_TO_HOST
>> flag and extended descriptor EAPOL4_CONFIRM frame type are not set in 
>> case the
>> AP is iwlwifi, because in that case the TX EAPOL packet is 2 bytes 
>> shorter.
>>
>> The downstream vendor driver has this change in place already [1], 
>> however
>> there is no explanation for it, neither is there any commit history 
>> from which
>> such explanation could be obtained.
>>
> 
> I get this using 2 RSI9116 s, for both AP and STA using hostapd.

Do I understand it correctly that two RSI9116 did not even work against 
one another as STA and AP respectively ? Sigh ...

> Comparing packet captures in the working and non working (without your 
> patch) case shows that
> the working case has a 802.11 QOS header whereas the non working case 
> does not, hence the 2 byte difference.
> The size of the EAPOL data is the same, it's the previous header that 
> causes the problem...
> 
> This whole use the message size to determine the messages to ACK seems 
> very fragile...

I'm not surprised, the quality of this driver is low and the 
documentation is lacking. Thanks for clarifying.

Do you think you can write and submit a patch which would fix this in a 
better way?