We have a new setup of about 15 CubeSA 60Pro AC access points with Cube 60Pro AC client radios and since we installed them, we're getting frequent drops on all 60Ghz clients. We have a simple setup with bonding (for 5Ghz failover) and can't see why this is happening. Any suggestions on where to look? Both AP and CPE are running 7.4.1.

I've tried turning on wireless / info or debug in the logs and aren't getting anything. The client signal strenghts are in the 80's and 90's with an MCS of 8.

AP 60ghz config: Client 60ghz config:
I mean, it's all pretty vanilla.

We have the same problem in multiple places. So problem is in RouterOS. We wait for fix....

We are looking into increasing our vertical separation on several of our APs. What distance are your APs from each other? Ours are about 10" away from each other vertically. We are also considering adding some EM shields on the backs... if that could help.

The problem is not caused by interference. It also happens to us in places where is 1x AP

The same is happening with old 802.11AD devices I think its a driver issue

I met this problem also , Both AP and client running 6.49.6，I saw large amount of IRQ related with ether net interface. Hope this will be useful to solve this.

We have a new setup of about 15 CubeSA 60Pro AC access points with Cube 60Pro AC client radios and since we installed them, we're getting frequent drops on all 60Ghz clients. We have a simple setup with bonding (for 5Ghz failover) and can't see why this is happening. Any suggestions on where to look? Both AP and CPE are running 7.4.1.

I've tried turning on wireless / info or debug in the logs and aren't getting anything. The client signal strenghts are in the 80's and 90's with an MCS of 8.

AP 60ghz config:

Code: Select all

/interface w60g set [ find ] disabled=no frequency=66960 isolate-stations=no name=AP-60Ghz put-stations-in-bridge=bridge region=usa ssid=myap
/interface bonding add mode=active-backup name=bond1 primary=AP-60Ghz slaves=AP-60Ghz,AP-5Ghz 

Client 60ghz config:

Code: Select all

/interface w60g set [ find ] disabled=no mode=station-bridge name=wlan60 put-stations-in-bridge=bridge region=usa scan-list=58320,60480,62640,64800,66000,66960 ssid=myap
/interface bonding add mode=active-backup name=bond1 primary=wlan60 slaves=wlan60,wlan1

I mean, it's all pretty vanilla.

20220820 12_45_09.png

20220820 12_44_25.png

Same exact setup and hardware. Same issue

The same problem with 7.5rc1. Mikrotik are you working on it?

Any update on this @Mikrotik? I have purchased quite a bit of these and they are currently useless. @normis

We deployed 2 sectors and 12 Cube60Pro AC's at a fairground for a recent event and had nothing but problems. I ended up having to disable 60Ghz entirely to get them working, and nearly lost the contract for the event while it was going on.

Mikrotik, let's get an answer on this please before I end up returning the entire lot to our distributor.

It seems like it only happens when you pair the CubeSA 60Pro with the multiple Cube 60Pro.

I have swapped out the Cube 60Pro with wAP60 and paired those with CubeSA 60Pro work fine.

I also swapped out the CubeSA 60Pro with wAP 60Gx3 AP and paired those with multiple Cube 60Pro and that worked fine.

I hope there is an update soon...

Have any of you filed support tickets with MikroTik? They often fail to notice posts like this.

The way to get MikroTik to look at an issue is to file a support request with support@mikrotik.com

Guys
802.11 AD and AY are not TDMA protocols. Maybe thats why it flaps...
a hidden node

Yes. Reported 12/Jul/22 to support. SUP-86857
No sollution yet

Only TCP Stream pass through AP Bridge Ether1 interface can cause this

Yup. SUP-91227

Client's Up&Down are closely related with Ether interface's IRQ , and It seemed that there is no IRQ load Balance ， CPU#0 will response All those IRQ, then, CPU #0 reached 100% usage, then, flapping occurred. and I think IRQ Load Balance and IRQ Merge will reduce flapping.
And I also feel puzzled abut why not Ethernet hardware forwarding does not work.

Any update on this? Support sent me an alpha build to test, but it didnt work. Same issue....

Any update on this? Support sent me an alpha build to test, but it didnt work. Same issue....

I can confirm. I'm also testing alpha and it didn't help

@mikrotik.com Any update on this?

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

AP 60ghz config:

Code: Select all

/interface w60g set [ find ] disabled=no frequency=66960 isolate-stations=no name=AP-60Ghz put-stations-in-bridge=bridge region=usa ssid=myap
/interface bonding add mode=active-backup name=bond1 primary=AP-60Ghz slaves=AP-60Ghz,AP-5Ghz 

Client 60ghz config:

Code: Select all

/interface w60g set [ find ] disabled=no mode=station-bridge name=wlan60 put-stations-in-bridge=bridge region=usa scan-list=58320,60480,62640,64800,66000,66960 ssid=myap
/interface bonding add mode=active-backup name=bond1 primary=wlan60 slaves=wlan60,wlan1

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?

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

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

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

Totally agree with that

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

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

is problem solved @normis or sombody from mikrotik ?
All ARM devices have some problems.
Mipsbe,mmips,tile are better product and very stable

ALL 60 GHz devices have this problem. It is not an ARM-thing

Does that issue trigger 5GHz failover and is able to soften the blow?

AP 7.7, clients 7.7 and problem is still here. Does anyone have a solution?

Does that issue trigger 5GHz failover and is able to soften the blow?

Dropout is from 1 to 5 seconds 20-30 times a day regardless of configuration and system version, even without bonding, 60GHz only. 5 clients Cube60 Pro ac. Clients distance between 50-70 meters.

ALL 60 GHz devices have this problem. It is not an ARM-thing

I can only speak for a pair of Cube 60G ac we use, but they run pretty stable, just upgraded them to 7.7 a few days ago.

The problem also occurs with the latest 7.8beta. So it's not fixed yet.
Mikrotik has a ticket with a video on how to simulate the problem. So I hope it will be fixed soon

ALL 60 GHz devices have this problem. It is not an ARM-thing

I can only speak for a pair of Cube 60G ac we use, but they run pretty stable, just upgraded them to 7.7 a few days ago.
2023-01-16 at 21.21.13.png

It seems to happen when you have 2+ clients on a cube. I just had an AP + 1 client where it never happened, then as soon as I added a second client, it all started again. These are all on 7.7.

Earlier a few people said "all 60GHz products".

I have roughly 150 or so 802.11ad radios on the air and they have been solid since 6.48.6 and all 6.49 releases. I have zero Cube60 SA's; my AP's are all wAP 60's or Cube60's. All the 802.11ad radios work fine as CPE, and I have roughly 10 Cube 60 Pro's (802.11ay) as CPE too, with no complaints.

It would appear the common thread for those with problems are the 802.11ay Cube 60 SA AP's.

Hi,

what clients do you have on 10 Cube 60 Pro's? Only AY or even AD?

It doesn't matter what clients you use. We have a sector where there are only AD clients and it disconnects them. Then we have another sector where there are only AY clients and it disconnects them. As mentioned above - a common problem is CubePro-SA

Latest 7.8rc1 on Cube-SA and also 7.8rc1 on all clients. Problem is still there. Reported several times to support.
@mikrotik.com Are you working on a repair or should we choose another 60Ghz multipoint manufacturer?

sucks, i bought a bunch of these in September.... can't even use them.

Are you working on a repair or should we choose another 60Ghz multipoint manufacturer?

What manufacture at that cost? Do not use Cube-SA as it's mentioned above.

Do not use Cube-SA as it's mentioned above.

WAP60G also does not understand with CubePRO clients. So what to use as a sector?

What manufacture at that cost? Do not use Cube-SA as it's mentioned above.

Not in this price range, but at least it will work.

Do not use Cube-SA as it's mentioned above.

WAP60G also does not understand with CubePRO clients. So what to use as a sector?

What manufacture at that cost? Do not use Cube-SA as it's mentioned above.

Not in this price range, but at least it will work.

sirbryan says that WAP60G works fine with cube pro
Or try using Cube pro as an AP

We're seeing the exact same thing with all 60ghz mikrotik products. hot garbage, do not buy, return if you can. No reply what so ever from Mikrotik with issues.

We're seeing the exact same thing with all 60ghz mikrotik products. hot garbage, do not buy, return if you can. No reply what so ever from Mikrotik with issues.

we are seeing that 60GHz is great

We're seeing the exact same thing with all 60ghz mikrotik products. hot garbage, do not buy, return if you can. No reply what so ever from Mikrotik with issues.

Rubbish, in multipoint they are a bit meh but in point-to-point setups they are AWESOME. Just cannot be beaten for anywhere close to the money, stupid performance, seemingly little to no impact from having multiple products on the exact same frequency on the same pole, the gigabit port is the limiting factor

Just have to dial the expectations back, sub 1km for heavy rain (will still drop briefly as it hits), sub 700m if you don't want any downtime at all. Mount them rigidly not on a flimsy TV antenna

Multipoint works, but set the expectation of speeds you'd otherwise never see at the price of the occasional drop-out. Keep your distances under 350m, ideally under 200m

I try 7.8 and the problem is still there. (1x AP Pro and 2x AD client or 1x AP Pro and 1x AD and 1x Pro client)
I observed that when the traffic on the clients is below 200M, it does not happen, or only at a minimum.
Once the traffic exceeds 250M, it starts to drop in a big way.

Is anyone from Mikorotik working on a solution?

Thanx

Yes. With 7.8 the same problem. No solution.

What's worse, support stopped answering questions. https://mikrotik.com/support.

I described a way how to simulate the problem. No reaction, no response from support.
I really do not know

A strange thing happened to me.
I tried to turn on "Isolate stations" on the AP (CubeSA Pro) and this stopped happening with high traffic.
Then I turned off "Isolate stations" again and it still doesn't happen.
So far, I have tried it on a test in the lab and on one operating transmitter.
Can anyone else try this? Maybe it's a coincidence.
Thanx

What is working for me:

As AP's:
- wAP 60
- wAP 60 180
- Cube 60G

At close range, despite their 60° pattern, wAP 60's mounted to a round mast almost act like they have a 180° pattern. I have one customer with a Cube 60 90° to the side of the wAP 60 at 200m and it's working great.

On the flip side, wAP 60 180's do not work with metal behind them. The two I have in production are mounted to plastic masts or have the top 1.5" (30mm) of the radio extended above the mast.

Cube 60 G's and Cube Pro's are a good option as AP if you want more range and a narrower sector.

I do not have any Cube SA's.

As CPE:
- wAP 60 (≤180m)
- Cube Lite (≤400m)
- Cube 60 G (≤400m)
- Cube Pro (≤400m)
- LHG 60 Light (≤700m)
- LHG 60 G (≤700m)

Settings on AP:
- Every AP on its own frequency; also ensure backhauls are on different channels
- All radios in the parent bridge
- Enable client Isolation
- It's simpler to manage VLAN filtering at the CPE than it is on the AP

I limit it to at three AP's per site (mast); with some shielding, you could probably get some ABC/ABC/ABC reuse around a larger installation. I also use AF60/AF60LR/AF60XR for backhaul as much as possible, with 65880-68040 for backhaul and 58320-64800 for serving customers.

An OmniTik PoE AC is both an excellent POE switch for the AP's as well as a backup (rain fade) AP for dual-band Cubes. Use bonding (active/passive) on the Cube, and make sure whatever VLANs you put on the wAP's are also on the OmniTiks' wlan interface.

On all 60GHz gear:
- 58320 and 64800 are best for up to 600-700m PTMP, 1km PTP
- 60480 and 62640 are OK up to about 300m PTMP, 500-600m PTP (your experience may vary)
- 6.49.x versions are the most stable
- 7.6+ looks promising (testing it on three Cube 60's)

I have dozens of wAP 60's and Cube 60's as AP's, with anywhere from 2 to 8 CPE on each one. Many of them will drop and reconnect within a split second, but nobody notices those drops. It's the ones that last longer than a couple seconds, or when they're really frequent. Sometimes a channel change is all that's needed.

I'm imagining no progress on this? Is there are Cube Pro ('ay) firmware and settings that is stable PtMP?

I seem to have a slightly different issue, only recently have I used the newer cube60 pro radio's in a multipoint setup (all radio's are the cube60 pro's, not the cube60sa) and it seems the AP soft locks, it responds to pings but you can't log into it, winbox shows no content, no interfaces etc. and data does not flow
OR it will respond and work but the 60ghz clients are connected (at least according to the AP, couldn't check the SM side) but no traffic flows across. They do not appear in neighbors etc. Log shows the odd authentication failed message but its not very frequent.
Do not have to restart the SM's at all, just power cycle the AP and everything reconnects and works again
This happens every few days, and it only happens when the AP is used as a multipoint to connect to more than 1 SM. In a PTP situation its fine. Doesn't happen with the older 60ghz products

We have potential fix for PtMP issues. We are still testing, but it should be ready in next beta releases.

Goood...... in the end I will may buy the new CubeG-5ac60ay-SA I have been waitng over a year

Fix should improve stability to 802.11ad line as well. Unfortunately we will not have it ready to next stable release cycle.

Thats great... I have few of those Thank you

Looks like PTMP fix is working as intended. Testing it for 1 hour now with nonstop bandwidth tests from clients and without any client drop! Looking for ASAP inclusion in any stable version. Thanks.

awesome, looking forward to release.

Has anyone had any throughput issues with PtMP? I have the 2x CubeSA 60Pro with either Cube60G or Cube60Pro clients (One SA has all 60G, other has all 60Pro).
All clients are within 200m and have decent signal/MCS levels. 5GHz is disabled on all units.

When there is one subscriber connected I can easily saturate the 200mbps WAN connection, with 2 client speeds drop down, often <20mbps.
Looking at peak load last night there was approx 60mbps going over the AP, which was enough to cause regular disconnections of all clients. This is also below the normal peak load of the site.
Currently on 6.49.6 but have also tested up 7.8 and 7.9rc1 with the same results. Also tested using a Cube60G as the Access Point with the same results (but did not test long enough to see if disconnections were occuring.

Btest between AP and Clients still shows 600mbps TCP but over WAN shows 20-40mbits.
Btest over WAN to AP shows 150+
Btest over WAN to client (multiple clients connected) show 20-40
Btest over WAN to client (single client connected) shows 150+
Similar results with speedtest.net from directly connected laptop

Edit 12/4: Upon further investigation we suspect that the 30-40ms jitter when multiple clients are connected is causing a significant hit to TCP performance. No resolution as yet.

yes! same here...

Has anyone had any throughput issues with PtMP? I have the 2x CubeSA 60Pro with either Cube60G or Cube60Pro clients (One SA has all 60G, other has all 60Pro).
All clients are within 200m and have decent signal/MCS levels. 5GHz is disabled on all units.

When there is one subscriber connected I can easily saturate the 200mbps WAN connection, with 2 client speeds drop down, often <20mbps.
Looking at peak load last night there was approx 60mbps going over the AP, which was enough to cause regular disconnections of all clients. This is also below the normal peak load of the site.
Currently on 6.49.6 but have also tested up 7.8 and 7.9rc1 with the same results. Also tested using a Cube60G as the Access Point with the same results (but did not test long enough to see if disconnections were occuring.

Btest between AP and Clients still shows 600mbps TCP but over WAN shows 20-40mbits.
Btest over WAN to AP shows 150+
Btest over WAN to client (multiple clients connected) show 20-40
Btest over WAN to client (single client connected) shows 150+
Similar results with speedtest.net from directly connected laptop

We have potential fix for PtMP issues. We are still testing, but it should be ready in next beta releases.

Hi, which beta can I test for more stable w60g ptmp? I have a lot of trouble stabilizing wap60gx3 with three Cube60gAC attached. Using fw 6.49. Thanks!

Hi, which beta can I test for more stable w60g ptmp? I have a lot of trouble stabilizing wap60gx3 with three Cube60gAC attached. Using fw 6.49. Thanks!

How is your wAP60gx3 mounted? I found they don't work when mounted on a metal pipe/mast/pole/wall. The signal leaks out through the back enough that it causes major reflections.

If you mount it on a plastic pipe or standoff, or lift the top of the AP above the top of the metal, it will work much better. The trick on those is to get the the upper 1"/250mm (where the patch antennas are) away from reflective material.

There is also a command line setting for those (forgot what it is) that's supposed to help with stabilization; it's in the help pages for 60GHz and on the forum.

How is your wAP60gx3 mounted? I found they don't work when mounted on a metal pipe/mast/pole/wall. The signal leaks out through the back enough that it causes major reflections.

If you mount it on a plastic pipe or standoff, or lift the top of the AP above the top of the metal, it will work much better. The trick on those is to get the the upper 1"/250mm (where the patch antennas are) away from reflective material.

There is also a command line setting for those (forgot what it is) that's supposed to help with stabilization; it's in the help pages for 60GHz and on the forum.

Use the QME/QMP mount for the wAP shaped devices. Put the included metal bracket right up flust with the top of the mount so the top of the wAP is above it when it's clicked into the bracket. This is dramatically better than direct to a pole of any kind, even a wood pole. Noticed the issue putting the top of the AP flat with a j-arm, move it up 3" and it gets a ton better.

Use the QME/QMP mount for the wAP shaped devices. Put the included metal bracket right up flust with the top of the mount so the top of the wAP is above it when it's clicked into the bracket. This is dramatically better than direct to a pole of any kind, even a wood pole. Noticed the issue putting the top of the AP flat with a j-arm, move it up 3" and it gets a ton better.

I have a bunch of 60° wAP 60's on various mounts, and they all work fine, metallic or not. As a matter of fact, I have one Cube 60 at 200m+ to the left of one wAP 60 (-270° if front of AP is 0°) attached to a metal J-Arm, and it works beautifully. In that case, it's as if the J-Arm is actually helping the patch. At another site, I have two AP's on a single mast (I think it's EMT), one facing west and one facing north, with the same SSID and 8 customers spread out across them, all within 400m. They all switch between the two as atmospheric conditions change. Those antennas work better (worse?) than they should.

I didn't notice a problem initially when swapping a couple of 60°'s for 180° x3's because the ones I swapped were all on non-metallic conduit. It wasn't until I put one on a pipe that things went south and I figured out what the issue was. Resolution there was the QMP, as you stated.

How is your wAP60gx3 mounted? I found they don't work when mounted on a metal pipe/mast/pole/wall. The signal leaks out through the back enough that it causes major reflections.

If you mount it on a plastic pipe or standoff, or lift the top of the AP above the top of the metal, it will work much better. The trick on those is to get the the upper 1"/250mm (where the patch antennas are) away from reflective material.

There is also a command line setting for those (forgot what it is) that's supposed to help with stabilization; it's in the help pages for 60GHz and on the forum.

Thanks. That must be the issue then. It's mounted on a small metal mount which is attached to a metal fence behind it. Much metal reflection behind it.

Would there be a good material which i can put behind the AP to prevent reflection? Something like a wooden plate?
I might have an option to mount it on a brick wall (with the QMP) would that be sufficient?

(I'll have some photos later this weekend)

Would there be a good material which i can put behind the AP to prevent reflection? Something like a wooden plate?
I might have an option to mount it on a brick wall (with the QMP) would that be sufficient?
(I'll have some photos later this weekend)

Make more space. That's the best solution. If you have to have it against something, make sure that it's a flat surface. A round pipe is a convex reflector, think about eyeglass lenses, that bends and distorts the signal and more specifically, if a radio can see a round pole, it WILL reflect back at it. Round shapes always have a fact that will reflect back. A flat surface will having things bounce off at an equal but opposite angle.

So, since I don't have the QMP yet, I've tried this first. As you can see, first it was mounted below with the fence behind it. Now I've mounted it higher, but still with some metal pole behind it.
First impression and tests are positive. Tested it with real throughput (+- 150mbit) and everything is stable for now. I had 1 to 10% loss on an active link before. Now it stays at 0% and no links down. But... it was only my first test and no offices open today. I'll keep an eye on it and figure out a plan to mount it even better later on.


ps: Setting I had set before, but didn't help out:
- static sector (/in w60g set 0 tx-sector=36)
- mdmg-fix ON (/interface w60g set wlan60-1 mdmg-fix=yes)

Looks good. The only thing I'd personally do is to bolt the radio higher up on the tilt mount so there's zero metal behind the patches (the top inch or two).

I've never locked the sectors on any radios. And I likewise haven't noticed any difference with mdmg fix enabled.

Next beta (after RC and stable) release, should address some of x3 issues as well. Hopefully mdmg-fix could be switched to off onward.

do you mean version 7.10 or will it be included already in 7.9?

think guys.... 7.9 is already RC, it will not became beta again......

Hi,
Small update on the progress of moving the AP upwards (see picture above)

The link hasn't been down even once the past two weeks! The reflection definitely was to blame and your solutions have solved a lot of trouble for me. Thanks!

@MikroTik Support Please release a working version as soon as possible. Customers complain to us that their online streams/games etc are interrupted. We don't have a workable solution for them.

We updated to the latest RC a couple weeks ago and the AP's stopped soft locking
However there's still an issue, not sure if its always been there (I would say so) but we have only just recently narrowed it down to being replicate able

Using 3x Cube60Pro AC's in a multipoint setup, when I run mikrotik btest across them absolutely no issues at all holding a solid 2gbit/s in either direction
However when the client behind one of the SM's runs a test from speedtest.net it will cause 'both' SM's to disconnect from the AP
The download test is fine, its always the upload test that does it. It's 100% repeatable that it will cause both SM's to disconnect after approx 3 seconds on the upload test (which is about 400mbit/s at the time, well below what the radio link can do)

When I kick off 1 of the SM's and run it in PTP mode, no issues at all it'll stay connected
Am currently on the latest 7.9rc5 on all radio's. As long as no one attempts to upload at a high speed then its fine it'll stay connected, but very quickly after that the SM's disconnect. Isolate-stations is turned on so traffic is not bleeding between SM's
Have tried all the frequencies, makes no difference so its highly unlikely to be a neighboring interference issue
Unless the SM running the speed test is causing interference on the other SM that is in-line with it, and that somehow signals to the AP to kick the session
But its looking like this is a bug

fix is there:

7.10beta5
*) w60g - improved interface stability for PTMP setups;

Have you seen any noticeable improvement? Are all clients still being disconnected (7.10beta5)?

The latest 7.10beta5 appears to have fixed the issue I was having, can now run upload tests from client side without causing radio disconnections. Note that importantly it never disconnected with a mikrotik btest, it was only specific types of traffic
Note also that you only need to update the AP and not the SM for the fix to take effect. So the issue was definitely AP specific

I would like to hear from MikroTik support in some technical detail as to what they suspect the issue was, and what specifically was implemented to fix it

You're unlikely to get that kind of detail. It's most likely some kind of driver update or tweak at a really low level.

I loaded it on some of my lightly-loaded AP's a couple hours ago and so far haven't seen the same kind of split-second disconnects I'm used to seeing. So now I'm loading it up across the network on busier AP's to see how it does.

Could we please get a bit more feedback before we include this fix in upcoming stable version? Thanks!

Tested on many sectors. It's much better than it was.
But the problem is not completely eliminated.

Yes I agree with the opinion above. It's much better - the disconnections don't happen as often, but they do occasionally. If you tweak it even more like 802.11ad, that would be fine.

@antonsb It would be nice to know why they dropped, if that's possible to glean from the driver (example: signal too weak, stopped transmitting, too many errors, etc.). Perhaps the AP and/or the station could also log the last known signal level as they leave.

I have loaded this onto a number of wAP 60's and, in some cases, things appear better (less flapping). In other locations, it looks like it did before: stations going away for a second or so at a time, then coming back.

We've had pretty regular afternoon thundershowers these past two weeks, and I don't know if some of the stations have dropped due to low signal from rain fade, or something else (power outages, reboots, etc.).

What are your PMTP pings from AP to CPE?

For me they are in the range of 1 - 10ms. That seems like a lot to me. When only one client is connected, they are around 1ms all the time. I understand that there is some extra overhead with multiple clients, but by that much?