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-next>] [day] [month] [year] [list]
Date: Fri, 2 Jun 2023 14:03:59 +0200
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Andrey Rakhmatullin <wrar@...r.name>,
 Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: linux-wireless@...r.kernel.org, Neil Chen <yn.chen@...iatek.com>,
 Deren Wu <deren.wu@...iatek.com>, Lorenzo Bianconi <lorenzo@...nel.org>,
 Felix Fietkau <nbd@....name>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Kalle Valo <kvalo@...nel.org>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, netdev <netdev@...r.kernel.org>
Subject: Re: MT7922 problem with "fix rx filter incorrect by drv/fw
 inconsistent"

[CCing the wifi-driver and the net developers, as a "JFYI" to ensure
they are aware of this "newer kernel requires newer firmware"
regression, so they can jump in if they want]

On 22.05.23 16:12, Thorsten Leemhuis wrote:
> On 22.05.23 15:20, Andrey Rakhmatullin wrote:
>> On Mon, May 22, 2023 at 03:00:30PM +0200, Linux regression tracking #adding (Thorsten Leemhuis) wrote:
>>> On 18.05.23 16:39, Andrey Rakhmatullin wrote:
>>>> Hello. I have a "MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless
>>>> Network Adapter" (14c3:0616) and when the commit c222f77fd4 ("wifi: mt76:
>>>> mt7921: fix rx filter incorrect by drv/fw inconsistent") is applied (found
>>>> by bisecting, checked by reverting it on v6.3) I have the following
>>>> problem on my machine: when I connect to my router no DHCPv4 exchange
>>>> happens, I don't see responses in tcpdump. My network setup is non-trivial
>>>> though, and it looks like the problem is specific to it, but I still
>>>> wonder if it's some bug in the aforementioned patch as my setup works with
>>>> all other devices and I would expect it to work as long as the network
>>>> packets sent by the device are the same.
>>>>
>>>> My setup is as follows: I have an ISP router which provides a 2.4GHz
>>>> network and another router (Xiaomi R4AC with OpenWRT) connected by
>>>> Ethernet to it that provides a 5GHz network and is configured as a "Relay
>>>> bridge" (using relayd) to forward packets to the ISP router and back. This
>>>> includes DHCPv4 packets, which are handled by the ISP router. tcpdump on
>>>> the machine with MT7922 shows that the DHCP requests are sent while the
>>>> responses are not received, while tcpdump on the bridge router shows both
>>>> requests and responses.
>>>>
>>>> I've tried connecting the machine to the ISP router network directly and
>>>> also to another AP (one on my phone) and those work correctly on all
>>>> kernels.
>>
>> Deren Wu asked me privately
>> if I'm using the latest firmware, and I
>> wasn't. I updated the firmware and now the problem doesn't happen.
>> The firmware where the problem happens is
>> mediatek/WIFI_RAM_CODE_MT7922_1.bin from the linux-firmware commit
>> e2d11744ef (file size 826740, md5sum 8ff1bdc0f54f255bb2a1d6825781506b),
>> the one where the problem doesn't happen is from the commit 6569484e6b
>> (file size 827124, md5sum 14c08c8298b639ee52409b5e9711a083).
> 
> FWIW, just checked: that commit is from 2023-05-15, so quite recent.
> 
>> I haven't
>> tried the version committed between these ones.
>> Not sure if this should be reported to regzbot and if there are any
>> further actions needed by the kernel maintainers.
> 
> Well, to quote the first sentence from
> Documentation/driver-api/firmware/firmware-usage-guidelines.rst
> 
> ```Users switching to a newer kernel should *not* have to install newer
> firmware files to keep their hardware working.```
> 
> IOW: the problem you ran into should not happen. This afaics makes it a
> regression that needs to be addressed -- at least if it's something that
> is likely to hit others users as well. But I'd guess that's the case.

Well, until now I didn't see any other report about a problem like this.
Maybe things work better for others with that hardware – in that case it
might be something not worth making a fuzz about. But I'll wait another
week or two before I remove this from the tracking.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ