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) {
