Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date:   Tue, 11 Jul 2023 14:15:22 +0200
Message-Id: <CTZC2XSCQF47.3QPNI1G4AXJLX@syracuse>
Cc:     <linux-wireless@vger.kernel.org>
Subject: Re: [regression] STP on 80211s is broken in 6.4-rc4
From:   "Nicolas Escande" <nico.escande@gmail.com>
To:     "Felix Fietkau" <nbd@nbd.name>,
        "Linux regressions mailing list" <regressions@lists.linux.dev>,
        "Bagas Sanjaya" <bagasdotme@gmail.com>,
        =?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>,
        "Kalle Valo" <kvalo@kernel.org>,
        "Johannes Berg" <johannes.berg@intel.com>
References: <CT5GNZSK28AI.2K6M69OXM9RW5@syracuse>
 <ZIQbs0wqdRh7c0Kx@debian.me>
 <a9d02800-2cd6-a27b-7998-4c97cf2eb692@leemhuis.info>
 <CTDWJJDKSYYD.XBG1CAZB3A5W@syracuse>
 <809500b6-4eec-7a5e-5930-00e7eeebcc5e@leemhuis.info>
 <CTYNAK10A6AJ.1I4W9V78VG1NB@syracuse>
 <4bb71d8a-daf1-5f60-daf0-44aa8afcfdc3@nbd.name>
In-Reply-To: <4bb71d8a-daf1-5f60-daf0-44aa8afcfdc3@nbd.name>
Precedence: bulk

On Tue Jul 11, 2023 at 1:12 PM CEST, Felix Fietkau wrote:
> On 10.07.23 18:50, Nicolas Escande wrote:
> > On Mon Jul 10, 2023 at 1:32 PM CEST, Linux regression tracking (Thorste=
n Leemhuis) wrote:
> >> On 16.06.23 09:45, Nicolas Escande wrote:
> >> > On Thu Jun 15, 2023 at 2:54 PM CEST, Linux regression tracking (Thor=
sten Leemhuis) wrote:
> >> >> On 10.06.23 08:44, Bagas Sanjaya wrote:
> >> >>> On Tue, Jun 06, 2023 at 12:55:57PM +0200, Nicolas Escande wrote:
> >> >>>>
> >> >>>> As user of the mesh part of mac80211 on multiple products at work=
 let me say
> >> >>>> thank you for all the work you do on wifi, especially on 80211s, =
and especially
> >> >>>> the recent improvements you made for mesh fast RX/TX & cross vend=
or AMSDU compat
> >> >>>>
> >> >>>> We upgraded our kernel from an older (5.15) to a newer 6.4. The p=
roblem is STP=20
> >> >>>> doesn't work anymore and alas we use it for now (for the better o=
r worse).
> >> >>>>
> >> >>>> What I gathered so far from my setup:
> >> >>>>  - we use ath9k & ath10k
> >> >>>>  - in my case STP frames are received as regular packet and not a=
s amsdu
> >> >>>>  - the received packets have a wrong length of 44 in tcpdump
> >> >>>>    (instead of 38 with our previous kernel)
> >> >>>>  - llc_fixup_skb() tries to pull some 41 bytes out of a 35 bytes =
packet
> >> >>>>    this makes llc_rcv() discard the frames & breaks STP
> >> >>>>
> >> >>>> >From bisecting the culprit seems to be 986e43b19ae9176093da35e0a=
844e65c8bf9ede7
> >> >>>> (wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces)
> >> >>>>
> >> >>>> I guess that your changes to handle both ampdu subframes & normal=
 frames in the
> >> >>>> same datapath ends up putting a wrong skb->len for STP (multicast=
) frames ?
> >> >>>> Honestly I don't understand enough of the 80211 internals & spec =
to pinpoint the
> >> >>>> exact problem.
> >> >>>>
> >> >>>> It seems this change was already in the 6.3 kernel so I guess som=
eone should
> >> >>>> have seen it before (but I didn't find anything..) ? Maybe I miss=
ed something...
> >> >>>>
> >> >>>> Anyway I'm happy to provide more info or try anything you throw a=
t me.
> >> >> [...]
> >> >> Hmmm, Felix did not reply. But let's ignore that for now.
> >> >=20
> >> > I haven't seen mails from felix on the list for a few days, I'm gues=
sing he's
> >> > unavailable for now but I'll hapilly wait.
> >>
> >> Still no progress. Hmmm. Are you still okay with that? I've seen no
> >> other reports about this, so waiting is somewhat (albeit not completel=
y)
> >> fine for me if it is for you.
> > I'm not so surprised no one else reported it, using STP on wifi (and 80=
2.11s) is
> > not a really common thing to do, to be honest (and STP on wifi is unrel=
iable).
> > Even though some openwrt guys do it for sure, I'm guessing their kernel=
 version
> > is lagging behind...
> >>
> >> But in any case it might be good if you could recheck 6.5-rc1.
> > Testing on 6.5 as a whole won't be as easy for me as testing a single p=
atch on
> > top of 6.4. I'll do my best to try but from what I saw nothing got merg=
ed that
> > would even remotely help me on this issue.
> >=20
> > I am not loosing hope that Felix or someone that understands this stuff=
 better
> > finds the time to look into this. I'm guessing it's the summer vacation=
 effet.
>
> Sorry for the delay. This should fix the regression, please test.
> I will submit it for 6.5 soon.
> ---
> --- a/net/wireless/util.c
> +++ b/net/wireless/util.c
> @@ -580,6 +580,8 @@ int ieee80211_strip_8023_mesh_hdr(struct
>   		hdrlen +=3D ETH_ALEN + 2;
>   	else if (!pskb_may_pull(skb, hdrlen))
>   		return -EINVAL;
> +	else
> +		payload.eth.h_proto =3D htons(skb->len - hdrlen);
>
>   	mesh_addr =3D skb->data + sizeof(payload.eth) + ETH_ALEN;
>   	switch (payload.flags & MESH_FLAGS_AE) {

Great, that does the trick for me
Thanks Felix