Hello. NV2 have still random problems with locked modulation on 6,5Mbit. This is P2P link. On both sides is ROS 5.25

AP side show 6,5Mbit TX / 130 Mbit RX. In the same time client side of the link show 130/130Mbit.
Sometimes it happens after 30 days, sometimes after 80 days. It's completely random. Throughput is very poor because of the locked modulation
See Ticket # 2012122166000702

I think so this is problem on AP side. Just turn off/on wireless and everything is ok - 130/130Mbit

Users - how do you solve this problem?

Not sure this will help but I have set all my AP's from default frequecy scan to +/- 20 to 40Mhz above and below the AP frequency, for example AP=5220, frequency scan 5180-5260, the same at the other end of PTP

It is another problem. There is NO scan list used.
Mikrotik team please see on Ticket # 2012122166000702

What is happening if you run traffic over the interface?

See BW test over wlan interface. Maximum troughput in tx is about 5Mbit. It is simple TX is locked to 6,5Mbit, but why? You don´t have sometimes this problem?

Disable/enable wireless, then is rate 130/130 a troughput in tx is over 60Mbit. This problem is only with NV2 protocol

Hi,

We are observing this problem too (for long time - maybe 1year+). Reported to support several times.

Typical signs of the problems is that latency on the link raises (but it depends on traffic on the radios) and the throghput lowers and when you try to find out what happened you see that AP is showing some low modulation in TX direction to a station. And the modulation doesn't change during time. Usually you will see a low modulation like 6.5mbps and even there is a good quality the modulation is still the same. Client side in the same time will show RX modulation which is different (higher). If you check times of RX modulation last measurement showed by client (winbox's Signal Strengths or print stats in registration-table) the there is only one or 2 modulations with lower times (measured recently). If these modulations are low ones you have a problem.
It is possible to write a script which will check all the client stations and inspect the modulation table's times (btw: thank you MT for the stupid time representation used in CLI)

And it looks like any modulation can be the locked one (we have seen already locks on 6,9,12,18,36). The lower ones have higher impact on the network. Btw MT shows another modulation name in 'Signal strengths' and in the registration table (6 versus 6.5 etc).

I understand the MT's support has not enough information to kill the problem (it occurs rather randomly) but from another point of view I thing they should take the problem much more seriously. What is Mikrotik without functional wireless layer? Nothing. If the problem had enough priority it could be solved before months.

the only way to fix this low modulation lockup is by uploading special packages and monitor that link till it locks up and then we could try to apply a special package for that and monitor again. And continue to do so till we will find the problem and solution. But to fasten all that we would need a link where it could happen more often - not once in a month.

the only way to fix this low modulation lockup is by uploading special packages and monitor that link till it locks up and then we could try to apply a special package for that and monitor again. And continue to do so till we will find the problem and solution. But to fasten all that we would need a link where it could happen more often - not once in a month.

soon we will have ready a mass monitoring script which will tell us whether there is a location in our network where the lockups occurs frequently. Probably it will not be on a PtP line but on an AP resp CPE routers at customers. The problems on PtP links are relatively rare (although not so rare we can ignore them) . I will contact you.

I've seen the situation that AP and CPE has different readings for the modulation in their registration table. AP was 5.25 and CPE 5.6 (rb133c). AP shows 6MBit while CPE shows 18MBit for the same connection. Protocol is NV2. Reboot of the cpe solved this.
Other CPEs on the same AP did not show this behavior.

soon we will have ready a mass monitoring script which will tell us whether there is a location in our network where the lockups occurs frequently. Probably it will not be on a PtP line but on an AP resp CPE routers at customers. The problems on PtP links are relatively rare (although not so rare we can ignore them) . I will contact you.

Can you share this script?

soon we will have ready a mass monitoring script which will tell us whether there is a location in our network where the lockups occurs frequently. Probably it will not be on a PtP line but on an AP resp CPE routers at customers. The problems on PtP links are relatively rare (although not so rare we can ignore them) . I will contact you.

Can you share this script?

the script uses our database so it is not usable outside our company.

the only way to fix this low modulation lockup is by uploading special packages and monitor that link till it locks up and then we could try to apply a special package for that and monitor again. And continue to do so till we will find the problem and solution. But to fasten all that we would need a link where it could happen more often - not once in a month.

soon we will have ready a mass monitoring script which will tell us whether there is a location in our network where the lockups occurs frequently. Probably it will not be on a PtP line but on an AP resp CPE routers at customers. The problems on PtP links are relatively rare (although not so rare we can ignore them) . I will contact you.

Let us know by writing to support@mikrotik.com when you have found the wireless links that experience this problem very often.

And it looks like any modulation can be the locked one (we have seen already locks on 6,9,12,18,36). The lower ones have higher impact on the network. Btw MT shows another modulation name in 'Signal strengths' and in the registration table (6 versus 6.5 etc).

I understand the MT's support has not enough information to kill the problem (it occurs rather randomly) but from another point of view I thing they should take the problem much more seriously. What is Mikrotik without functional wireless layer? Nothing. If the problem had enough priority it could be solved before months.

Wireless layer - funkcionality is very very important. Now we use NV2 everywhere. But this know issue is very annoying.

I understand that support wants access to the AP where it happens often. But how to do that if it is random problem? The problem occurs maybe once in 30 days. Then clients call and complain about the speed.
I give remote access to "Locked AP" for support@mikrotik.com, but nothing changed.
They need to problem occurred frequently. But how to do that?

Ive seen this a lot on nstreme data rate will lock on 6Mbit after 60-90 sec link will disconnect and reconnect
On nv2 Ive seen it on 3 or 4 times - wrote to support but no feedback

soon we will have ready a mass monitoring script which will tell us whether there is a location in our network where the lockups occurs frequently. Probably it will not be on a PtP line but on an AP resp CPE routers at customers. The problems on PtP links are relatively rare (although not so rare we can ignore them) . I will contact you.

Hello dada. Have you any news with your network where this problem occur more often?

soon we will have ready a mass monitoring script which will tell us whether there is a location in our network where the lockups occurs frequently. Probably it will not be on a PtP line but on an AP resp CPE routers at customers. The problems on PtP links are relatively rare (although not so rare we can ignore them) . I will contact you.

Hello dada. Have you any news with your network where this problem occur more often?

I have some stations which lock near every day. But most of them are RB112/133.
Each time I run the script I find several locked CPEs. If all is OK I will contact Mikrotik support tomorrow to arrange the remote access to the stations/APs

soon we will have ready a mass monitoring script which will tell us whether there is a location in our network where the lockups occurs frequently. Probably it will not be on a PtP line but on an AP resp CPE routers at customers. The problems on PtP links are relatively rare (although not so rare we can ignore them) . I will contact you.

Hello dada. Have you any news with your network where this problem occur more often?

I have some stations which lock near every day. But most of them are RB112/133.
Each time I run the script I find several locked CPEs. If all is OK I will contact Mikrotik support tomorrow to arrange the remote access to the stations/APs

When you look at these RB112/RB133 do they show locked down rate? I've seen higher rates on CPE than on AP.

When you look at these RB112/RB133 do they show locked down rate? I've seen higher rates on CPE than on AP.

the rates on CPE (shown in Registration Tab) are higher than the corresponding ones on AP (usually there is maximum rate displayed). Typically you can find that a 'locked' CPE shows 100% quality in RX direction (probably because it gets all the packets on very low modulation) and when you have "Last Measured" of modulations ordered by their time you see only one modulation (typically basic modulation i.e 6mbps) or two modulations which were measured before very short time but and all other modulation were measured deep in the past (I use 5 minutes as a threshold in the script).

On the AP you can identify 'locked' station when you check all the stations with low TX modulation - run (MAC) ping to them with delay 100ms and wait a minute if the TX modulation goes higher. If it remains the same (and the TX quality is not poor) the station has probably locked modulation. Then kick it off - seelct it and press the "-" (minus) button near to the top left corner of the Registration Tab window). After the station reconnects check if the modulation goes higher.

Hello. Any news? Give you remote access for support?

Hello. Any news? Give you remote access for support?

I have sent the passwords to support before one hour. Unfortunatelly, from offered list of clients (most of them slow boards), they selected the one which is RB433 and locks not so often. And I am not sure they will want to solve the problem in 5.X since I had to upgrade the client and AP to 6.5 version...

Now with uptime only 22days. P2P link is locked to 6,5Mbit. Customers call - speed is terrible

Now with uptime only 22days. P2P link is locked to 6,5Mbit. Customers call - speed is terrible

note: you need inspect Last Measured times on client not on AP

Now with uptime only 22days. P2P link is locked to 6,5Mbit. Customers call - speed is terrible

note: you need inspect Last Measured times on client not on AP

Yes but what is solution? In configuration P2P links is problem on AP side. Disable/enable wireless solve this problem.

When you have locked clients - what is solution? Reboot (Disable/enable) AP or just reboot client?

Now with uptime only 22days. P2P link is locked to 6,5Mbit. Customers call - speed is terrible

note: you need inspect Last Measured times on client not on AP

Yes but what is solution? In configuration P2P links is problem on AP side. Disable/enable wireless solve this problem.

When you have locked clients - what is solution? Reboot (Disable/enable) AP or just reboot client?

to 'unlock' the client it is enough to disconnect it. Use the [-] (the minus) button in Registration table in winbox (either on AP or on client). This way the client reconnects in shortest time probably.

to 'unlock' the client it is enough to disconnect it. Use the [-] (the minus) button in Registration table in winbox (either on AP or on client). This way the client reconnects in shortest time probably.

I know it. But this is not solution of problem

Have you any news? A have this issue now in P2MP scenario. AP is rb800 with 5.26.

Some clients are locked on 9Mbit on TX. Very bad throughput

Have you any news? A have this issue now in P2MP scenario. AP is rb800 with 5.26.

Some clients are locked on 9Mbit on TX. Very bad throughput

nothing new. I have many lockups on clients using RB1xx boards but newer boards have the problem less frequently. And it looks when we monitor them they lock the modulation even less frequently

I is not only problem rb1xx. I have the same problem on rb411 and Groove. It is SW problem

we have the same problem with RB800. So far, the problem is solved by restarting but it is repeated every week and there is no solution for the problem yet.
Today I will upgrade to 6.5 and see if there are results.

we have the same problem with RB800. So far, the problem is solved by restarting but it is repeated every week and there is no solution for the problem yet.
Today I will upgrade to 6.5 and see if there are results.

With 6.5 the same issue. Today reported to support

Out of interest, have you tried setting all of the following to an empty string on both client and AP:

basic-rates-b
supported-rates-b
basic-rates-a/g
supported-rates-a/g

Just an idea because 6Mbps seems to be listed as an 802.11a/b/g rate, not an 802.11n-like HT rate. Also, I've removed all the a/b/g rates from a client/AP pair and the 6Mbps rate is still listed in "/int wire reg print stats". This might suggest that if you're only looking at the "Signal Stengths" table then the "6Mbps" won't ever go away... Maybe MikroTik can confirm that the 6Mbps rate is tested for signal strength regardless of your data rate settings?

Along the same theme, if your link 'usually' has a data rate of 130Mbps, with a high CCQ, then why not use "rate-set=configured" and explicitly limit your data rate choices to HT20-7 or HT40-3 or whatever. Maybe that will stop RouterOS from even picking the 6.5Mbit rate? (By the way, 6.5Mbps is HT20-0, not the 6Mbps a/b/g rate in case there is any confusion)

I have two test OmniTiks running NV2 locked to mcs-11 (ht20-3 and ht40-3) and although the 6Mbps rate shows up in signal strengths, the actual tx/rx rates are both 120Mbps:

ros code

[admin@MikroTik] /interface wireless> reg pr stats
 0 interface=wlan1 radio-name="D4CA6DF04D3B" mac-address=D4:CA:6D:F0:4D:3B ap=yes wds=no bridge=no rx-rate="120.0Mbps" tx-rate="120.0Mbps" packets=79097,106164 bytes=24039103,143155344 frames=25726,101470 frame-bytes=24160704,142808304 uptime=9m1s last-activity=0ms signal-strength=-29dBm signal-to-noise=85dB 
   signal-strength-ch0=-45dBm signal-strength-ch1=-29dBm tx-signal-strength-ch0=-45dBm tx-signal-strength-ch1=-42dBm strength-at-rates=-29dBm@6Mbps 0ms,-41dBm@HT20-3 8m20s130ms,-42dBm@HT40-3 0ms tx-signal-strength=-40dBm tx-ccq=100% rx-ccq=100% distance=1 routeros-version="6.2" last-ip=192.168.88.223 tdma-timing-offset=-1 
   tdma-tx-size=1520 tdma-rx-size=4000 tdma-retx=0 tdma-winfull=0 
[admin@MikroTik]

Hope this helps... do report back!

Hello. I have renamed topic. Yes, it is 6,5Mbit. When I have mode - 5Ghz-only N. The problem is the same - locked to 6,5Mbit after some time....

You have nice idea. Using only higher MCS rates, other disabled. I will try it on P2P links. But this is not solution for P2MP where is the same problem with locked modulation on 6,5Mbit

Ive had this problem. I can add just a few bits of info:

1/ When problem occurs, to resolve it no reboot is needed. Just disconnect the wireless client and when it reconnects it's solved till it happens again!

2/ Problem is not solved by not allowing 6.5mbps rate. It just locks on the higher rate as well.

3/ Problem is pretty rare. Probably has happened only a handfull of times over a year on two of 20 links.

Ive had this problem. I can add just a few bits of info:

1/ When problem occurs, to resolve it no reboot is needed. Just disconnect the wireless client and when it reconnects it's solved till it happens again!

2/ Problem is not solved by not allowing 6.5mbps rate. It just locks on the higher rate as well.

3/ Problem is pretty rare. Probably has happened only a handfull of times over a year on two of 20 links.

yes, I can confirm everything you wrote.

Now we have no problem with 6.5 and 6.6.

Now we have no problem with 6.5 and 6.6.

you are a lucky man, then. It is only matter of time when the links will lock. We have had already several locked modulation cases on 6.6. Finnally it happened that Mikrotik support staff was able to see it on live so they installed some debug pakage on the radios and rebooted them. We were lucky because after it the radios locked the modulations again soon. But Mikrotik's were not able to get all needed information out of the radios probably - because they compiled a new wireless package and rebooted the radios again. And the link didn't lock after it yet.

After observing the problem - there is an interesting thing related to RB1xx - I started to upgrade them to 5.26 and after it the rate of problems with these old boards significantly lowered

bad news

We can only test the 6.7 and hope ....

I am creating a script to check this. I wont have time to test for a while it but if anybody can try this let me know if it works, the script would need to go both ends to work or change it to check rx-rate too on one end:

{
:local a [/in wi reg get number=0 tx-rate]
:put $a
:if ($a>=6.5Mbps) do={
/interface wireless registration-table remove 0
}
}

I am creating a script to check this. I wont have time to test for a while it but if anybody can try this let me know if it works, the script would need to go both ends to work or change it to check rx-rate too on one end:

{
:local a [/in wi reg get number=0 tx-rate]
:put $a
:if ($a>=6.5Mbps) do={
/interface wireless registration-table remove 0
}
}

if you want to detect the problem without too much false positives you really have to:
1) check it on stations not on APs (the registration table on station shows that only one or 2 modulations were used for long time - other modulation have high 'uptime')
2) accept the fact that the locked modulation can occur on other modulation than 6.5mbps. Probably it could be any modulation (even the highest one)
3) be sure that there is enough traffic - because with no traffic any link tends to fall down to 6.5mbps for longer time
4) you will probably need to use no Mikrotiks's CLI scripts but some external scripts which connects to stations via API

I think in my case this will work as it's a point to point backhaul link.

1) check it on stations not on APs (the registration table on station shows that only one or 2 modulations were used for long time - other modulation have high 'uptime')

I did say both ends or change script to check tx and rx.

2) accept the fact that the locked modulation can occur on other modulation than 6.5mbps. Probably it could be any modulation (even the highest one)

Ive never seen it happen at higher rate apart from when I disabled the 6.5 one as a test. I think that would be good enough at least for my setup to solve it.

3) be sure that there is enough traffic - because with no traffic any link tends to fall down to 6.5mbps for longer time

It never drops to 6.5Mbps unless there is the problem apart from maybe a minute or two when it first connects. But your right that's something else to think about.

4) you will probably need to use no Mikrotiks's CLI scripts but some external scripts which connects to stations via API

that's an option but a real pain in the ass to setup just to work around some bug :-0

I had This problem also but Lucky i had One stx left from my six pack. I chance the client site and after that no problems. There have not bin any issues after I put the new stx on. I have the old (old it is not only 20 days old) with me and all settings is is the same but wend I put the old on again I still have only 6mbit/6mbit same firmware and all?

Cheers jimmy

Send from mobile phone

I had This problem also but Lucky i had One stx left from my six pack. I chance the client site and after that no problems. There have not bin any issues after I put the new stx on. I have the old (old it is not only 20 days old) with me and all settings is is the same but wend I put the old on again I still have only 6mbit/6mbit same firmware and all?

Cheers jimmy

Send from mobile phone

So are you saying you think it a hardware issue only affecting certain hardware?

That is quite interesting as I did have one case of this happening once on another link and a week or so after it happened twice the card died.

The current link I have the prob happening on is both new SXT units though.

Hi guys

I have the exact same problem with Groove and SXT APs. TX-Rate freezes at 6.5 Mbit
So, after a while i made 2 scripts wich "watch" APs and force disconnet if needed over SNMP.

There is first one (Mikrotik AP):
/system script
add name=wlanFix policy=\
ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api \
source="/interface wireless registration-table print\r\
\n/interface wireless registration-table remove 0"

And second (FreeBSD/Linux machine):
#!/bin/sh
DEVICES="10.11.106.254 10.11.113.254"
for DEVICE in $DEVICES
do

# Get Current Frequence
CURFREQ=`snmpget -c public -v 2c $DEVICE .1.3.6.1.4.1.14988.1.1.1.2.1.8.212.202.109.72.76.239.1 | awk '{print $4 }'`

# Compare and disconnect if needed
if [ $CURFREQ = "6500000" ]; then
`snmpset -c public -v 2c $DEVICE 1.3.6.1.4.1.14988.1.1.8.1.1.3.1 s 1`
else
echo $CURFREQ
fi
done

Hint: Ofcourse you have to change SNMP comunity to fit your needs.

In my case i run it on evry 5 min via crontab on FreeBSD, but i think it could be used on Linux as well.
I hope it could be usefull

I had This problem also but Lucky i had One stx left from my six pack. I chance the client site and after that no problems. There have not bin any issues after I put the new stx on. I have the old (old it is not only 20 days old) with me and all settings is is the same but wend I put the old on again I still have only 6mbit/6mbit same firmware and all?

Cheers jimmy

Send from mobile phone

So are you saying you think it a hardware issue only affecting certain hardware?

From detected nv2 problems in our network I cannot say that the problem is related to any specific hardware (although I didn't checked it much). I can say only it affects older slow boards (1xx) more frequently than the more modern ones. And after upgrading the problematic old boards to 5.26 the frequency of the problem lowered significantly.

And it seems that for some strange cause the probability of nv2 modulation lock is much higher when a new radios are installed (when we upgrade an old PtP link to MIMO usually it locks withing a few of days. Then it locks again one or 3 times and after it there is much longer time than the problem occurs again).

And my colleague thinks that when the radio is powered of and on the probability of the nv2 modulation lock is higher too.

From my point, I have bye a six pack stx and only one has this problem, so in my case it is the hardware.
My point wars to complete reset and put new firmware and all again, but it is still the same, 6mbit lock?

Cheers
jimmy

Send from mobile phone

Problem persist with ROS 6.7 on both sides of P2P link. [Ticket#2013110466000664]

So it seems we are no closer to a fix of this problem...

Having read through this thread, it's interesting that a hardware problem has been mentioned, so here's my take on this, maybe someone can offer me help, maybe it could help others...

I have what I consider a fairly large network with currently around 150 clients, 18 base stations and a mix of sectors and OmniTiks, it's all MikroTik, but that will be no reason for me to get an answer from them. I have dedicated links between base stations using either RB433s and grids, SXTs or Sextants and I have various Internet connections, I'm running a bridged network with OSPF and PPPoE.

I have only recently experienced this locked speed and it only happens on the client, the AP adapts. I have a couple of SXT 5nD r2's creating a dedicated backhaul link and originally they were fine for almost a year, then I noticed this locked problem on one end, so changed it for a new one, the problem was immediately still there, so I changed the other end thinking the problem was there instead.

Immediately the problem was there and even after 2 days it remained locked, I sent in supouts and gave complete access to support, but they have been less than helpful, hence posting here. It seems we have more experience than MT support at trying to resolve problems.

So having replaced both ends of this link with brand new SXT 5nD r2s, the problem was immediate, so by order of MT, I uploaded "test" software and rebooted, only to find I then had to go and replace them both again as neither came back. Having sent in lots of supouts and trying various software versions over the last 6 weeks, I now have it running 6.10 and it's working... BUT...

When I upgraded to 6.10 the problem was immediately still there, so instead of having them connect to each other, I put them as clients on different base stations and noticed that the problem was on the RX on 1 and the TX on the other, so I reversed the AP/Client connection and rejoined them and now it's been up for almost 5 days without fail. So to clarify, the 2 ends had the same problem when connected as clients to different AP's but on alternate chains, 1 was on RX, the other was on TX.

When I originally had these 2 brand new SXT's connected, they were oriented so that I had poor speed on one chain, which is the problem seen everywhere, by changing the AP to client and visa-versa, it has now been up for 5 days without fail. When I first linked them, they immediately failed in the other orientation no matter what I did, reboots, wireless disconnects etc., never fixed it, at the moment I have this:



Today I see I have yet another problem on a different SXT 5nD r2 link, this was a new SXT running ROS 5.24 and has been up, running and in service for 237 days, so I think this proves it's a hardware problem.



Now please note that although the actual link speed is fairly fast, I have most of my backhaul links running at around 270Mbps both ways, notice the registered signal level though, I have it ordered by last measured and you can see it is locked at 6Mbps, so although it appears to be running at 243.0Mbps/81.0Mbps, it is not, the test for this is to run ping speed or traceroute across the link one way, then the other.

Trace to a node either side of the wireless link and it becomes clear that the ping speed and thus data speed is low in one direction, my network has many clients that come and go frequently so I use OSPF and when these links run slow, OSPF drops out as it cannot exchange routing data efficiently enough to keep the routing tables updated, thus I end up with a link that drops an entire network segment, which then cascades to other routers and causes downtime on the affected segment as it cannot find the default route to the Internet.

If MT support are interested, I have supouts of this link, although you've been no use so far, I want to try my own tests which I will report back on soon. I want to downgrade the affected links to 5.14 as it seems I have no problems on links running this, but to be honest, this could also prove it's a hardware problem. If it does prove to be a hardware problem, then the Mikrotik equipment I've been buying recently is not fit for purpose and I will be seeking replacements.

Gary

Now please note that although the actual link speed is fairly fast, I have most of my backhaul links running at around 270Mbps both ways, notice the registered signal level though, I have it ordered by last measured and you can see it is locked at 6Mbps, so although it appears to be running at 243.0Mbps/81.0Mbps, it is not

on the pictures you attached there is nothing typical to NV2 locked modulation state. If the link modulation is locked the 'station' side shows that
1) in SNR measurement sorted by measurement time there is one or 2 modulation (probably low ones) in fresh state (measurement age in seconds or rather near zero seconds) and the other ones are much older (it can be hours or days - it depends on how long is the link in the locked state).
2) TX quality is 100%

Since the 6mbps is the default modulation which is used whenever there is a need to send some information which must reach all the connected clients you will see that modulation SNR as the fresh one near all the time. Every time for example a broadcast/multicast packet is sent from AP it is send using 6mbps modulation (because any connected station must be able to receive it).

So again - on the pictures there is no locked modulation (if they are taken from 'station' side of the link, of course)

The second picture shows poor CCQ in RX direction....

In our network the locked modulation problem didn't occur on any our link we upgraded to 6.10 (resp 6.8rc1) yet. It is not 100% proof because of short time (some links had the problem after weeks or months of running OK).

In our network the locked modulation problem didn't occur on any our link we upgraded to 6.10 (resp 6.8rc1) yet. It is not 100% proof because of short time (some links had the problem after weeks or months of running OK).

From 6.8rc1 we have no problems. It is amazing to hear that you are the same
Picture which Gazza put is NO locked modulation

Thanks for the responses guys, care to comment on this capture then?...



This was one of the original SXTs that I changed because it wasn't passing data. It's shown running 5.23 and as you can see according to the wireless signal level it appears to be fine, if only a bit slower than normal, the link had been up for just over an hour, the last measured rate shows 6Mbps at the top of the list like my other picture, but you can see from the wireless link speed it's locked to 6.5Mbps. It was normally 243~270Mbps for almost a year before it "failed".

I'm not about to get into an argument on my findings, but when the 6Mbps is ALWAYS at the top of the client last measured rate list, I know there's a problem, I then run tests across the wireless link and prove it because the traceroute time from both sides will be 1ms or 2ms one way and sometimes 100s from the other, it sometimes even times out.

Judging by the last measured rates alone would suggest the link is fine as you've pointed out in my previous picture, however, looking at the wireless link speed of 6.5Mbps and the CCQ you can see there's a problem. In my experience of this, it is my understanding and observation that there is no direct correlation between (1):CCQ, (2):wireless link speed and (3):last measured rate time.

I have monitored the CCQ to be ~ 80-100% and the wireless link to be 243Mbps/270Mbps yet last measured is 6Mbps and other times it can be 4/80% CCQ, wireless link 6.5 ~ 162Mbps/243Mbps with last measured as in my previous shot above showing 6Mbps, HT40-6, HT40-5, ... in that order yet still struggling to pass data across the link.

It seems to me there IS a correlation between the CCQ and wireless speed, but not between wireless speed and last measured. However there is always a correlation between poor throughput and last measured. If it is always or nearly always 6Mbps as the last measured rate, then throughput is bad.

I know there's a problem on my network because I use it, I am a client of it and when it drops out, I search for where and it always turns out to be on one of these links where last measured is 6Mbps, even when there's others measured higher below it at the same time, if 6Mbps is ALWAYS last measured, then there's a problem. The links that are solid with no problems NEVER or rarely show 6Mbps as last measured, it's always, or nearly always the 2nd or 3rd in the list, like the first picture I posted above.

When I search for a problem that's how I find it, I look at the client last measured and if it shows 6 most or all of the time, I then run a traceroute over it which shows the poor speed. The attached picture below shows 94/94% CCQ, 270Mbps/270Mbps link speed last measured at 6Mbps and the average traceroute speed at 70ms, this is between the 2 SXT's directly wirelessly connected to each other under 6.9. After contacting support, I was given and tried it with 6.8rc1 but it failed straight away and never got better. I gave support access to them, sent them screen shots and supouts but they visited it only once and told me to upload 6.9, after which I've been ignored!!! This shot is taken AFTER I tried with 6.8rc1 and then upgraded to 6.9 but it still has the EXACT same problem.



I've since loaded 6.10 on this link where I noted the RX/TX chain problem and set it up so the problem end is the AP which seems to have solved it for now. It's been 5 days, whereas when I had it setup the other way it failed straight away and didn't get any better even after 3 days.

Support always says about giving steps to recreate the problem, but they are so far not willing to spend the time to investigate my problem where it occurs straight out of the box. I am very wary of upgrading links as it seems we are being used as test subjects. I don't feel being told to "try" something is solving anything. I understand it's difficult when a problem occurs, you need to be able to re-create it to then find a solution, but when the fault happens straight away from first power up, what better scenario can there be to jump on it and find out why?

For now I will try to find my own work around, as mentioned earlier, I will downgrade to 5.14 as it seems none of my links are suffering up to this, I am increasingly seeing problems which I think is hardware related since they are happening randomly and cannot easily be replicated. You will note in this last picture, there are just 2 deciding factors that this link is locked.

(1):Last measured data rate at 6Mbps with subsequent times being in the past
(2):Traceroute throughput is slow across the wireless link

These are the only 2 factors that prove there is a problem, wireless link speed and CCQ have no place in this diagnosis. As for your kind responses dada and honzam, your last picture honzam from January 16th shows the same as mine, last measured rate looks fine, with other high rates below, as does the CCQ at 100/97%, so the only way you know there is a problem is because the data throughput on the link is slow, just 4.7Mbps and the last measured rate is 6Mbps.

In my humble opinion, it is the last measured rate that is holding down the wireless speed and choking throughput, not that there is a wireless problem, if this is software triggered from hardware, then the problem is hardware and I am here, willing and able to give as much time to solving this as you need MikroTik, my family, livelihood and business depend on it, just don't take too long, it's already been over a month and in another month my network will hopefully be servicing hundreds more clients using your products, so don't fail me..,

Gary

Thanks for the responses guys, care to comment on this capture then?...

I assume the picture is taken from AP side of the link. There is 6.5mbps mentioned in registration table as TX modulation. It could be that the link is in locked modulation state but to be sure you need to check the other side of the link and inspect the measured SNR. If there is only one or 2 modulations which have fresh data and the other modulation's data are 'old' (and they stay old even if there are data transfered through the link) the link has really probably locked modulation. The CCQ on station will probagly be 100 procent in the case too.
Of course on locked state there should not be usually (probably in rare cases the link can lock on the highest modulation too) the highest modulation in the fresh ones - if you have exceptionally good link (no interference) it can run on highest modulation all the time (except packets sents purposedly in lowest modulations - broadcasts etc)

This was one of the original SXTs that I changed because it wasn't passing data. It's shown running 5.23 and as you can see according to the wireless signal level it appears to be fine, if only a bit slower than normal, the link had been up for just over an hour, the last measured rate shows 6Mbps at the top of the list like my other picture, but you can see from the wireless link speed it's locked to 6.5Mbps. It was normally 243~270Mbps for almost a year before it "failed".

Even on a link in good state you will always see the 6.5mbps modulation as the fresh one - again it is a default modulation used to distribute packets which should be delivered to multiple recipients at the same time (broadcasts, multicast etc). Because the default (or basic) modulation is the only one which all connected stations must be able to use.
So having 6.5mbsp as a fresh modulation is not the proof of problem.

I am not saying you have no problem with the link - I am just saying that it looks like you have no nv2 modulation locked problem like we were observing. If the problem occurs again try to create snapshot of meassured modulation on CLIENT side (station)

I'm not about to get into an argument on my findings, but when the 6Mbps is ALWAYS at the top of the client last measured rate list, I know there's a problem, I then run tests across the wireless link and prove it because the traceroute time from both sides will be 1ms or 2ms one way and sometimes 100s from the other, it sometimes even times out.

on a good working link you should see the basic (6.5mbps) modulation and the highest one(s) on the top of the list of measured modulations (sorted by time) = most of packets received on highest modulation and the broadcasts and service frames received on the basic modulation.

Judging by the last measured rates alone would suggest the link is fine as you've pointed out in my previous picture, however, looking at the wireless link speed of 6.5Mbps and the CCQ you can see there's a problem. In my experience of this, it is my understanding and observation that there is no direct correlation between (1):CCQ, (2):wireless link speed and (3):last measured rate time.

I have monitored the CCQ to be ~ 80-100% and the wireless link to be 243Mbps/270Mbps yet last measured is 6Mbps and other times it can be 4/80% CCQ, wireless link 6.5 ~ 162Mbps/243Mbps with last measured as in my previous shot above showing 6Mbps, HT40-6, HT40-5, ... in that order yet still struggling to pass data across the link.

It seems to me there IS a correlation between the CCQ and wireless speed, but not between wireless speed and last measured. However there is always a correlation between poor throughput and last measured. If it is always or nearly always 6Mbps as the last measured rate, then throughput is bad.

I know there's a problem on my network because I use it, I am a client of it and when it drops out, I search for where and it always turns out to be on one of these links where last measured is 6Mbps, even when there's others measured higher below it at the same time, if 6Mbps is ALWAYS last measured, then there's a problem. The links that are solid with no problems NEVER or rarely show 6Mbps as last measured, it's always, or nearly always the 2nd or 3rd in the list, like the first picture I posted above.

When I search for a problem that's how I find it, I look at the client last measured and if it shows 6 most or all of the time, I then run a traceroute over it which shows the poor speed. The attached picture below shows 94/94% CCQ, 270Mbps/270Mbps link speed last measured at 6Mbps and the average traceroute speed at 70ms, this is between the 2 SXT's directly wirelessly connected to each other under 6.9. After contacting support, I was given and tried it with 6.8rc1 but it failed straight away and never got better. I gave support access to them, sent them screen shots and supouts but they visited it only once and told me to upload 6.9, after which I've been ignored!!! This shot is taken AFTER I tried with 6.8rc1 and then upgraded to 6.9 but it still has the EXACT same problem.

if this snapshot was taken from client side it does have measured RX levels which looks like there is a modulation lock. But I would expect the 100% CCQ in RX (maybe even on lowest modulation the link is not fully reliable).
There is 13 minutes gap between 6.5mbps modulation and the others. Which should mean all the data in last 13 minutes were received on 6.5mbps modulations. So either you have only broadcast/multicast packet going through the line or there is modulation locked.
There is 6.9 on the radio - what version of ROS do you have on the other side (it should be the AP od th elink probably)? I guess/hope you have there something older than 6.8rc1. If not than the NV2 locked problem was not really solved yet. You have to have both sides of the link od 6.8rc1+ ROS ...

I've since loaded 6.10 on this link where I noted the RX/TX chain problem and set it up so the problem end is the AP which seems to have solved it for now. It's been 5 days, whereas when I had it setup the other way it failed straight away and didn't get any better even after 3 days.

Support always says about giving steps to recreate the problem, but they are so far not willing to spend the time to investigate my problem where it occurs straight out of the box.

the problem is that it is not possible to see what exactly is causing the problem by observing (connecting to) the radios. They did it in our case and it involved installation of special packages to the radios - with restart so the locked modulation problem disappeared and we had to wait for the another problem hit.

I am very wary of upgrading links as it seems we are being used as test subjects. I don't feel being told to "try" something is solving anything. I understand it's difficult when a problem occurs, you need to be able to re-create it to then find a solution, but when the fault happens straight away from first power up, what better scenario can there be to jump on it and find out why?

what I know about the problem there is no report of it since ROS6.8rc1. May be your case it the first one but I hope it isn't

In my humble opinion, it is the last measured rate that is holding down the wireless speed and choking throughput, not that there is a wireless problem, if this is software triggered from hardware, then the problem is hardware and I am here, willing and able to give as much time to solving this as you need MikroTik, my family, livelihood and business depend on it, just don't take too long, it's already been over a month and in another month my network will hopefully be servicing hundreds more clients using your products, so don't fail me..,

Gary

[/quote]

I would like to add one comment yet:
- the problem with locked NV2 modulation seems to have something related with radio interference. Probably if there is no interference the problem will not likely occur. You are using wide channel (40mbps) which does increase the probability of interference (IMHO)...
- if I need to transfer approx 50mbps+ I use more professional equipment than Mikrotik ones (using 10ghz or other band suitable for directional radio links). In this way I (and many others) am saving the 5ghz band for another use (delivering data to customers via APs etc) and I am having more robust and reliable uplinks...

Until 5.22 the link between my two SXT's with both chains activated used to enter stall mode. After 5.22 stalling was fixed but it entered 6.5 Mbps rate mode.
Since then I only use SXT on single chain mode.
Is there someone in the world who linked two SXT's for a week with traffic spikes of 40-60 Mbps and had no problems? I have 4-5 setups and I just gave up the ideea. (Lucky me the bandwidth of a single chain was enough)

Until 5.22 the link between my two SXT's with both chains activated

Upgrade to 6.11 http://download2.mikrotik.com/routeros/ ... e-6.11.npk

the problem with the locked data-rates to 6.5mbps is fixed in newer Router v6 releases.
Please upgrade the RouterOS to the current release - v6.11
Also you need to upgrade both - AP and the Clients.

Upgraded to 6.11. Firmware 3.12.
The issue is still there just that it has other flavour.
It worked well for 30 minutes and then the connection rate (for tx in this specific case) went up and down from 6.5 to 120 Mbps. The RX stayed at 270/300 Mbps.
The throughput can be seen in the picture. Now I upgraded both sides to firmware 3.13 and rebooted. Currently showing 270Mbps/300Mbps on both sides with BTEST udp running fixed at 50Mbps/50Mbps. I will get back with the results.

Every single link with SXT's with dual chains enabled that I tested developed the behaviour. How cannot this issue be isolated? Really.

And I am back with updates: Disconnecting the link by clicking the minus sign (-) on the side with low TX CCQ caused a reconnection but the CCQ and rate were still low (not steady 6.5 but oscilating at 6.5-60 Mbps).
However, if I disconnected the link from the other side it started working well again.

Bottom line, the issue is not fixed yet.

LE: The link dropped with control frame timeout/registration timeout. Link restored by watchdog on the other side. Disabling the second chain for another year or so ) ...

Disconnecting the link by clicking the minus sign (-) on the side with low TX CCQ caused a reconnection but the CCQ and rate were still low (not steady 6.5 but oscilating at 6.5-60 Mbps).
However, if I disconnected the link from the other side it started working well again.

Bottom line, the issue is not fixed yet.

We have the same issue as you. Problem is not fixed yet. With ROS 6.10 on both sides of P2P link. TX CCQ is vely low and rate is 6,5-30Mbit.
After remove wireless client (clicking minus) then is everythink OK - tx/rx - 130/130. CCQ ok
Unfortunately I forgot to generate supout and send to support. If you have supout.rif (before and after) sent it to support@mikrotik.com

How often does it happen now with newer RouterOS versions?
If you are able to reproduce this problem please report to support@mikrotik.com with the support output files attached from both ends.
Also if you could provide remote-access to such link, it would help us.

I have a similar problem. After upgrading to 6.12 from 6.9 there was bad connection between two sxts (about 300m) for several days, than Tx locked on 6mbps on an AP and Rx on a client without any real throughput. Restart and downgrade to 6.9 didn't help. It was set to 5Ghz-A/N, 40Mhz, NV2. I've tried to switch it to only A, 20Mhz, 802.11 and different channel, it didn't help. Rx on the AP (Tx on the client) jumps from 6mbps to 90mbps (before upgrade it was 180/180, I've disabled higher modulations) on N and to 54mbps on A.

UPD: Ticket#2014042266000767

On newer releases (or older, same thing) it happens every 1 or 2 hours, on every link that i've tested if the throughput is constant over 40 mbps.
I see this behaviour especially on SXTs, but also on rb711G-5HnD (once in a week or so but this week occured 3 times).

It only happens when running with both chains enabled.

Please contact the support@mikrotik.com to get access to the v6.13rc versions so you could try out the new test RouterOS version which has some improvements for the wireless driver including the new wireless-fp package.

When you are doing the 40mbps test when it goes down does it gets back to 40mbps after some time and if yes how long do you need to wait till that happens?
Also maybe you have some misconfiguration issues, try to reset the wireless configuration and configure the settings you only need and try again.

Maybe you could provide us remote access to your link so we could debug it?

Are you saying that you set up a test link and did btest for hours and didn't saw this issue? In my opinion that's it all it takes to see this *specific* case.

The throughput never goes back once it degrades.
Misconfigurations - I personally think are excluded. 7 links, all of them with minimum settings (n-only mode, nv2, station bridge on client, bridge mode on the AP side).
As power source I use http://www.meanwell.com/search/AD-55/AD-55-spec.pdf , cable runs 15 m - 60 m.

we haven't seen such problem in the test link.
If you could provide us remote access to such link where the problem could be easy to reproduce that would help us to find the cause of this problem and hopefully to fix it as well.

Hi boys!, i'm from Argentina, and i have the same problem with a ptp link with 2 STX.
The bandwitch is going alright for 10.. 15 minutes and then all the traffic go to down. In these moment the Wlan interface is locked to 6.5 Mbps.

I tryed distinct routeros releases, and upgrading the firmware, but i cant fix the problem.

somebody have any news?

i'm Sorry for my bad english.
best regards

oxigeno20, please contact support@mikrotik.com and send us the support output files from both ends. That could help us to understand the problem and how to fix it.
If you could provide us remote access to your link it would speed up the process as well.
How often does this problem happens?

This happen in a 800 mt backhaul link where we connect to the Fiber of Silica Network. We are buying 100 Mb and we need transport these bandwidth with this link.
The bandwidth test is OK, but when i use channel width 20/40, everything's going alright, until every 10, 15 minutes the data rates goes down and get locked to 6,5 mbps; too, the traffic go away.
The only way to unlock this is re-enabling the wireless card. (but the radio link never lost, is like if, i lost the IP connectivity)

Otherwise, when i use channel width 20, or 10 the link works well. But the bandwith is very poor. But at less it isn´t lost conectivity.

I don't have remote access to these link, because it was replaced by two Ubiquitis Rocket 5M.

If you find the solution, we can come back to test again.

Best Regards
Nicolas

This happen in a 800 mt backhaul link where we connect to the Fiber of Silica Network. We are buying 100 Mb and we need transport these bandwidth with this link.
The bandwidth test is OK, but when i use channel width 20/40, everything's going alright, until every 10, 15 minutes the data rates goes down and get locked to 6,5 mbps; too, the traffic go away.
The only way to unlock this is re-enabling the wireless card. (but the radio link never lost, is like if, i lost the IP connectivity)

Otherwise, when i use channel width 20, or 10 the link works well. But the bandwith is very poor. But at less it isn´t lost conectivity.

I don't have remote access to these link, because it was replaced by two Ubiquitis Rocket 5M.

If you find the solution, we can come back to test again.

Best Regards
Nicolas

I would go licensed or 17/24 GHz for such a link. Buying 100MBit and then waste Bandwidth and latency with a TDD link is no good idea.

I'm having a similar problem with a pair of SXT 5nD r2 s. I'm about to put them in the field so I hope a remote fix is possible... Putting both of them on a table and getting them to link, before deploying as a PtP link, I got a signal strength of -41 to -56 (if I *try* to keep it low), but the speed sticks at 6 Mbps both ways. Tx/Rx CCQ is 6/6, but the composite CCQ is more like 74. I have them in NV2 with 20 MHz channels, but tried 20/40, and tried 802.11, and it still seems stuck at 6 Mbps.

Any clues? Thanks.

From ROS 6.11 or 6.12 I never seen this problem (locked modulation to 6,5Mbit)

One of the two radios is at 6.13, the other at 6.17 (I upgraded it when I unpacked it).

Now that it's in the field, the two units about .3 km apart, the link is working at full speed. The signal is actually stronger than it was in the office, since they're pointing at each other. Is it possible that using them indoors leads to multipath problems?

Following up my July post... the two SXTs have been in the field. Until a few weeks ago, they were happily locking in MCS15 or at least close, being dead line of sight 980 feet apart. They don't often carry much traffic as they're a backup link, but help keep the network resilient.
Then about a month ago we had about 8 feet of snow. (Actually, a series of storms, first 3 feet then 2 feet and then more. It's a mess here in Boston. The snow pile is 2-3 feet high after its own compression.) The radios are on rooftops, on sleds, and one of them, on a sled atop a city school, shut down. I suspect a cable problem but nobody has been up there. Both radios are accessible. A few days ago, the failed radio came back to life. The signal strength is -50 to -60 (I actually turned the out put down to +4 dBm since that's plenty.) But instead of MCS15, its mostly converging at 11a-6 Mbps or occasionally 11a-9 or MCS0. NV2 CCQ is 6, 802.11n CCQ is 61.
I've upgraded both units to 6.27, but it doesn't help the speed. Any ideas? Would snow in a Fresnel zone, or near the radio but not in the path, prevent higher order modulation from working? Thanks.

Maybe this problem was solved in old wireless package(to ROS 6.29)
With wireless-fp and wireless-CM2 is problem back (from ROS 6.30). NV2 molulation is locked with latest firmware and latest ROS 6.36.2
Someone with the same problem?