Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
MIME-Version: 1.0
References: <CAAMvbhGsA4A9qHrYdXcNXLzv7a7xZZq98f90Q-Btb-9vs9ayCw@mail.gmail.com>
 <CAAMvbhHo8wo924YVZqFrLKQko59iSiLMhVAzb=tdSvf_-v1CCQ@mail.gmail.com> <acdb4315780bde3481c44ba90fe341fea75a2929.camel@sipsolutions.net>
In-Reply-To: <acdb4315780bde3481c44ba90fe341fea75a2929.camel@sipsolutions.net>
From:   James Dutton <james.dutton@gmail.com>
Date:   Tue, 10 Oct 2023 21:42:07 +0100
Message-ID: <CAAMvbhHoAgqhCJhHfBLtO0q-E9GvN=-+pix8O93N=rCZ60c41g@mail.gmail.com>
Subject: Re: mac80211 bugs
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, 10 Oct 2023 at 15:22, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Mon, 2023-10-09 at 16:56 +0100, James Dutton wrote:
> >
> > Looking at this, it can be one of two things:
> > 1) local->hw.wiphy->bands[band];    is NULL
>
> Yes, I think that's it.
>
> > 2) bands is an array of 6 items, making band valid for values 0-5.
> > If band >= 6, it would cause problems.
>
> Highly unlikely.
>
[snip]
>
> _Maybe_ change it to WARN_ON_ONCE(!sband || !sband->bitrates) there, but
> really I think we should prevent this in the first place.
>
>
> Is this, by any chance, a device without 2.4 GHz?
>

Hi,
I have the same device that is reported to be crashing. My device does
not actually crash, so I personally have not seen the problem.
My device is what I would call unstable (not crashing, just not
forwarding packets) though. My work around is to switch on/off
airplane mode on the client, and it continues forwarding packets
again. Some of the wifi device drivers have some not very portable use
of bit fields that looks suspicious to me, but again no proof yet of
what causes my stability problems. It is why a lot of access to bit
fields in the kernel correctly uses portable accessors like
STA_STATS_GET() and friends.

I have seen this though:
https://github.com/openwrt/openwrt/issues/13198
Which has reports of a few other people seeing the crash.
The device has both 2.4 and 5G wifi.
From what I can see, the band information originates from what the
wifi card received over the RF.
So, theoretically, it might be caused by a bogus wifi packet being received.
I agree that it is unlikely for "band" to get to 6 or above, but until
one of the users who are seeing the problem runs a kernel with the
extra printk or WARN statements in it, I don't think we are going to
know the cause for certain.
I think it prudent to put the if statements in to catch both edge cases.