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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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?