I can’t comprehend this kind of bug existing since product release (effectively rendering it unusable) and not having a fix for it.
And we are not talking here that hhen you point Cube 60 down, there is big chance to get water inside and break the device.
Guys, does any one make a try on 7.6beta10 ?
Having this issue on a brand new deployment of CubeSA as ptmp access point for 6 stations. It’s 100% recreatable. If I run an internet speed test from any 60g station the CubeSA immediately drops and re-associates all stations, resulting in service disruption for all stations.
I’ve updated tonight to new 7.6rc1. Issue unaffected - still 100% reproducable. Going to tower tonight to take this hardware down and replace it. Sad. It’s really beautifully constructed. Had high hopes for it.
Only thing we found to prevent it was to go power down all but one station. When only one is connected it’s completely solved, reliably, over many tests. Reconnect the other stations again so it’s now having to do point to multipoint? 100% reproducable again.
Odd because on the previous series APx3 and even the original cubes upgraded to level 4 license to act as ptmp access point we can run huge loads with complete stability no problem.
Sent our support file into mikrotik. SUP-94299
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?
@mikrotik any news on this? Hook us up already? It’s been months without a solution on a new product that failed to work as advertised.
I have the same problem… When I try Btest between client and AP from client side… Recieve is OK… Send = link down… no data.. AP sometimes freeze, only power recycle helps. FW 7.6
But I see the problem.. The wireless Phy rate was >3Gbps ..then it’s always link down and up.. When we change direction, the quality drops under 2.5 Gbps… everything stable…
Can be the Phy rate set manually ?
Can they be downgraded to ROSv6? I havn’t tried the CubeSA yet, but found with other 60ghz mikrotik products that its quite stable with 6.49.6
Other things to think of…
/int w60g set 0 mgmt-fix=yes
Can try that on the AP, no idea if its supported with the CubeSA products. Not even entirely sure what it does, but noticed an improvement in stability on a wap60gx3
My guesstimate is it duplicates certain management traffic frames across all clients, as I noticed all clients have more traffic instead of all sitting idle except those that are actively transmitting
Get rid of the bonding interface? Try with just 60ghz
If that works it would be possible to use an isolated OSPF+BFD instance between AP and all SM’s for failover, instead of using bonding interface
Anyone get any luck on this front since @mikrotik says they can’t replicate the issue…
I have all this gear and can’t use it. My bosses are like WTF you going to do with all this gear…
If Mikrotik says it can’t replicate the issue then let’s see a youtube video from them on how to get it working - our engineers (who also happen to be 'tik instructors) have spent days trying to get it working without any luck.
Has anyone who opened a support ticket received any updates on this issue? It was pretty easy to replicate in a lab with 3 CubeSA 60Pros on 6.49.6. 1 in AP Bridge mode and the other 2 station bridges. Within 10-20 seconds after initiating a speed test from the AP to 1 of the stations, the other station drops for a few seconds then comes back up. I don’t have any bonding configured and 5 GHz interfaces are disabled. Also, set 0 mdmg-fix=yes did not make any difference.
I was hoping to use these in multipoint mode, but I guess I’ll have to come up with another plan. Glad I saw this before deploying.
I have several tickets open. From the beginning, Mikrotik trying to help - communication. Now silence and no solution. Same as here on the forum.
I don’t know why, but Mikrotik often chooses the tactic of silence 
I don’t know why, but it’s not good for this new products - could say “flagships”
@Mikrotik can you coment it?
I have the same problem. From 6.49.6 to 7.6. Twenty times every day. 1x CubeSA 60Pro ac + 5x Cube 60Pro ac…
This “flapping” happens not only with AY devices, AD devices also have such problem, but please read logs, drops are usually a second or less, you hardly mention that.
Don’t forget it’s not an TDMA protocol, it might have a hidden node problem, or other 802.11/FDMA issues
Also it may be an beam-forming problem. Client tries to find a better sector and looses connection. Set it manual maybe it will help
Mikrotik 60 Ghz devices are great
thank you guys
your Siberian fan
You can’t say they are great when they just flat out have problems
My biggest gripe is MikroTik has done NOTHING in actually educating the community on the ins and outs of their 60ghz products, nor how to use them properly
It’s frustrating because I know for a fact they can be made to work good, but you have to fight your way there. It took me a long time to finally understand the LHG60 products, now I finally know how to install and use them properly and exactly what is realistic and what isn’t. And am almost there with the Cube60 PTP setups
MikroTik could easily fill people in and bring them up to speed with a single wiki page, but they don’t. And every bit of information i’ve been given my MikroTik reps on this forum has been blatantly wrong, and i’ve proven them wrong (to which they just go silent). It’s frankly bullshit, makes it seem like they have absolutely NFI about their own product
Totally agree with that
We read on the forum that a lot of new Mikrotik product has problem flaghsip included, when it can’t be resolved they go silent!! I have several CCR2004 on the shelf
is problem solved @normis or sombody from mikrotik ?
All ARM devices have some problems.
Mipsbe,mmips,tile are better product and very stable