Outstanding issues for mesh support in wcn36xx

[Jason Mobarak]

Hello --

I'd like to update the wcn36xx team on the issues we've seen on mesh support:

# 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").

# 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).

It's strange that changing the flavor of "config BSS" from "add" to
"update" works at all, since the firmware told us earlier that the STA
was deleted/leaving.

However, we saw (with our work-around), that when we deleted the first
mesh interface, then created a second interface, the second interface
(which only used basic rates) would not have the traffic routing issue
after rejoin.  This is similar scenario to an earlier work around we
tried, where we forced the rejoined node to use only basic rates by
setting the STA index to the bss index.

# 2nd interface created is different than first

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.

Thanks,
-Jason M