Hello Guys,

I'm interested if anyone run into this issue:
Wireless card stops transmission (counter stable stays on 0), but receiving works.
If i disable/enable the wireless card, datas flow again.

It happened with:
RB411AH, ROS5.18 and 5.22 (this board reboots with kernel failure as well, few times a day)
AP mode, MIMO, 20mhz, nv2, a dozen of clients. Now ping watchdog set to one of the clients

The following are in P2P setup
RB433AH(with mikrotik card) and MetalTik. one with 5.16 other with 5.18
nv2 as well

I have no ideas what can cause this, and what can fix. Nor of other APs (yet) did this.
I would even welcome and idea for script this thing.

if anyone has any tips how to detect the stopped TX in script, i would be thankful!

ps: ticket already assigned, but got only automated reply.
Ticket#2013011666000759

The problem with your 411 might be related to power supply issues. The remaining problems could be down to a shaky installation. If you are certain that it's not hardware related, then it's might be worth upgrading the software on each device to the same version. You might also run a quick check to detect if there are no rogue DHCP servers on your network.

You could set up a script which will check for 20 seconds if there is any tx trafic. If no trafic for 20 seconds then restart the interface. However you should nail down the problem instead of trying to find a workaround.

Ohara: right.
finding the problem is more important than finding a workaround.

What i tought is make a script what check the tx packets five to ten times in a row (between few second diff). Log them all, and if sum is 0, than disable/enable.
Maybe you have better idea?

Power supply is a UBNT Toughswitch 5port. 2 or 3 other devices on it, and works well. The other devices are same 411AH or 711.

this should not be a power issue. Just seen on a very stable AP, what has 3 cards. 2 running nstreme (p2p) one sector with NV2.

so i bet this IS as NV2 issue.

The kernel problem might be power or hardware issue. If you don't want to take down the RB then you might erase the config and set up again or try to disable other devices on you poe switch and see if it makes a difference.

As per wireless disconnects, did you get a response fron support? I have seen some other threads about the same issue recently and it is certainly about nv2 and ptmp, unless you have observed it in ptp.

Ohara: there are 3 pcs of 411AH on the toughswitch. It can provider 5x12W
i think, 411AH + wireless does not eats more than 8-10W

The support responded to replace/re-netinstall.
I also can confirm it's an NV2 issue. It's just happened on another AP what has 3 wlan cards. 2 of 3 are nstreme, p2p
the 3rd one (what stopped) running NV2 multipoint. That AP is running since 72 days.

Never happened with nstreme.

Sounds like it is the same issue in this thread:
http://forum.mikrotik.com/viewtopic.php?f=7&t=66642

+1

Wasn't able to determine whether it was the SXT or the Sextant, radio remains registered but unable to pass any traffic.

Both units using 5.22, sextant 1 month old and sxt 6 months, but both fresh out the box.

@wpeople: Personally I am not facing such issues on our end, but I experienced them some time ago. Here is a simple script that should reset the interface when there is no traffic for 10 seconds. It's a workaround and it does not resolve the problem though. Feel free to test it.

@beeski: do you have a similar script which you could possibly share?
EDIT: remove abbreviation for 'monitor-traffic', change log entry type

Easy way u can enable watchdog just put watch-address - ip of client

I m not sure if MT is still working on this problem..?

watchdog forces reboot, who wants to loose the connectivity for 45 secs + watchdog period when the script could do it far quicker.

However, a good explanation of the script would be useful to us all and I cant wait to start using it (as soon as I fully understand ALL the parameters)

When I was facing the problem, it was enough to re-enable the wireless interface on any CPE unit. Thereafter the traffic on all other CPE's would be restored. Theoretically it would be enough to launch the script from task scheduler on a CPE, but I don't know if the current issues are similar to mine. I have added comments to explain the script:
EDIT: remove indentation, remove abbreviation for 'monitor-traffic', change log entry type, update comment

Brilliant! thanks.

Script is installed, but the wireless card is up for 5days 2hrs (411AH, running ROS 5.22).
What is strange, the longest uptime client (5days 2hrs) is a non N client.
the rest are:
1d 17h
17h24m
1h37m
1h24m
1h8m
1h3m
52m
22m
20m
16m

On AP side: control frame timeout logged
on client: lost connection, medium-access timeout

For everyone with this problem. Try latest 5.23rc1 with fix
http://www.mikrotik.com/download/share/ ... .23rc1.zip

For everyone with this problem. Try latest 5.23rc1 with fix
http://www.mikrotik.com/download/share/ ... .23rc1.zip

We are testing 5.23rc1
So far, so good.

how many days of uptime?

I have a rb711 g5hnd that have been running flawless for some months but in last couple of weeks I hade some kernel failure whit reboot.

Running a AP whit nv2.

My response from the support was that the wireless process was interrupted any they linked me to 4.23. And now it is 4.23rc1?

Should I apply this? Is it working?

maybe 5.23 not 4.23
as you see above, in the first times, my AP was rebooted (or stopped) with 5.22 - and now working well since 6d3h (thas is a longest uptime client, since ap reboot).
So it should be now hardware problem.
Since the ROS 5.23 (rc) is not public and sent us within a week, i cannot tell you that is a solution.
What IS a well working workaround: set watchdog to your uplink router IP AND install one of the scripts above. That will reboot the AP if got stucks, and restart wireless if it stops.

5.23 is older build. Try latest 5.23rc1 from 25.January.

If you have 5.23 instaled, then put package 5.23rc1 and then run command /system package downgrade

lockup with AP and CPE's on 5.23rc1
supout.rif sent to support

RB800 AP
wlan1 is r52Hn
CPE's are 711's

doh, i meant 5.23.

but I have never suffered of lockups, only whit kernel failure? And when it gets kernel failure it reboots.

And as I said earlier it has run flawless for some months, until now.

Today they have released 5.23 (2013-Jan-29 14:07), anyone knows if they have fixed it? should I upgrade from the release I got last week?

Today they have released 5.23 (2013-Jan-29 14:07), anyone knows if they have fixed it? should I upgrade from the release I got last week?

No changes (about freezing) in changelog. The only way. Testing and testing

And I that always thought that mikrotik tested their routeros before lunching

new error found:
AP is 411AH, mimo, nv2, N-only
11 clients connected. one client stopped, but still connected.
even mac telnet not works.
this client had same link uptime as AP (all others was re-connected since reboot already).
client does not respond, but after remove (kick off) he joined again, and data flowed again.
he has torrent client, so traffic is continious to/from him -> must not be timeout or something.
maybe buffer overrun somewhere in nv2?

his traffic on eth (so on wireless since reboot, ~6.5days):
tx (to client): 33gig 79.2 million packets
rx (from client): 15gig 55.5 million packets

maybe useful info.
ps: AP is 5.22, all clients are 5.18

new error found:
AP is 411AH, mimo, nv2, N-only
11 clients connected. one client stopped, but still connected.
even mac telnet not works.
this client had same link uptime as AP (all others was re-connected since reboot already).
client does not respond, but after remove (kick off) he joined again, and data flowed again.
he has torrent client, so traffic is continious to/from him -> must not be timeout or something.
maybe buffer overrun somewhere in nv2?

his traffic on eth (so on wireless since reboot, ~6.5days):
tx (to client): 33gig 79.2 million packets
rx (from client): 15gig 55.5 million packets

maybe useful info.
ps: AP is 5.22, all clients are 5.18

Today i had an very similar issue. In my case setting the adaptive-noise-immunity=none solved it.

Disable ANI on client(s) or on AP?

new error found:

ps: AP is 5.22, all clients are 5.18

Try upgrade AP and all clients to 5.23. Then see if problem persist

can you explain why? there is no wireless fix (noticed) in 5.23

can you explain why? there is no wireless fix (noticed) in 5.23

the changelog was missing the nv2 improvement entry. We have fixed it.
You need to install v5.23 on the AP and on the Clients.

can you explain why? there is no wireless fix (noticed) in 5.23

the changelog was missing the nv2 improvement entry. We have fixed it.
You need to install v5.23 on the AP and on the Clients.

Uldis, have the same wireless fix 6.0rc8? For our clients which using older 6.0rc
Thanks

sadly i have to report, that 5.23 does NOT fix the NV2 lockup issue.
all but 1 clients running 5.23 (the remaining 1 is running 5.18)

turn off/on script do the trick. hey Mikrotik, Go On with it! (at least do wireless restart inside the protocol if no transmission is detected for a bunch of frames!)

The same in my case. ROS 5.23 don´t solve this problem. Interface still freezing.
[Ticket#2012122166000702]

Hi all,
How to run this script? In scheduler? When run this script in logs show 10 warnings.
Thanks for help
Art.

Had to quickly apply your script this morning... The wireless interface on Sextant froze up, second time since new ( 3 months)

Netwatch sent me an email just after midnight, but I forgot to redirect the email to a server to convert to SMS.

Customer rang phone early AM to alert me to problem.

Anyhow, there are a couple of problems with the script. Firstly a command error in the line

/interface monitor $iface once do={

it should read
/interface monitor-traffic $iface once do={


And secondly: I didn't get the commented version to run at all... Maybe you can take another look at that one.

The un-commented script runs fine with the corrected command.

Thanks for the script

Simon

ok...

Now I see other issues.

I have set the scheduler to run the script every 20 seconds, and I get 10 log entries prefixed in blue by script warning 1 -txrx blablabla

I assume this comes from line

:set txrx ($txrx+$("tx-bits-per-second")+$("rx-bits-per-second"))
}
:#log warning ($i . " - txrx: " . $txrx)

But why is it set txrx?

why the warnings?

The monitor-traffic command has been updated as per your advice and tabular indentation has been removed. It seems like ROS does not like when tabs appear before comments. I have updated the script in the initial posts. Thanks for the valuable feedback.

:#log warning ($i . " - txrx: " . $txrx)

The idea was to use the blue warning log entries for debugging purposes. If all 10 log enries indicate 0 traffic, then the interface is restarted, which is also confirmed with a blue log entry. Changing ':log warning' into ':log info' results in a standard log entry. However, when the script is launched every 20 seconds I would remove that line completely, so that the logs remain clean.

Mikrotik Support: any fix on that?

others: i'm using the ping-script for restarting interface on AP, but sometimes individual clients just stops - so pinging 1 or 2 specific clients is not a bulletproof solutions.
Pinging every client as a watchdog, well, i would not call it a solution.

Should i install the script on every client as well?

Try 5.24rc1 http://www.mikrotik.com/download/share/ ... .24rc1.npk
It works for me

I would suggest users who has problems with the Nv2 lockups to upgrade the AP and the Client to v5.24 and report how it is working.

We have the same problem right up to ros6rc10 but only when we do 30mibs or more on tx and rx

The AP what's usually locks up make me this screen:

Please compare the used cpu in top left with profiler. If process IDLE is using up all the resource, how to kill it?
(ok, i know what does idle means, but where the bug is?)

The AP what's usually locks up make me this screen:

Please compare the used cpu in top left with profiler. If process IDLE is using up all the resource, how to kill it?
(ok, i know what does idle means, but where the bug is?)

Hello wpeople. I have the same problem. CPU show bad values when AP lock up. Both sides have 5.24. Problem with freezing (lock UP) still persist. [Ticket#2012122166000702]

wpeople,

please upgrade your wireless clients as well to v5.24.

Uldis: no problem, i will do.
But really a station can cause AP to freeze???

No, it is not problem with clients. We have PTP link. Both sides 5.24 with NV2 and it FREEZING

same, same problem!!!
mt team, any solution? I cant afford this...

until they find a fix.

Use netwatch to ping the adjacent service, after ping fails for say 4 secs, trigger script to disable/enable interface.

Or use the other script examples above.

Really I know its a headache but my script runs all the time and only changed the interface state once in the past 4 days... Unless the clients are on the phone or watching video etc, the chances are that they may not even notice the break.

My time out is set at 10 seconds and it took 5 secs for the interface to be disabled/ enabled and the associated station to reconnect.
Total outage time is 15 seconds.

you could get this down to say 8 seconds if you modify the netwatch timeout to 3000ms.

PS set the station scanlist to the same frequency of the AP, so that it doesnt waste time scanning and aslo set the mode to either NV2 or nstreme or whatever it is that you are using.
The faster you can get the station to reconnect the better.

8 seconds is not such a big deal every few days, unless they are on the phone!! At least until a fix is found.

I also put the same script in the station, but with a different timeout value so that there is not a "race" condition with the AP.. Else the AP will disconnect, then the station will disconnect etc etc.

At present it just seems that its the AP/Bridge end which is the problem.

I've never seen this problem in our live network

Did some performance testing with 5.24 in lab today. After increasing TDMA-Period Size from 2 to 10
I get this problem after a short time of running Bandwidth test through the test link.

With TDMA-Period Size = 2. I never get this problem.

So you guys who see this problem: What is your TDMA-Period Size?

For those who experience the Nv2 lockups:

Please make sure that the AP and the client uses v5.24 and do the following steps, those will help to detect the problem and to find a fix for it:
1. Wait till the nv2 stops working
2. Make support first output file on the AP
3. When it finishes making, make a seconds support output file (without changing
any configuration to the router)
4. Remove the wireless clients from the registration table
5. When wireless client connects back to the AP make a support output file on the client
6. Send all 3 files to support@mikrotik.com

For those who experience the Nv2 lockups:

Please make sure that the AP and the client uses v5.24 and do the following steps, those will help to detect the problem and to find a fix for it:
1. Wait till the nv2 stops working
2. Make support first output file on the AP
3. When it finishes making, make a seconds support output file (without changing
any configuration to the router)
4. Remove the wireless clients from the registration table
5. When wireless client connects back to the AP make a support output file on the client
6. Send all 3 files to support@mikrotik.com

Sent 3 supouts. Problem did not show up with 20MHz Channel and did not show up with TDMA-Period Size=2.
test done with RB411AH/R52nM and 1x SXT 5Hnd.

only to comment that my problem is only my card give up tx then if :set txrx ($txrx+$("tx-bits-per-second")+$("rx-bits-per-second")) doesnt work for me...
I changed to :set tx ($tx+$("tx-bits-per-second")) and it works fine

i have this problem in Metal 2shpn . i hate my life when i get Metal

can any one give me full script to make wireless card disable and enable again when TX & RX get 0

i had same problem. 6x p2p links sxt on both sides, misc configs: 802.11/nv2/20-40MHz, newest ros 5.24 and bios,
distance 200-1500m and my sxt lockups (very often at max traffic, max mbits/packets, 3-29mbit,).
i watch that lockup are less at low traffic. disable/enable wlan when interface lockups "repairing/starts" traffics.
mikrotik do somthing with this bug!

I am having this problem now and it is causing a bit of complaints. The link will just go to 6.5mbps on the TX side and won't pass traffic faster than about dial up speed. Reconnecting the client does solve the problem till it happens again. It is random. could take 3 days could happen after an hour.

I only had this problem after upgrade from 5.20 to 5.24. Im going to try to downgrade tonight as I never had the prob with 5.20 use rb600 and rb800 btw.

Also to add I do have the prob with TDMA-Period Size = 2

i had same problem. 6x p2p links sxt on both sides, misc configs: 802.11/nv2/20-40MHz, newest ros 5.24 and bios,
distance 200-1500m and my sxt lockups (very often at max traffic, max mbits/packets, 3-29mbit,).
i watch that lockup are less at low traffic. disable/enable wlan when interface lockups "repairing/starts" traffics.
mikrotik do somthing with this bug!

Can you help with this problem?

For those who experience the Nv2 lockups:

Please make sure that the AP and the client uses v5.24 and do the following steps, those will help to detect the problem and to find a fix for it:
1. Wait till the nv2 stops working
2. Make support first output file on the AP
3. When it finishes making, make a seconds support output file (without changing any configuration to the router)
4. Remove the wireless clients from the registration table
5. When wireless client connects back to the AP make a support output file on the client
6. Send all 3 files to support@mikrotik.com

Has anybody tried disabling MCS 0-4 in configured rates? I just wondered if it would stop the link going bad as whenever I have seen it happen it's stuck on the low rates.

I would say it's traffic related. It seems to affect me when throughput is high 30-50mbps

I am pretty sure disabling the mcs 0-4 has not solved the problem but it has made the wireless disconnect and reconnect rather than hanging.

I guess that can only be done on strong links but it may help as a workaround. I am going to try downgrade back to 5.20 tonight when network is quiet.

For those who experience the Nv2 lockups:

Please make sure that the AP and the client uses v5.24 and do the following steps, those will help to detect the problem and to find a fix for it:
1. Wait till the nv2 stops working
2. Make support first output file on the AP
3. When it finishes making, make a seconds support output file (without changing any configuration to the router)
4. Remove the wireless clients from the registration table
5. When wireless client connects back to the AP make a support output file on the client
6. Send all 3 files to support@mikrotik.com

if anyone can write script to do these 6 steps at ap and client side when mikrotik lockups...

i cant wait for lockups and do these steps, until now i set watchdog to reboot bridge at client side, now i set workaround that disconect client after 3 lost ping.

has anyone else noticed that a "standard" netwatch script is not working. ie the script is not running from the netwatch facility, however if the script is run manually, the script performs disable/enable OK.

It has happened to me three times now, but again I forgot to notice if the CPU was maxed out at the time the interface stalls.

Reverting to commands written within the scheduler instead to see if same problem exists.


MT.. When will we see a fix on this issue???