Community discussions

MikroTik App
 
troy
Member
Member
Topic Author
Posts: 310
Joined: Thu Jun 30, 2005 6:47 pm

RB Metal AP stability

Wed Jun 26, 2013 4:50 pm

All,

I've got a site with 3 Metal 2.4Ghz Access Points. All 3 were running 5.25 with 3.07 firmware. They're attached to 15db sector antennas. One unit has 17 clients, another has 9, the 3rd is empty at the moment.

The wireless process on these units is locking up at 50% CPU, dropping all clients and not allowing any client to register. In fact, the AP isn't even visible when this happens. Only a reboot will fix this issue.

We've tried both 802.11 and NV2. We've tried b/g, only g, and b/g/n. We've tried default data/mcs rates, we've tried various custom rates.

Most recently, we upgraded to 6.1 and brought the firmware down to 3.02. Still no luck with any combination of settings.

We've been the same configurations using the R2SHPn on various 433 boards without issue. I'm suspecting there's an issue with the chipset used in the Metal that's causing this, but MT doesn't seem to want to entertain this idea.

My question here, is if anyone is running Metal 2.4Ghz APs without issue? If so, can you share your wireless configuration?

MT ticket #2013060966000316. Initially got a couple responses. Last email sent to MT was on 6/14 with no response from MT in the last 12 days.

Thanks,

-Troy
 
letabawireless
Frequent Visitor
Frequent Visitor
Posts: 63
Joined: Thu Jul 26, 2012 5:11 pm

Re: RB Metal AP stability

Wed Jun 26, 2013 5:54 pm

Hi

Same behavior, we have 2 x Metal 2.4 Grooves with exactly the same sypmtoms. The 5Ghz Metal Grooves on the same mast, seems stable. So it can't be a power issue. We have resorted to using 433 with RB52Hn cards; seems the Metal 2.4 is NOT a high site unit.

Thanks.
 
cuvsaran
just joined
Posts: 1
Joined: Sat Oct 31, 2009 11:30 am

Re: RB Metal AP stability solution is here

Sun Jun 30, 2013 10:33 am

hi

if you use encryption dont use it. please follow access list because metal not supporting with wpa/wpa2 because the logs shows group key exchange time out. after i remove the encryption.its well working with great performance
 
User avatar
ShayanFiroozi
Member Candidate
Member Candidate
Posts: 284
Joined: Sat Jun 01, 2013 12:44 pm
Location: Bandar Abbas , Iran

Re: RB Metal AP stability

Mon Jul 01, 2013 7:59 am

Hi
Metal is a very good equipment , but in my opinion you used it in wrong place !!

Metal is 31 dbm high power radio , perfect for long range and long distance but not good for hotspot or multipoint links.
Metal has only 400 mhz CPU and 64 MB ram.

you should use use a board with powerful cpu and ram like RB 435G or RB 800 , with a stable wireless Card , like XR5 , SR71-15

if high power equipment like Metal use in short link its high power makes your link unstable and poor throughput.

most of the time more power = more distance not more throughput !! if you can not replace Metal , reduce its power , but when many users connected to it , its CPU and Ram can not support all of them , that's why it hangs !
The price of your knowledge which you have to pay is to share it with others !!
 
troy
Member
Member
Topic Author
Posts: 310
Joined: Thu Jun 30, 2005 6:47 pm

Re: RB Metal AP stability

Thu Jul 04, 2013 7:04 pm

Hi
Metal is a very good equipment , but in my opinion you used it in wrong place !!

Metal is 31 dbm high power radio , perfect for long range and long distance but not good for hotspot or multipoint links.
Metal has only 400 mhz CPU and 64 MB ram.

you should use use a board with powerful cpu and ram like RB 435G or RB 800 , with a stable wireless Card , like XR5 , SR71-15

if high power equipment like Metal use in short link its high power makes your link unstable and poor throughput.

most of the time more power = more distance not more throughput !! if you can not replace Metal , reduce its power , but when many users connected to it , its CPU and Ram can not support all of them , that's why it hangs !
For hotspot or any indoor wireless, I'd never use these radios. I would use any radio at 17-20db Tx, and 3-6dB antennas. It's very likely that I wouldn't use any MT solution for the APs in such an environment.

For any PTP or PTMP solution, why would you need more CPU or memory? Look at the RB711G-5HnD. Same CPU, half the ram. It pushes 160Mbit/s with ease. PTP/PTMP makes no difference, the time slotting on the radio happens outside the CPU.

You are right that the SHPn devices (Metal or mPCI) were marketed for long hauls, but they'll also let you reach the limits in a PTMP configuration.

I would never do a 2.4Ghz long haul PTP, but the math is pretty simple. Start with a 29dB antenna and a 2dB cable loss, restrict your TX power to about 23dB, and you end up with a max EIRP of 50dB.

In a PTMP application, start with a 15dB antenna, take out 2dB line loss, restrict Tx power to 23db, and you're at the 36dB max EIRP.

Compare this to the R52Hn. 2db less tx, and 6db lower Rx. This means that the SHPn has a total of 8dB better margin to work with.

I do love the XR5, but this doesn't support 802.11n. The SR71-15 at MCS7, is 19/-75. This is gives a margin that is again 7db smaller than the SHPn, and gives a max EIRP of just 32dB, 4dB short of the max EIRP.

Here's a real life case study... I had a cell driven by a cm9 with a 12db omni. We had nothing but trouble reaching clients above the AP (the antenna has a 7* beamwidth with a 3* downtilt). Anyways, we maximized the potential of this site by replacing it with a R2SHPn and a 9db Omni. This give us an EIRP of 29dB @ MCS7 and great vertical coverage (-7 to +7), and a much better Rx sensitivity. If needed, we could have even better vertical coverage with a lower gain antenna.

Now, tell me again why the SHPn is unsuitable for a 2.4Ghz AP?
Last edited by troy on Thu Jul 04, 2013 7:41 pm, edited 1 time in total.
 
troy
Member
Member
Topic Author
Posts: 310
Joined: Thu Jun 30, 2005 6:47 pm

Re: RB Metal AP stability

Thu Jul 04, 2013 7:34 pm

We finally replaced our Metals with 433/R2SHPn combos, which is about 3x the cost, but is working great.

I finally did get a response from MT about the metals. Uldis said the supout shows the it was unable transmit and unable to reset. He's thinking that changing the adaptive-noise-immunity might work, but it's too late for us to try.

Taking a critical look at this, you can see that the Metal2 and Metal5 are using the same chipset. The only difference, as I understand it, is the RF modulation to get to 2.4 or 5Gzh. The Metal 5 works awesome, the Metal 2 does not.

The R2SHPn works great, but is a completely different chipset than the Metal, which means that it's RF modulator is likely different as well.

I'm thinking this is an Atheros problem, not a MT problem, but won't know until MT does some in depth testing to figure it out.
 
diablonet
Frequent Visitor
Frequent Visitor
Posts: 53
Joined: Wed Jan 05, 2011 3:33 am

Re: RB Metal AP stability

Fri Jul 05, 2013 10:58 pm

Thank you Troy for pointing me about this thread, well I have 4 Metal2SHPn, exactly same settings, adaptive-noise-inmunity is set to ap and client, what support suggested about this?

If settings were a problem now, why 2 works and 2 dont!

Wifi card is unreliable, exactly as you described!
 
diablonet
Frequent Visitor
Frequent Visitor
Posts: 53
Joined: Wed Jan 05, 2011 3:33 am

Re: RB Metal AP stability

Fri Jul 12, 2013 3:22 pm

Just to report, I contacted support [Ticket#2013070566000876], they suggested to disable the b rates and using only g and n rates, which didn't worked, also I tried ONLY-G mode, it didn't worked also.

I bought 4 devices, all of them same settings and installation, 2 work, 2 fail, which suggest that its not a configuration issue, there must be something else, please help Mikrotik!
 
User avatar
ShayanFiroozi
Member Candidate
Member Candidate
Posts: 284
Joined: Sat Jun 01, 2013 12:44 pm
Location: Bandar Abbas , Iran

Re: RB Metal AP stability

Sun Jul 21, 2013 12:20 pm

You are right troy . i mean Metal is not a Heavy Load AP(Wireless + Ethernet) , MT has a chart that we can choose out best equipment for each scenario , i think just RB435 and RB800 are Heavy Load Multi AP for industrial use and high traffic , in my opinion u can achieve 200mbps with Sextant but its not for Heavy use
The price of your knowledge which you have to pay is to share it with others !!
 
earljack
newbie
Posts: 40
Joined: Thu Jan 22, 2009 7:34 pm

Re: RB Metal AP stability

Tue Dec 17, 2013 12:01 pm

I can confirm this issue. I have a METAL that disconnects all clients, and has it's wlan interface completely stop working. A scan wont even show any other APs. I have another METAL at the same site and it doesn't have these issues. My METAL with the problem has this issue 5 or 6 times a day. I have made a ping watchdog script to reboot the METAL when the problem happens, and that seems to alleviate the problem, but here lately I have had it lockup on a reboot like my RB/1200s do sometimes. Every time I have to reboot an RB1200 I get very scared because I know there is something like a 1 in 50 chance it will crash on reboot. My METAL is crashing on reboot every few days after the ping watchdog script reboots it.The thing that is really making me mad is that I have to climb a tower to pull the power to get it back up when this happens. I think the METALs wlan issue is hardware related, but the reboot crash is software related since powerpc routerboards and mipsbe routerboards both have the problem.

Also, the performance of the METAL is absolute garbage. I replaced an 8 year old Demarc Tech 802.11b radio with an RB/METAL and have had customers complain of outages, slow speeds, etc. I'm seriously considering putting up the old Demarc Tech AP again, but its CPU can't handle high traffic loads very well anymore. This is horrible. I have other Routerboards (433AH with XR2) and they work fine. I can't say I've owned a Routerboard that has had the wireless work well since the 433 and 600 boards. I have also tried an RB/711 and had awful reliability and performance issues. I find myself asking has the hardware or software quality of Mikrotik products dropped in recent years? Then I realize the difference is that the only Mikrotik APs I have had work well have been teamed with XR cards. Is there some compatibility issue with the chipset Mikrotik is now using for their own wireless cards that the Ubiquiti XR cards wouldn't have had an issue with? That's the only common denominator I can think of. I don't know what I'll do when all my RB433/XR2 APs die. I definitely can't replace them with 711s or METALs. Maybe I can dig out all my old RB/133 APs. I still have two in service and they are performing awesome.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3439
Joined: Mon May 31, 2004 2:55 pm

Re: RB Metal AP stability

Tue Dec 17, 2013 1:13 pm

you are saying that only few Metal boards are not working and other Metal boards works fine? Could you write to support@mikrotik.com about this issue and specify which Serial Numbers are working one and which are not.
 
UpRunTech
Member Candidate
Member Candidate
Posts: 125
Joined: Fri Jul 27, 2012 12:11 pm

Re: RB Metal AP stability

Sat Mar 01, 2014 6:22 am

Try v6.10. I am told it has fixes for the 2.4GHz Metal radio disappearing in AP mode. I have 3 of them that do this at the moment.
 
User avatar
cdiedrich
Forum Veteran
Forum Veteran
Posts: 950
Joined: Thu Feb 13, 2014 2:03 pm
Location: Basel, Switzerland // Bremen, Germany
Contact:

Re: RB Metal AP stability

Wed Mar 05, 2014 7:03 pm

Hi all,

I have axactly the same issue here.
One Metal (2.4GHz) working as AP and two as clients on mobile stations in our (rather huge) warehouse. NV2, +3db groundplane omni antennas on each Metal.
Every once in a while the AP Metal (and ONLY the AP) locks up as described.
Hat this with all ROS and FW Versions beginning with 5.24 up to 6.10 now...

It seems that it only happens after a certain uptime (or amount of traffic...).
I worked around this and added ad scheduled reboot every night at 04:30 AM.

Not a single issue since then (about 6 weeks ago)...

Cheers
-Chris
 
mackosy
just joined
Posts: 2
Joined: Thu Feb 05, 2009 1:21 pm

Re: RB Metal AP stability

Sat Jun 14, 2014 9:28 am

Hi!

I can confirm this issue. I have a METAL that disconnects all clients, and has it's wlan interface completely stop working. A scan wont even show any other APs.

I have 2 metal and both are doing the same.

Mikrotik can not have a solution and can not respond .
U can see it in this topic too : http://forum.mikrotik.com/viewtopic.php ... &start=100

Im thinking to change it to R2SHPN with rb411gl, but after that I do not know whether that is good Innovate.
 
User avatar
CyberTod
Long time Member
Long time Member
Posts: 511
Joined: Wed Jan 25, 2012 10:23 am

Re: RB Metal AP stability

Sat Jun 14, 2014 6:36 pm

I'm having these problems even after upgrading to v6.15 and enabling wireless-fp package.
But the clients does not disconnect. Actually they all stay connected, but the 'last-activity' field goes very high, normally it is a few seconds (not more than 20s) but when this happens it goes for example 00:06:02.640 and then only reboot solves it. I am using a script to detect this problem and reboot the board. If someone is interested I can post it here.

P.S. As mackosy said there are few other topics on this subject. I think this problem affects a lot RB Metals, only the 2ghz version (RB Metal 2SHPn)
 
hardings
newbie
Posts: 30
Joined: Fri Feb 26, 2010 11:13 am
Location: Melbourne Australia

Re: RB Metal AP stability

Sat Jul 05, 2014 12:37 pm

If someone is interested I can post it here.
I am interested. I am having lots of issues with metal 2GHz units in a number of point to point links and would like to see if your detection works in my situation. I currently use a path ping timeout detection. I have no problems with metal 5GHz units on similar links.
 
User avatar
CyberTod
Long time Member
Long time Member
Posts: 511
Joined: Wed Jan 25, 2012 10:23 am

Re: RB Metal AP stability

Sat Jul 05, 2014 1:13 pm

Here is the script, tested on v6 all versions :

/interface wireless registration-table print
:global lastactivity [/interface wireless registration-table get number=0 value-name=last-activity];
if ($lastactivity > "00:05:00.000") do {
/system sup-output
/interface wireless registration-table print stats file=regtable
log warning "Wireless Card fail. Last activity is $lastactivity. Rebooting router";
/system reboot
}

I have included making supout file and dumping the registration table into a file, because I opened a ticket about this problem and mikrotik support asked me for this information.
Make a scheduled task for this script to execute every 5min or an interval of your choice.
 
hardings
newbie
Posts: 30
Joined: Fri Feb 26, 2010 11:13 am
Location: Melbourne Australia

Re: RB Metal AP stability

Sat Jul 05, 2014 3:26 pm

Thanks. Ill have a play, but in my case the registration vanishes so I am not sure I will be able to read the value.
 
User avatar
CyberTod
Long time Member
Long time Member
Posts: 511
Joined: Wed Jan 25, 2012 10:23 am

Re: RB Metal AP stability

Sat Jul 05, 2014 4:39 pm

So it is different in your case. If there is nothing in the registration table you will not be able to get a value.
Maybe it drops the connection on the station side. I am using them as ap-bridge and the connections always stay.
 
hardings
newbie
Posts: 30
Joined: Fri Feb 26, 2010 11:13 am
Location: Melbourne Australia

Re: RB Metal AP stability

Sat Jul 05, 2014 5:48 pm

Yes, mine appears to be a different problem.

With my link problems I have two metals either end of a link. The longest is 16Km.

When the connection fails the registration vanishes.

I can reproduce the problem 100% by causing one end to send maximum throughput for a long time. It is always the TX end that fails, regardless of bridge or station side.

When the link fails cycling the wireless interface does not restore the connection, only a reboot of the TX end restores the connection. Rebooting the RX side has no effect.

I have a script that pings an address on the other end of the link and if it cant see it the wireless interface is cycled up to three times, and if that does not clear it a log and supout is saved and the metal is then rebooted. Usually it reboots.

The problem remains even after latest firmware is installed and latest ROS (6.15) is netinstalled.

Rarely, the TXing metal logs a kernel fault reboot, or a watchdog reboot.

I have experienced the problem on seven different 2GHz metals. Links I have with 5GHz metals have no problems.

I think this issue behaves like a thermal problem, but I cannot prove that yet. It could also be a total packets transferred problem manifesting through a resource leak of some sort.

I am also having problems with normal APs but that is a different story.

Very frustrating ... :cry:
 
swissiws
Member Candidate
Member Candidate
Posts: 105
Joined: Sat Apr 04, 2009 12:42 am

Re: RB Metal AP stability

Tue Sep 16, 2014 10:49 pm

Still same issue with AP disappearing

ROS 6.19 firmware 3.17


!!

Metal 2SHPn

can I get refund?
 
hardings
newbie
Posts: 30
Joined: Fri Feb 26, 2010 11:13 am
Location: Melbourne Australia

Re: RB Metal AP stability

Wed Sep 17, 2014 3:14 am

Try upgrading firmware to 3.17.2. It fixed all my problems.
 
swissiws
Member Candidate
Member Candidate
Posts: 105
Joined: Sat Apr 04, 2009 12:42 am

Re: RB Metal AP stability

Thu Sep 18, 2014 8:55 pm

hardings,

did you wrote this firmware version yourself?
 
hardings
newbie
Posts: 30
Joined: Fri Feb 26, 2010 11:13 am
Location: Melbourne Australia

Re: RB Metal AP stability

Fri Sep 19, 2014 3:35 am

This update note came from Mikrotik. I followed it and my problems vanished.

We have made some improvements for Metal 2SHPn could you please upgrade your metal 2 firmware by uploding this file
http://www.mikrotik.com/download/share/ ... _2SHPn.fwf to router then go in "/system routerbaord upgrade" and then reboot.
Upgrading to latest routeros 6.17 and resetting wireless to default config
"/interface wireless reset-configuration wlan1" would also be recommended. If possible you could try to enable wireless-fp package to see more improvements for wireless. Please test and get back with the results.
 
troy
Member
Member
Topic Author
Posts: 310
Joined: Thu Jun 30, 2005 6:47 pm

Re: RB Metal AP stability

Mon Sep 29, 2014 5:36 pm

Wow! 16 months later, we have a solution?

Too bad we ditched virtually all our MT wireless stuff in favor of the other guys. Still rocking the MT routers though, way more than I care to count!
 
hardings
newbie
Posts: 30
Joined: Fri Feb 26, 2010 11:13 am
Location: Melbourne Australia

Re: RB Metal AP stability

Mon Sep 29, 2014 5:54 pm

Yeah, and the problems vanished for a bunch of other around these parts too. This issue with the 2s has cost Mikrotik dearly in reputation. They took way too long to take it seriously. I no longer sing their praises.
 
swissiws
Member Candidate
Member Candidate
Posts: 105
Joined: Sat Apr 04, 2009 12:42 am

Re: RB Metal AP stability

Tue Sep 30, 2014 11:35 am

unbelievable - and not letting public know.

yes - latest FW seemed to fix VAP disappearance issue for me, still having port flapping towards CRS125 - 100 half duplex is stable.


\ still have to check poe injector - (off mikrotik ..) what is known about those they do not tell? \ sure there are cables \ - blame it on that!

Who is online

Users browsing this forum: No registered users and 55 guests