I have metal mikrotik 2.4. It stops transmitting the wireless when it wants. No more setting to change. I’ve tried them all and the problem continues.
The SSID of the Metal mikrotik 2.4 disappears in a site survey.
Clients lose the connection in hotspot and have to restart the metal 2.4.
Sometimes I can restart remote, but others I have to go there and cut the power. I use it on battery because I was thinking that the original source was faulty.
I’ve tried all settings. I reduced the power, I used default power, I changed ack, I left only B mode B / G mode and B / G / N
It is one day, two, three or more days good. But at other times it hangs two or three times a day.
It stops transmitting the wireless when ithe wants. No more setting to change. I’ve tried them all and the problem continues.
The SSID of the Metal mikrotik 2.4 disappears in a site survey.
I’ve tried all settings. I reduced the power, I used default power, I changed ack, I left only B mode B / G mode and B / G / N
It is one day, two, three or more days good. But at other times it hangs two or three times a day.
Through experience I have with other RBs mikrotik I can say that I am not doing anything wrong. The conclusion that I have is that it has a design defect or batch production ou firwmare problem.
I saw that in registration Metal 2.4 clients do not disconnect.
But they will disconnecting in the hotspot.
Anyone else have encountered this kind of problem?
Going to some new revision software is going to introduce you different set of issues, better go for the latest one of the same series - v5.25 and then up it from that, if needed.
Hello, same happened to me, I bought 4 of these APs, 2 of them had the same problem, WIFI were unstable, it kinda worked for a while after a reboot, but still unstable, I have tried everything, I reached support, after several mails and weeks, they ask me to send them to RMA, dont waste your time, these devices are kinda defective (at least 2 of 4 on my case=50%), return them!
my metal burn out today(( speed was 40 mbps and board work with it 5-10 mins. after - all leads is off. metal newer come back again. RIP (
for good work of this board you must limit summary bandwidth to 5 mbps for all wireless clients (not for each).
script might be not work sometimes. nobody dnot know why.
i used this version of script ( without while cycle)
local a [/in wi reg get number=0 last-activity]; :local b {[:pick $a +4]}; :if (b>=2) do={[/system reboot;];}
I agree that running a script to monitor the Wireless Interface is a bandaid solution. However, why do these units fail? Mikrotik needs to address this issue. It’s not acceptable to have products that need bandaids to make them work.
I have installed these units at 100’ on towers and been forced to drive to location and repower them because the units wireless stopped and the monitoring scripts (bandaids) have jammed the unit to the point where I could not access them.
The specs and design of these units is amazing and when they are running correctly they are great units, but they need to be made stable in order to be useable.
If your car suddendly stopped running on the highway and you had to stop the car, turn the key off and then back on again in order to continue your trip, would you not expect the manufacturer to fix the car?
We have THE SAME PROBLEM with MikroTik Metal-2Hn.
Groove A (level4) with the same configuration and in the same place - works good.
What is wrong with that Metal-2Hn?!
I have the same problem with MikroTik Metal-2Hn.
Groove A2hn with the same configuration and in the same place - works good.
Its signal quality is very bad, unstable. Customers are not connected continuously.
I’ve got the wireless client count checking script mentioned in one of the metal2.4 threads running so we at least do not have long periods with no traffic, the reboots are quick. Theres 2 of those type reboots in the log below.
But as you can see there are two other reboot types that occur… kernel issues, and i guess just watchdog reboots are the “without proper shutdown” ones.
we’ve tried it all, we can’t find any relief. we are currently on 6.9 but we’ve seend this on every 5.x and 6.x version we’ve tried.
The most frustrating thing is that there is no information on what is actually going wrong, nothing in the logs, nothing in autosupout.rif etc. If someone were to hackinto the linux command prompt behind RouterOS on the devices you might be able to log some information on what is happening before the reboot occurs. You would think Mikrotik has done this already and has some information to report
The same thing is occuring with a second Metal2.4 plus a SXT 2.4Ghz running as a sector.
We have a RB450 running on the same power source, aggregating the ethernet from those 3 aps, and it never reboots or hangs.
It’s a reboot party on our tower.
[root@localhost log]# grep boot metal2.log
Feb 1 14:53:47 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 2 19:36:24 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 4 00:15:07 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 4 00:15:07 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 4 08:57:54 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 4 08:57:54 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 4 18:22:46 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 4 18:22:46 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 5 07:20:05 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 5 07:20:05 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 5 21:09:23 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 5 21:09:23 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 6 18:35:31 10.4.9.52 metal2 still 0 associated clients, router reboot
Feb 6 18:36:23 10.4.9.52 metal2 router rebooted
Feb 7 21:49:33 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 7 21:49:33 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 7 23:22:01 10.4.9.52 metal2 router was rebooted without proper shutdown by
Feb 8 07:27:34 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 8 07:27:34 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 8 08:39:15 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 8 08:39:15 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 8 18:11:21 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 8 18:11:21 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 9 18:42:00 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 9 18:42:00 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 10 14:18:25 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 10 14:18:25 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 11 12:03:18 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 11 12:03:18 10.4.9.52 metal2 router was rebooted without proper shutdown
Feb 12 08:33:30 10.4.9.52 metal2 still 0 associated clients, router reboot
Feb 12 08:34:22 10.4.9.52 metal2 router rebooted
Feb 13 18:26:28 10.4.9.52 metal2 System rebooted because of kernel failure
Feb 13 18:26:28 10.4.9.52 metal2 router was rebooted without proper shutdown
[root@localhost log]#
