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.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.
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.
the script uses our database so it is not usable outside our company.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.
Let us know by writing to support@mikrotik.com when you have found the wireless links that experience this problem very 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.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.
Wireless layer - funkcionality is very very important. Now we use NV2 everywhere. But this know issue is very annoying.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.
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.
I have some stations which lock near every day. But most of them are RB112/133.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.
When you look at these RB112/RB133 do they show locked down rate? I've seen higher rates on CPE than on AP.I have some stations which lock near every day. But most of them are RB112/133.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.
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
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).When you look at these RB112/RB133 do they show locked down rate? I've seen higher rates on CPE than on AP.
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...Hello. Any news? Give you remote access for support?
note: you need inspect Last Measured times on client not on APNow with uptime only 22days. P2P link is locked to 6,5Mbit. Customers call - speed is terrible
Yes but what is solution? In configuration P2P links is problem on AP side. Disable/enable wireless solve this problem.note: you need inspect Last Measured times on client not on APNow with uptime only 22days. P2P link is locked to 6,5Mbit. Customers call - speed is terrible
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.Yes but what is solution? In configuration P2P links is problem on AP side. Disable/enable wireless solve this problem.note: you need inspect Last Measured times on client not on APNow with uptime only 22days. P2P link is locked to 6,5Mbit. Customers call - speed is terrible
When you have locked clients - what is solution? Reboot (Disable/enable) AP or just reboot client?
I know it. But this is not solution of problemto '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.
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 frequentlyHave 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
With 6.5 the same issue. Today reported to supportwe 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.
[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!
yes, I can confirm everything you wrote.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.
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.Now we have no problem with 6.5 and 6.6.
if you want to detect the problem without too much false positives you really have to: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
}
}
So are you saying you think it a hardware issue only affecting certain hardware?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
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.So are you saying you think it a hardware issue only affecting certain hardware?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
on the pictures you attached there is nothing typical to NV2 locked modulation state. If the link modulation is locked the 'station' side shows thatNow 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
From 6.8rc1 we have no problems. It is amazing to hear that you are the sameIn 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).
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.Thanks for the responses guys, care to comment on this capture then?...
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.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".
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.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.
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).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.
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'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.
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'tI 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?
[/quote]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
Upgrade to 6.11 http://download2.mikrotik.com/routeros/ ... e-6.11.npkUntil 5.22 the link between my two SXT's with both chains activated
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.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.
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.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