Cube:
jul/28 01:13:32 interface,info wlan60-1: link down
jul/28 01:13:32 interface,info wlan60-1: link up
jul/28 01:24:13 interface,info wlan60-1: link down
jul/28 01:24:17 interface,info wlan60-1: link up
jul/28 03:25:53 interface,info wlan60-1: link down
jul/28 03:25:53 interface,info wlan60-1: link up
jul/28 05:47:10 interface,info wlan60-1: link down
jul/28 05:47:10 interface,info wlan60-1: link up
jul/28 12:15:06 interface,info wlan60-1: link down
jul/28 12:15:08 interface,info wlan60-1: link up
jul/28 12:15:33 interface,info wlan60-1: link down
jul/28 12:15:35 interface,info wlan60-1: link up
jul/28 12:42:51 interface,info wlan60-1: link down
jul/28 12:42:51 interface,info wlan60-1: link up
jul/28 16:43:21 interface,info wlan60-1: link down
jul/28 16:43:24 interface,info wlan60-1: link up
jul/28 16:43:59 interface,info wlan60-1: link down
jul/28 16:43:59 interface,info wlan60-1: link up
jul/28 16:47:48 interface,info wlan60-1: link down
jul/28 16:47:48 interface,info wlan60-1: link up
I have 3 clients using an Aircube Lite connecting to a wAP60 in a PtMP environment.
One of the clients had the most link up link down problems (which is killing for VoIP).
I changed the chanel from auto to channel 4 last night. After that I found that the problem only still persists with the specific client.
It seems that this client still gets the same amount of link up link down errors.
After the change of frequency AND reboot of the client AP (cube) it lasted about 13 hours before I saw the connection flapping again.
now: 2 hours ago I only rebooted the cube again and since then I haven;t seen flapping coming back (yet)
For now it seems that the only way to get is stable for ~12-13 hours is to reboot the station.
Unfortunately I had to reboot the client again as it began flapping again, about 12 hours after the previous reboot.
Since the reboot this morning @ 07:40 since now (13:52) I haven’t seen any disconnects.
I haven’t rebooted the PtMP WAP60 yet since the other 2 clients haven’t had any problem since 3 day’s now (after changing the frequency to channel 4 (formely set on auto but forgot to see the actual state then)
I down graded to 6.45.9 and now things seem better. The link has not dropped after rebooting (5 hours) and monitor shows the error packets are fewer with lower amounts of errors.
For me, again, I had to reboot. Yesterday I rebooted @ 07:41 and flapping began @ 01:13
Now I rebooted @ 08:16 and I will see how long it takes before it will flap again.
Still nothing in the logs to be found usefull why the connection drops every now and then.
It just tells me the link is down and up again.
I am very curious what happens after Joe’s downgrade. Hope it helps.
Downgrading didn’t fix my issue unfortunately
SOmtimes I also see an error in the logs like this: snmp,warning timeout waiting for program 20
Although I think this has nothing to do with the link down and link up issue…
I tried an alternative frequentie now, Let’s see what happens…
Same here, with 6.47 and 6.47.1 (both WAP and Lite60 client) many link down/ups happen, after downgrade to 6.45.9 all good. (also MCS seems more stable).
There were also cases where client would log a quick link down/up and 5 minutes later another quick link down up, while on the AP there would be for the same time range a link down… 5 minutes later link up, and the client wouldn’t really be sending/receiving data for the whole 5 minutes.
I suspect these from 6.47 changelog:
*) w60g - fixed link status logging;
*) w60g - improved rate selection in low traffic conditions;
download latest stable ROS version and install it
if it doesn’t help, download long-term release and install that one (have to enable downgrade)
if still having problems, try 6.45.9 mentioned above or 6.46.5
Halo I have the same issue on the new Cube 60 ac with 1G ports connected to wAP 60Gx3 AP. It was delivered with factory version 6.47.5 I tried to downgrade it to 6.45.9 but the netinstall didn’t allow it.
I have one CPE that is rock solid on another 60ghz link, so I have installed matching version of the OS on this link. Still, it resets the link several times a day.
Is there a setting I can enable where it will give more debug information as to why a link flaps?
We used to have a SIKLU 60ghz setup, and it was rock solid. Why can’t Mikrotik’s product be as reliable?
I agree, it’s very frustrating. I reset all my devices back to factory defaults (2 WAP60G’s and 1 WAP60Gx3 AP), then upgraded them to 6.4.8 (stable). I then applied the cli fix “/interface w60g set wlan60-1 mdmg-fix=yes” on the WAP60Gx3 AP. So far it’s been a two days and I have only seen a couple on link up/downs during the night. It’s way better than before. When I had the two WAP60’s setup in a PtP config it was rock solid. Adding the WAP60Gx3 AP to the mix made everything wacky. I hope they fix whatever is wrong. I spent over a week fighting with it, trying different firmware’s, etc. One WAP60G is 19m and one is 29m away from the WAP60Gx3 AP so the connection should be rock solid.
As I understood on my link with SXTsq Lite60, the problem lies in the implementation of Beamforming.
At cheap devices, there is no hardware tuning, and Mikrotik implemented software tuning with an internal script. The device regularly measures the signal strength (as I understand it) and at some lowering starts the Beamforming adjustment. In this case, the script breaks the link, determines the maximum signal strength in the antenna array and enters the measured values in the Beamforming table, after which the link is restored.
You can either disable Beamforming altogether, or set the static value manually. The script will not work and the link will not be interrupted.
Beamforming is disabled with the command /int w60g set tx-sector=0
I assume that the default value of “Auto” is only for the initial launch of the link.
If during installation the devices are pointed exactly at each other, and the mounting of the devices is massive and reliable (there is not the slightest swaying from the wind), then you need to manually fix the TX Sector with the measured value.
If the mounting of the devices is not very stable, then the TX Sector should be set to " 0"
Since the “central axis” of the antenna does not coincide with the geometric center of the body, it is necessary to point the devices at each other using the “artillery targeting” method: turning the device left-right and then up-down, and fixing the directions when the link breaks. The midpoint between the fixed directions and will be the “central axis” of the antenna. The deviation from the geometric center of the case can reach several degrees.
I thought that if you disable beamforming the signal level to fall heavily, but this didn’t happen. The signal remained as it was. And the breaks have stopped, the link is now working stably. The ROS version is the latest at the moment (6.48).
