Hello,

I recently purchased 2 cap ax to upgrade my cap ac/hap ac setup. First thing I noticed was that they weren't compatible with capsman - i had to install the new wifiwave2 package on my capsman.
Good thing is I have 2 chr instances that I use as capsman servers.
I resorted to using CHR because i need to forward the traffic through the capsman since i'm using stp in my network and roaming would fail otherwise.
Now that this is out of the way, I installed the wifiwave2 package on one of my CHRs, I made a test config on it, managed to get the cap ax to connect to it, but I couldn't get it to tunnel traffic.

Wifiwave2 capsman does not ( yet ?) support capsman forwarding.

Capsman2 doesn't support capsman forwarding ... yet. Why do you think that STP will break wireless client roaming?

Beat you by some seconds

Why do you think that STP will break wireless client roaming?

My 2 APs are in different switches. If i disabled STP roaming worked if I enabled STP it didn't. With tunneling worked regardless, since the client wouldn't hop switches.

Capsman2 doesn't support capsman forwarding ... yet.

Is there a public timeline for it getting supported?

There's a phenomenon which includes wifi station roaming and STP: namely wireless interface "running check" feature, configured by property "disable-running-check". If configuration property is set to "no" (default setting) and no wireless station is connected, then wireless interface becomes inactive. When a station connects, wireless interface transitions to active ... which in turn triggers bridge xSTP to verify for loops. This takes a few seconds and kills roaming performance.

Now, I don't know how to solve the problem with capsman, but with local wireless interfaces there are two possibilities:

1. set disable-running-check=yes on wireless interface
   In this case wireless interface will allways show as active bridge port and xSTP will not do the loop discovery after initial check (right after bridge gets populated with ports after reboot)
2. set wireless interface as bridge port with edge=yes
   This will tell xSTP that wireless "port" is an edge port and xSTP will not perform loop discovery ever (not even after reboot).

I used to have a small capsman setup to play with but I don't have it any more (due to mix of legacy/wave2 devices) so I can't check myself.

Capsman2 doesn't support capsman forwarding ... yet.

Is there a public timeline for it getting supported?

No. MT doesn't publish any timelines.

1. set disable-running-check=yes on wireless interface
   In this case wireless interface will allways show as active bridge port and xSTP will not do the loop discovery after initial check (right after bridge gets populated with ports after reboot)
2. set wireless interface as bridge port with edge=yes
   This will tell xSTP that wireless "port" is an edge port and xSTP will not perform loop discovery ever (not even after reboot).

I used to have a small capsman setup to play with but I don't have it any more (due to mix of legacy/wave2 devices) so I can't check myself.

i wasn't able to set disable-running-check=yes due to capsman, but capsman puts all wifi dynamic ports as edge - that should be enough right?

IMO that's a good news. It does take care of STP delays when wireless interface becomes active.

Personally I don't see any benefit in having running check enabled on wireless interfaces so I always disable it (did I mention I don't use capsman any more?). Probably I'm just having sort of a spot blindness

Capsman2 doesn't support capsman forwarding ... yet. Why do you think that STP will break wireless client roaming?

I know this is already some months old but it just dawned on me ...
What if we put an EOIP layer on top of the IP connection between CAP and CAPSMAN controller ?
Let the discovery run over that EOIP tunnel, all wireless traffic from Cap to Capsman via EOIP.

That's conceptually capsman forwarding minus encryption.

Hmmm ... I feel a test-project coming up for after when I'm back from holidays