Not directly related to your problem:
I see that your config includes bonding of the 60G interface itself, I didn't know I could do it that way?
In the default setup for the preconfigured Cube 60 kit the station interface is included as both primary and slave in the bonding.
As station interfaces are added dynamically as new clients connect, I thought I could not use bonding, and resorted to an RSTP bridge on both sides instead.
I guess detecting broken 60G on the client side is easy for the bonding, but with this way of doing it, what will make the AP side switch to 5G? One client disappearing does not necessary mean that they all leave?
Gave your way of doing it a try now.
Appears to me that all the failover functionality is taken care of by the client side; when disabling the 60G-interface on either side, the client side bonding instantly switches 5G to active port and 60G to inactive, when re-enabling 60G it switches back.
On the AP side the 60G interface is permanently rendered as inactive port and 5G as active, it does not react to the 60G being disabled or enabled.
Disabling 5G however makes it swap active and inactive ports, but that does not do anything to the client side, which is happy with its 60G connection...
For the time being I have not yet tested with serveral clients using this setup.
But my question is:
In a PtMP setup, what is the advantage of using bonding in favour of RSTP bridges?