[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2550c80c-471b-4723-4061-a488b8b85fd8@denx.de>
Date: Thu, 27 May 2021 19:07:05 +0200
From: Marek Vasut <marex@...x.de>
To: Martin Fuzzey <martin.fuzzey@...wbird.group>,
netdev@...r.kernel.org
Cc: Angus Ainslie <angus@...ea.ca>,
"David S . Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Kalle Valo <kvalo@...eaurora.org>,
Lee Jones <lee.jones@...aro.org>,
Martin Kepplinger <martink@...teo.de>,
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@...i.sm>,
Siva Rebbagondla <siva8118@...il.com>,
linux-wireless@...r.kernel.org
Subject: Re: [PATCH] rsi: Fix TX EAPOL packet handling against iwlwifi AP
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?
Powered by blists - more mailing lists