Outstanding issues for mesh support in wcn36xx

[Eugene Krasnikov]

> # Beacon support
>
> The wcn36xx driver does not send beacons in mesh mode (you've seen
> some patches for this already).  Currently, wcn36xx uses IBSS mode for
> the firmware, but this only allows the wcn36xx to work in a network
> where someone else is beaconing.
>
> We've sent some patches to resolve this, but there's some question
> about whether we're interacting with the firmware in the correct way.
> Specifically, we are using AP mode instead of IBSS, and we're forcing
> the firmware to write TIM IE information outside of the size of beacon
> packet (but within the limits of the "frame template").

I had a quick chat with Yanbo and it seems like mesh was never tested
with that FW. So i think we can have any mesh related workarounds in
driver we want.

>
> # Mesh rejoin / healing
>
> The wcn36xx driver fails to rejoin a mesh network after a loss of
> connectivity.  I plan to send patches with our work-around for
> comments.  The issue appears to be firmware related, because after a
> node "leaves" (that is, gets locked in an RF chamber) the firmware
> sends wcn36xx an "indication" that the STA has left.  This indication
> makes it look like the firmware and mac80211 are out of sync, because
> once the node rejoins, it is able to peer, but no traffic will be
> routed to the node.
>
> We worked around this by keeping a list of associated STAs in wcn36xx,
> and changing changing the "confis BSS" HAL command to use an action of
> "1", instead of "0" if the entry was already recorded by wcn36xx-- the
> action of "1" is supposed to mean "update the existing entry" instead
> of adding a new one-- this allows us to see traffic routed for the
> rejoined node (this workaround appears to unstable though, and
> sometimes does not work).

I would also recommend to check wcn->queues_stopped flag. Sometimes FW
just forgets to send and update about used dxe buffer that is leading
to data path stall
https://github.com/KrasnikovEugene/wcn36xx/blob/master/dxe.c#L603


> After creating a mesh interface for the *2nd* time, we see different
> rates reported through iw (via "station dump", rates seen when polling
> periodically never recover to rates seen on the first  interface).
> Initially it looked like it was always falling back to the lowest
> rate.  After recent changes it looks like it doesn't fall back to the
> lowest rates, but the 2nd interface does not use the same rates as the
> first interface.

Sounds like a bug in the driver to me that should not be that difficult to fix.

-- 
Best regards,
Eugene