Anyone else experiencing AP's running NV2 that completely stop talking to the Client Radios ?

When this happens none of the Clients are reachable - ping, Mac Ping - fail. Power cycling the client does not resolve the problem. Disable/Enable the AP interface and everything starts working again
Anyone ??

supout.rif sent to support

we would need more detailed info on your Nv2 network so we could try to reproduce it.
How often does it happen?
what usually triggers the lockup - upload/download or some bandwidth testing?

I have NV2 running on 8 AP's now and 10 PtP links. NV2 Distance and Slots vary depending on the AP.

The problem appears to be completely random. It first happened on a PtP link only 13 hours after I installed 5.21 on those two RB's. It has since happened to THAT PtP again, and another one as well.

All of the "AP's" that have had the problem so far are running as a router, no bridging.

The most recent one (that I sent you the suppout.rif from) has 42 connected clients. Radius Auth. for Wireless. Radius DHCP. Nv2 Period=4, Cell Radius =10. No NV2 security. Card is an Atheros 5413. RB is a 433AH. Uptime since upgrade to 5.21 is ~4 days 7 hours. ALL on this AP clients are also 5.21.

You can email me at the address from ticket [Ticket#2012102366000597] if you need further info.

Thanks.

please try to lower the tdma-period-size to 2 on the AP and check again.
The AP and the Clients uses the legacy AR5413 chipet cards?
What wireless mode you use for the wireless clients: station, station-wds or station-bridge?

Period size on the point to points is already set at 1.

If I set the period to 2 on an AP with 42 clients it takes them a very long time to re-associate (5 or more minutes) if they drop

Sorry posted too soon.... All clients are Station mode. I'd say 90% of the customers are R52H. Remainder are R52Hn or RB Groove 2hn.

Z

The same problem with my AP which you have remote access. [Ticket#2012062266000221]
The problem occurs randomly (even just once a week). No BW test running.

What type of Card do you have in the affected AP? Are you running the AP with B/G or G only ?

I'm having same problems on grooves and metals. Random reboots, disconnects and other crap like that. To make things even more fun, after /system package downgrade metal went bye-bye. Feels like 2.9 all over again

This isn't a reboot problem. The AP side just stops talking to the CPE's. CPE's are mostly R52H on RB411. I have probably 30 Grooves as CPE's running 5.20 or 5.21 and no issues with them. No Groove AP's though. Other than this issue 5.21 has been very stable - and latency and jitter are way better than previous versions of NV2.

Well, I replaced a groove after upgrading it to 5.21 with Metal. Now co-worker gets on the mast to replace metal with another metal. Either two devices were broken, or 5.21 is broken. I'm not planning on uploading 5.21 again. Metal is now confirmed dead after attempt to downgrade 5.21->5.20 - ethernet doesn't even come up...

I have no metals - just the older style 2Hn grooves.

BTW: Isn't the Metal just the mipsbe ?

I don't understand your question.

The Metal is just the groove in a steal case is it not? The Groove is a mipsbe board. mipsbe is the platform for the RB4xx.

Yes, that's correct. Not sure about any subtle hardware differences, but it's mipsbe. Oh well, sent some supouts with wireless lockups, maybe it will get fixed along that

can one of you provide us remote access to such AP where the Nv2 stops working - needs disable/enable, as we can't reproduce this problem locally?

About Metal downgrade from v5.21 to v5.20, what packages you used and what bios firmware version you had?

Done - please see your email for the ticket.

BTW: Yesterday overnight I tried setting the TDMA slots to 2, but could only authenticate ~24 CPE's. The status Tab showed "Connected 42, Authenticated 24". I cache radius responses for 2 minutes. Radius resends were low but the other ~18 CPE's could not authenticate (?) In the end I could only lower the slots to 3 and still have all subs authenticate.

ULDIS:

It it currently broken. If you wan in you have 5 minutes before I reset it.

I sent TWO supout files via Email. Please advise if you think this problem would be resolved by replacing the b/g card with a b/g/n card ????

Today i had a 2 minutes "outage" because a SXT->OmniTIK link did not pass any traffic for about 2 minutes. the connection was not dropped and other clients were able to pass traffic w/o any problems. Signal is -55dB (only short range)

After that the link passed traffic again

All devices run 5.21 with nv2

That happened to me on two PtP links. I wrote a Quick script to check the interface and disable/enable the ENTIRE interface when failure is detected. It runs every 90 seconds under scheduler. You could do faster but you need to account for script delay and ping reply time or it'll just reset continuously.

Insert the IP of the other end of the link in place of IP.of.other.side below. Set wlan2 to the Interface you need to bump. Change <Link Name> to something meaningful, and change the destination email address - you must have /tool email configured and working of course.

:if ([/ping IP.of.other.side count=5]<2) do={ /interface disable [find name=wlan2]; delay 2s; /interface enable [find name=wlan2] ;delay 5s; /tool e-mail send to="you@your.domain" subject="<Link name>stopped responding and was reset"; delay 2s; /log info ("Interface <Link Name> Not Responding - Reset at " . [/sys cl get time] . " " . [/sys cl get date]. " Email sent")}

I am NOT running this script on the AP that has the issue that started this thread. MT is Remote accessing that and debugging that one separately.

This is NOT a solution to the problem, but a temporary kludge.

So far I haven't had this issue on any AP's or links running b/g/n or a/n cards, only on R52h, SR5 and XR5

We have same problem with NV2 instability. Our config is PtP link with both sides similar - rb433AH+r52Nm+Jurios24Duplex. Link up time was 2 days with CCQ 100%, but today i saw situation - client connected, but no traffic passed via wireless link until disable/enable interface.

My 'problem child' AP just kicked up a fit again... I have another supout.rif file for you Uldis ;-D I'll send via email.

I also noticed that if I disable/enable the interface too quickly the CPEs don't ALL re associate. In this case there are 42 CPE's on this interface and only ~26 came back when I disabled for only 2 seconds. Disabled again and waited for ~10 seconds and re-enabled and bang 42 CPE's again.

The domed cap's were a big problem on RB450G for me. Lost 12 boards in the space of 8 months. Found that if I powered them with 18VDc across the power adaptor plug it wasn't an issue, but using the 24VDc POE into port one they would blow the caps. As a matter of fact I did loose two RB493's early on the same way. But I've never seen that with the RB433AH - which s what this one is - and I have a few dozen of them in the field, some at 3+ years.

BTW Uldis - if you're reading this - it blew up again this morning. Interesting this time that it stopped working for 40 minutes and then came back for 20 minutes and then stopped for 40 and came back for 20 and stopped again - then I finally disabled/enabled the interface and it's back to normal now.... that's a different symptom than before. I'll send the supout via email.

Z

Uldis, please contact me over XMPP at your leisure, JabberID p@75.pl.

As to your firmware question, I was at 3.0 and downgraded 5.21 -> 5.20 with main mipsbe package.

Uldis, please contact me over XMPP at your leisure, JabberID p@75.pl.

As to your firmware question, I was at 3.0 and downgraded 5.21 -> 5.20 with main mipsbe package.

we only offer email support, so please write to support@mikrotik.com if you have issues.

I was referring to your ssh request. Luckily for you, I offer free-of-charge jabber support

Hello Uldis.

A DIFFERENT AP, basically the same hardware configuration, all running 5.21, same issue. I've sent two supout.rif files to support on the existing ticket

Z

The problem child kicked up a fuss again. Two supout file sent via email. They are also still on the AP.

Z

Edit: cancel that - I'm an idiot and too tired to read
Z

The Metal is just the groove in a steal case is it not? The Groove is a mipsbe board. mipsbe is the platform for the RB4xx.

you kidding me? metal is the most power CPE made, up to 31db TX power!!! Big difference from the groove...

It's still a mipsbe board is it not ? That was my point.

everyone who has problem please email support@mikrotik.com for a test release that most likely will fix this problem with Nv2 AP stopping.

uldis, will it be enough to update the AP or does the client(s) need update aswell?

Regards,
Joerg

Required on Both AP and ALL CPE's

Anyone updated to that test release and could tell us if this issue is fixed?

Anyone updated to that test release and could tell us if this issue is fixed?

So far, 8000 pings, zero drops.
AP = RB800 with 3 R52Hn cards in AP Bridge mode, A/N, NV2
CPE = RB711-5HnD in Station Bridge mode, A/N, any
-55/-51 tx/rx signals, 130Mbps/130Mbps rate
30Mbps down steady tcp speed test
80Mbps up tcp speed test, started at 2Mbps then got faster. Is this correct?


I was dropping pings to the CPE, 5 to 10 in a row, at random intervals. It would not lose the wireless connection, just drop pings / stop passing traffic.

Uptime 7 hours, I'll let you know if anything changes.

Anyone else with positive feedback?

Having the same problems with multiple links. Some PTP and some are PTMP, running 5.22 and also 6.06rc6.

[Ticket#2013011866000013]

The same problem today. AP BRIDGE 5.22, all clients 5.22.

Supout.rif send to support

I have seen this issue with both PTP and PMP links. The PTMP only stops on my OmniTik with 15 SXT CPE's. My other PTMP systems (RB711GA-5HnD's) have never had issues. PTP links over SXT's are the only problem units with my PTP links using RB711's do not have issues. Sounds like a fix is being worked on though. I now build my own units for AP's and PTP links.

These issues happen more during the summer months with things stopping every 1-3 days on the units mentioned above. Now that it is winter with temp like -35C (just the other day) I have not had this issue nearly as much (only every month or two). I am currently running 5.22 on everything but have had this issue since 5.14

We have experienced the same problem on 5.22 and even on the 5.23 pre-release.
Sending multiple supout.rif's to Support.
No fix yet.
Getting frustrated.

We have written a script to disable/enable the wlan card that locks up.....but it is not foolproof.
Mikrotik, please give this issue adequate resources to fix it ASAP.
Our customers don't like being offline.

also being member of the crew, with the same problem.
http://forum.mikrotik.com/viewtopic.php?f=7&t=69064

Joining the bandwagon.

viewtopic.php?f=7&t=69224

MikoTik support just sent me the 5.23 package. I'll be trying that next.

rb800 + v6.0rc9
Same problem... something new? disabling and enabling interface works but is not-operative.
Help, help... I´m loosing customers

The same problem today. AP BRIDGE 5.22, all clients 5.22.

Supout.rif send to support

hello?

The same problem today. AP BRIDGE 5.22, all clients 5.22.

Supout.rif send to support

I had problems with V5.22 and went back to V5.20 - OK now - I can only say try a version which works for you and like others say here don't automatically upgrade to newest version on a live production network but test elsewhere on your network before upgrading?

Has mikrotik any anwer to this issue? Nothing to say? It seems a wellknown problem..

this is an old topic, please upgrade the AP and the client to the v5.24 and if you still have problems report to the support@mikrotik.com

Same problem for me, too... Something new? Disabling and enabling interface works but is not-operative.
My equipment it's a Mikrotik SXT G-2HnD - v5.25

well, i still not brave enough to upgrade the production APs to 6.x, so the only solution what i found is scripting.

There are several script exist for fixing this issue (what happens to me even with 5.24, 5.25, and 5.26 version, luckily, very few times)
what
a) ping specific host and disable/enable the interface if unable to ping (select the client with highest uptime!)
b) watching the changes of packet counters. if there is no packetflow in a direction it restarts the interface.