On Tuesday, November 5, 2024 2:02:31 PM CET Toke Høiland-Jørgensen wrote:
> Issam Hamdi <ih@xxxxxxxxxxxxxxxxxx> writes:
> > From: Simon Wunderlich <simon.wunderlich@xxxxxxxxxxxxx>
> >
> > The chip is switching seemingly random into a state which can be described
> > as "deaf". No or nearly no interrupts are generated anymore for incoming
> > packets. Existing links either break down after a while and new links will
> > not be established.
> >
> > The driver doesn't know if there is no other device available or if it
> > ended up in an "deaf" state. Resetting the chip proactively avoids
> > permanent problems in case the chip really was in its "deaf" state but
> > maybe causes unnecessary resets in case it wasn't "deaf".
>
> Proactively resetting the device if there is no traffic on the network
> for four seconds seems like a tad aggressive. Do you have any
> information on under which conditions this actually happens in practice?
> I assume this is a patch that has been lying around in openwrt for a
> while, or something?
Hi Toke,
this patch has been around for a long time (8 years or so?), and it has been
integrated in various vendor firmwares (at least three I know of) as well as
mesh community firmwares [1]. The circumstances leading to this "deafness" is
still unclear, but we see that some particular chips (especially 2-stream 11n
SoCs, but also others) can go 'deaf' when running AP or mesh (or both) after
some time. It's probably a hardware issue, and doing a channel scan to trigger
a chip reset (which one normally can't do on an AP interface) recovers the
hardware. This patch provides a workaround within the kernel.
We submitted it only as RFC back then [2], and since we had colleagues
suffering the same problem again we though we give it another shot to finally
get it integrated upstream. :)
The idea is that if the radio is idle anyway, a quick reset (which takes a few
tens of ms maximum) doesn't hurt much, and it helps to recover non-functional
APs or mesh points.
Cheers,
Simon
[1] https://github.com/freifunk-gluon/gluon/pull/2114
[2] https://patchwork.kernel.org/project/linux-wireless/patch/
20161117083614.19188-2-sven.eckelmann@xxxxxxxxxxxxx/Attachment:
signature.asc
Description: This is a digitally signed message part.
