On Sun, 21 Sept 2025 at 01:29, Gleb Smirnoff <gleb...@freebsd.org> wrote:
> Hi, > > On Sat, Sep 20, 2025 at 12:47:38AM +0000, Adrian Chadd wrote: > A> commit 785edcc2af5ae32c24f5caf5b9552f62bdae33ee > A> Author: Adrian Chadd <adr...@freebsd.org> > A> AuthorDate: 2025-06-10 04:22:10 +0000 > A> Commit: Adrian Chadd <adr...@freebsd.org> > A> CommitDate: 2025-09-20 00:42:45 +0000 > A> > A> net80211: convert the rest of the native net80211 drivers to > SEQNO_OFFLOAD > A> > A> * Convert the rest of the drivers to implement driver/offloaded > sequence > A> number handling. > A> > A> * For drivers that implement their own sequence number space > handling > A> for A-MPDU, only call ieee80211_output_seqno_assign() if the frame > A> isn't tagged with M_AMPDU_MPDU, which mirrors the original > net80211 > A> sequence number behaviour. (Except of course, the assignment is > A> now happening during final encap/transmit, not early in encap.) > A> > A> Locally tested (sta mode): > A> > A> * ath > A> * iwn > A> * bwi > A> * bwn > A> * iwm > A> * otus > A> * ral > A> > A> Differential Revision: https://reviews.freebsd.org/D50772 > A> Okayed by: bz > > This commit broke my iwm(4) on Thinkpad X1 Carbon 7th Gen. > > The symptoms are that the interface can associate and even receive DHCP > address, but after that all transmitted packets are lost. Any > communication > attempt results in ARP requests that are not seen by other devices on the > network. Reverting this commit resolves the problem. > > I will be able to test patches tomorrow, please send them to me. > > If we are not able to resolve that before start of the stabweek which is > this > Monday, I'd like to get this reverted from main. > Yup, I figured it out pretty quickly after it was first reported. See: https://reviews.freebsd.org/D52652 It looks like different generations of firmware/chipsets have different expectations for sequence numbers being present. I'm going to land this once kevans (and/or you?) test it out and OK it. Sorry! -a > > -- > Gleb Smirnoff >
