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 (Thorsten Leemhuis) wrote:
> >> On 16.06.23 09:45, Nicolas Escande wrote:
> >> > On Thu Jun 15, 2023 at 2:54 PM CEST, Linux regression tracking (Thorsten 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 vendor AMSDU compat
> >> >>>>
> >> >>>> We upgraded our kernel from an older (5.15) to a newer 6.4. The problem is STP
> >> >>>> doesn't work anymore and alas we use it for now (for the better or 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 as 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 986e43b19ae9176093da35e0a844e65c8bf9ede7
> >> >>>> (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 someone should
> >> >>>> have seen it before (but I didn't find anything..) ? Maybe I missed something...
> >> >>>>
> >> >>>> Anyway I'm happy to provide more info or try anything you throw at me.
> >> >> [...]
> >> >> Hmmm, Felix did not reply. But let's ignore that for now.
> >> >
> >> > I haven't seen mails from felix on the list for a few days, I'm guessing 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 completely)
> >> fine for me if it is for you.
> > I'm not so surprised no one else reported it, using STP on wifi (and 802.11s) is
> > not a really common thing to do, to be honest (and STP on wifi is unreliable).
> > 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 patch on
> > top of 6.4. I'll do my best to try but from what I saw nothing got merged that
> > would even remotely help me on this issue.
> >
> > 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 += ETH_ALEN + 2;
> else if (!pskb_may_pull(skb, hdrlen))
> return -EINVAL;
> + else
> + payload.eth.h_proto = htons(skb->len - hdrlen);
>
> mesh_addr = skb->data + sizeof(payload.eth) + ETH_ALEN;
> switch (payload.flags & MESH_FLAGS_AE) {
Great, that does the trick for me
Thanks Felix
