Re: [REGRESSION][BISECTED][STABLE] MT7925: mDNS and IPv6 broken in kernel 6.14.3 and above

[Niklas Schnelle <niks@kernel.org>]

On Mon, 2025-05-05 at 05:48 +0000, Mingyen Hsieh (謝明諺) wrote:
> On Sun, 2025-05-04 at 00:39 +0200, Niklas Schnelle wrote:
> > 
> > External email : Please do not click links or open attachments until
> > you have verified the sender or the content.
> > 
> > 
> > On Wed, 2025-04-30 at 06:47 +0000, Mingyen Hsieh (謝明諺) wrote:
> > > On Wed, 2025-04-30 at 01:14 +0000, fossben@pm.me wrote:
> > > > 
> > > > External email : Please do not click links or open attachments
> > > > until
> > > > you have verified the sender or the content.
> > > > 
> > > > 
> > > > Hello all,
> > > > 
> > > > After upgrading to 6.14.3 on my PC with a MT7925 chip, I noticed
> > > > that
> > > > I could no longer ping *.local addresses provided by Avahi. In
> > > > addition, I also noticed that I was not able to get a DHCP IPv6
> > > > address from my router, no matter how many times I rebooted the
> > > > router or reconnected with NetworkManager.
> > > > 
> > > > Reverting to 6.14.2 fixes both mDNS and IPv6 addresses
> > > > immediately.
> > > > Going back to 6.14.3 immediately breaks mDNS again, but the IPv6
> > > > address will stay there for a while before disappearing later,
> > > > possibly because the DHCP lease expired? I am not sure exactly
> > > > when
> > > > it stops working.
> > > > 
> > > > I've done a kernel bisect between 6.14.2 and 6.14.3 and found the
> > > > offending commit that causes mDNS to fail:
> > > > 
> > > > commit 80007d3f92fd018d0a052a706400e976b36e3c87
> > > > Author: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
> > > > Date:   Tue Mar 4 16:08:50 2025 -0800
> > > > 
> > > >     wifi: mt76: mt7925: integrate *mlo_sta_cmd and *sta_cmd
> > > > 
> > > >     commit cb1353ef34735ec1e5d9efa1fe966f05ff1dc1e1 upstream.
> > > > 
> > > >     Integrate *mlo_sta_cmd and *sta_cmd for the MLO firmware.
> > > > 
> > > >     Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when
> > > > the
> > > > firmware supports it")
> > > > 
> > > >  drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 59 ++++-------
> > > > ----
> > > > --------------------------------------------
> > > >  1 file changed, 4 insertions(+), 55 deletions(-)
> > > > 
> > > > I do not know if this same commit is also causing the IPv6 issues
> > > > as
> > > > testing that requires quite a bit of time to reproduce. What I do
> > > > know with certainty as of this moment is that it definitely
> > > > breaks in
> > > > kernel 6.14.3.
> > > > 
> > > > I've attached my hardware info as well as dmesg logs from the
> > > > last
> > > > working kernel from the bisect and 6.14.4 which exhibits the
> > > > issue.
> > > > Please let me know if there's any other info you need.
> > > > 
> > > > Thanks!
> > > > Benjamin Xiao
> > > 
> > > Hi,
> > > 
> > > Thanks for reporting this issue, we will aim into this.
> > > 
> > > Can you provide me with your testing steps?
> > > 
> > > Best Regards,
> > > Yen.
> > > 
> > 
> > Hi Yan,
> > 
> > I see the same IPv6 issue on my Framework 13 (Ryzen 5 AI 340) with an
> > mt7925e WiFI module. My setup is just a home router with native IPv6
> > both for my uplink and in the LAN. The problems with IPv6 can already
> > be seen just in the LAN for example by checking which IP was used for
> > SSH, in my setup it should always be IPv6 but falls back to IPv4 in
> > the
> > broken state.
> > 
> > As another data point, I tried reverting cb1353ef3473 ("wifi: mt76:
> > mt7925: integrate *mlo_sta_cmd and *sta_cmd") on top of 6.15.-rc4.
> > This
> > fully restores IPv6 for me. Also note I'm running this with the
> > mt7925
> > firmware version 20250425073330 from linux-firmware's master branch
> > as
> > I had some dropped connections with earlier firmware.
> > 
> > So it definitely looks like that commit also broke IPv6 and not just
> > mDNS. Note that if if I use DHCPv6 instead of router advertisements,
> > on
> > the latest firmware, but without the revert, I get a global IPv6
> > address added to the interface but then native IPv6 addresses are
> > still
> > uncreachable. With the offending patch reverted my SSH session to an
> > IPv6 only host works fine and is stable. Also I'd be willing to test
> > a
> > proper fix as I rely on IPv6 heavily due to having to use CGNAT for
> > IPv4 but not for IPv6.
> > 
> > 
> > Thanks,
> > Niklas
> 
> Hi Benjamin & Niklas,
> 
> Can you help to try this patch? I can get IPv6 address through this
> patch.
> 
> If it can work at your environment as well, i will upstream it and add
> test tag with you.
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
> b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
> index a42b584634ab..fd756f0d18f8 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
> @@ -2183,14 +2183,14 @@ mt7925_mcu_sta_cmd(struct mt76_phy *phy,
>                         mt7925_mcu_sta_mld_tlv(skb, info->vif, info-
> > link_sta->sta);
>                         mt7925_mcu_sta_eht_mld_tlv(skb, info->vif,
> info->link_sta->sta);
>                 }
> -
> -               mt7925_mcu_sta_hdr_trans_tlv(skb, info->vif, info-
> > link_sta);
>         }
> 
>         if (!info->enable) {
>                 mt7925_mcu_sta_remove_tlv(skb);
>                 mt76_connac_mcu_add_tlv(skb, STA_REC_MLD_OFF,
>                                         sizeof(struct tlv));
> +       } else {
> +               mt7925_mcu_sta_hdr_trans_tlv(skb, info->vif, info-
> > link_sta);
>         }
> 
>         return mt76_mcu_skb_send_msg(dev, skb, info->cmd, true);
> 
> 
> Thanks~
> Yen.
> 

Hi Yen,

As the patch didn't apply, I edited mt7925_mcu_sta_cmd() manually on
top of v6.15-rc5 according to the diff. With that IPv6 works fine for
me.

If it were me, I'd probably structure the if different. I'd leave
the mt7925_mcu_sta_hdr_trans_tlv() where it is but have an inner if
(info->link_sta) inside just if (!info->enable), then the !info->enable
case becomes just an else. I'd maybe even put the if (info->link_sta)
body in its own static function if that makes sense semantically, but I
don't know enough (anything) about the driver to know. Anyway, that's
all a matter of taste and actually makes the patch quite a bit larger.

So whichever way you decide on feel free to add:

Tested-by: Niklas Schnelle <niks@kernel.org>

Thanks,
Niklas