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, 06 Jun 2023 12:55:57 +0200
Cc:     <linux-wireless@vger.kernel.org>
Subject: [regression] STP on 80211s is broken in 6.4-rc4
From:   "Nicolas Escande" <nico.escande@gmail.com>
To:     <nbd@nbd.name>
Message-Id: <CT5GNZSK28AI.2K6M69OXM9RW5@syracuse>
Precedence: bulk

Hello Felix,

As user of the mesh part of mac80211 on multiple products at work let me sa=
y
thank you for all the work you do on wifi, especially on 80211s, and especi=
ally
the recent improvements you made for mesh fast RX/TX & cross vendor AMSDU c=
ompat

We upgraded our kernel from an older (5.15) to a newer 6.4. The problem is =
STP=20
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 986e43b19ae9176093da35e0a844e65c8bf9=
ede7
(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 pinpoin=
t the
exact problem.

It seems this change was already in the 6.3 kernel so I guess someone shoul=
d
have seen it before (but I didn't find anything..) ? Maybe I missed somethi=
ng...

Anyway I'm happy to provide more info or try anything you throw at me.

Thanks,

---
Nicolas E.