Is anyone else seeing this problem on the RB751U-2Hn? I'm currently up-to-date with 5.12/2.38 and still seeing nearly daily reboot, mostly occurring under heavy wireless load (particularly to the router). I'm not getting anything useful in the logging, other than a kernel failure. Ticket #2011121366000676 with MT (open for 49 days now), hasn't produced any improvement. The overall layout is pretty trivial:

wireless bridged to lan (dhcp)
dmz (dhcp)
dhcp uplink
dns on the router
pptp client
simple filter/nat rules
8 simple queues

I haven't had this issue with other hardware, so I do suspect something in the wireless driver for this board is at fault. Any ideas, anyone?

I haven't had this issue with other hardware, so I do suspect something in the wireless driver for this board is at fault. Any ideas, anyone?

Hi,

I've setup around 30 the past week. I don't see this issue, maybe you have a defective unit?
do you use the orignal power supply? (12V, 1A)

[xxxxxx@xxx] > /system resource print
uptime: 1w2d18h34m1s
version: 5.6
free-memory: 8908KiB
total-memory: 29708KiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 400MHz
cpu-load: 0%
free-hdd-space: 31112KiB
total-hdd-space: 61440KiB
write-sect-since-reboot: 116993
write-sect-total: 141470
bad-blocks: 0%
architecture-name: mipsbe
board-name: RB751U-2HnD
platform: MikroTik
[xxxxxx@xxx]>

I've been running this one since 3 days after rOc-nOc got their first shipment. It wasn't *bad* with 5.6, but recent versions have had this problem. 5.11 was the worst, 5.12 has been better, but far from perfect. I haven't tried rolling back the firmware to what shipped with 5.6 (is this possible/easy without a serial port?), but I did netinstall 5.12 fresh with keep configuration, and am currently at 2d7h uptime (which is a recent record). So, perhaps it was a bad block in the kernel. Time will tell.

I've had similar issues. I put it down to using Skype; but that could be just because thats about the only thing that might be taxing my wireless. I posted about my issues here: http://forum.mikrotik.com/viewtopic.php?f=13&t=58424

The next step is to try a netinstall and resetup and see if it still happens....very frustrating!

I've been running this one since 3 days after rOc-nOc got their first shipment. It wasn't *bad* with 5.6, but recent versions have had this problem. 5.11 was the worst, 5.12 has been better, but far from perfect. I haven't tried rolling back the firmware to what shipped with 5.6 (is this possible/easy without a serial port?), but I did netinstall 5.12 fresh with keep configuration, and am currently at 2d7h uptime (which is a recent record). So, perhaps it was a bad block in the kernel. Time will tell.

Hi,

We use 5.6 on all our production systems at the moment, that's the reason i'm running it.
You can downgrade easily without serial, just upload files via winbox, then go to /system/package in winbox and hit the Downgrade button.

EDIT: Just thought about it, I got one RB751 in the field running 5.11:
[xx@xx] > /system resource print
uptime: 1w4d7h51m50s
version: 5.11
free-memory: 12096KiB
total-memory: 29708KiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 400MHz
cpu-load: 1%
free-hdd-space: 30032KiB
total-hdd-space: 61440KiB
write-sect-since-reboot: 133790
write-sect-total: 304708
bad-blocks: 0%
architecture-name: mipsbe
board-name: RB751U-2HnD
platform: MikroTik
[xxx@xxx] >




Kind regards

I think I downloaded as far as 5.8 without seeing an improvement. I was more interested in downgrading the firmware, rather than the OS.

I had a reboot about 16 hours ago. Still leagues better than I'd been seeing, and seems to be more frequent when my iPad is downloading large binaries from apple.

I think I downloaded as far as 5.8 without seeing an improvement. I was more interested in downgrading the firmware, rather than the OS.

I had a reboot about 16 hours ago. Still leagues better than I'd been seeing, and seems to be more frequent when my iPad is downloading large binaries from apple.

Ok, some further news from my site. I also seem to see reboots on different locations now.
Strange thing is that we don't see it on all of them.
We 've stopped upgrading our locations to RB751's as we first want to know the cause of this issue.
We're running 5.6, 5.12 seems to be a complete disaster on RB751U-2HnD.

Hi all
I have the same problem on my 751U, and i resolve him. I fix tx power to 14db and use "card rates" in wifi power.
Specific options will I be able to point out when I get home. Prior to their use RB751 rebooted several times a day

Hi all again, my setup, 14db it not priorities for best stability, it`s just my choice , but rate selection played a major role, and security profile in wireless section.

try 5.13

try 5.13

Ok, will do.
@Turbo: We already have those settings, except from tx power at 17 instead of 14.

I am seeing the same thing at present...very annoying.

This is a brand new unit - 5 days old. Have ROS 5.12 on it w/the latest firmware 2.38 installed.

Card TX set to default, setup as a 'standard' router type device, (client) ether1->wlan--><- wlan (AP) ether1 ->Internet, it's the client radio.

Thom

The nice thing is when you disable wifi it ain't happening.
But we bought them to use as wifi devices obviously

It definitely presents like a wifi driver issue. I've sent numerous supouts to support, and the last suggestion I got was trying 5.12rc1. So far, 5.13 seems to work. I haven't seen this problem since my upgrade to it.

It definitely presents like a wifi driver issue. I've sent numerous supouts to support, and the last suggestion I got was trying 5.12rc1. So far, 5.13 seems to work. I haven't seen this problem since my upgrade to it.

Ok, just upgraded two locations. We'll see.
kind regards
B

Upgraded to ROS 5.13 - 24 hours ago...so far so good.

Upgraded to ROS 5.13 - 24 hours ago...so far so good.

I still see reboots, less then before, but it still happens on 5.13 too.
Problem is NOT solved ! I will try 5.14

Nope. Not fixed in 5.14, though *much* less frequent.

Nope. Not fixed in 5.14, though *much* less frequent.

I'm very close to forgetting this RB751U-2Hnd. Too much trouble with it.

I'm very close to forgetting this RB751U-2Hnd. Too much trouble with it.

Thats what I did. Now re-visiting and hoping things are fixed but it would appear not

It all seems to be wireless-related, so I'm hoping they'll eventually get the driver right. But if they don't have these problems with the RB2011 with wireless, they'll probably kill this model outright.

It all seems to be wireless-related, so I'm hoping they'll eventually get the driver right. But if they don't have these problems with the RB2011 with wireless, they'll probably kill this model outright.

We 've stopped deploying them.
We bought 100 to start with (we need +500 to replace good old WRT54GL's), half is in the field.
The other half we will use without the wireless activated and equip them with an ubiquity AP.

Best we can do for now...
Still hoping the wireless driver gets fixed one day...

Don't know if anyone else tried this before, but you never know...
I changed the wireless band to 2ghz-b/g on a few systems in the field.
Let's hope this solves it untill there's a decent wireless driver available for this device
I'll keep you posted.

PS @MT Send me another for free please, I was so frustrated with that thing last week that I put my foot on one of them.
That one sure doesn't (re)boot anymore now

Ok, FYI putting it in b/g mode doesn't help. Still rebooting.

B/G didn't work for me either. Couldn't find any setting that would fix it.

have any one of you contacted support with RB751U which reboots, and is running v5.14? We need supout.rif files.

have any one of you contacted support with RB751U which reboots, and is running v5.14? We need supout.rif files.

Hi Normis,

I did yesterday.
It should be easy to reproduce:
Our scenario,hotspot, wifi @ 19dbm, card-rates
Connect with +5-7 users simultaneously (not all with perfect signal, in live scenarios users can be more far from the AP then in the lab) and start to generate traffic so the wifi gets loaded.

Hope this helps

PS Apart from this, I also see systems rebooted with no autosupout.rif generated, even it's set to yes in the settings. What does this mean?
It aren't power failures as the modem connected to the same power outlet hasn't been rebooted in those scenarios.

I just contacted support with the same problem.

I agree it seems to be wireless related, specifically when a client tries to connect or reconnect after sleep. Doubt its power because I turned down the wireless power (17dbm) and it shares a power strip, unless its the adapter.

Its annoying because it resets my ipsec connections which take many minutes to reconnect. Hope this issue is corrected because the feature and price point on this router is unbeatable.

CPEng

Normis, my ticket has been open for 90 days, #2011121366000676. I have sent supout.rif files 5 times.

All,

I disabled the watchdog completely on a few systems, none of them has rebooted so far.
It's only 3 days now, but that's a record on the locations I did this. Can someone else try this and post your findings?
One of those systems ran with a cpu@100% yesterday, this never happened before. It was a system pretty far away from our office, so stupid me rebooted it immediatelly in a panic reaction. Afterwards I realised it was a system with disabled watchdog and I should have taken a supout first...hell! I did check the scheduler before the reboot to see if no jobs were stuck or so, but this wasn't the case.

It concerns me a little that MT support replies to me that the problem isn't wireless related while everybody sees the opposite.
Disabling the watchdog could maybe lead to a supout which reveals more concerning the problem.
In attachment some cacti graphs, showing cpu usage of that particular system.

kind regards
B

Normis / MT support,

I had another system with disabled watchdog and cpu at 100%
I just mailed the supout's to MT support, using the old ticketnr Ticket#2012011266000348
Hope this brings some light, as we're in the process of disabling the wifi and installing a seperate AP on all of them.
It would save us a lot of work and costs if a stable firmware was available for this device.

kind regards

Anyone who heard something from Mikrotik support about this the last weeks?
I've sent them lots of supout's and personal findings, but didn't receive any replies yet

Not I. No reboots since disabling watchdog, much as that idea galls me.

Anyone who heard something from Mikrotik support about this the last weeks?
I've sent them lots of supout's and personal findings, but didn't receive any replies yet

post your ticket number please

post your ticket number please

4 posts above

Not I. No reboots since disabling watchdog, much as that idea galls me.

Same thing happened here, no reboots since disabling watchdog.

Not I. No reboots since disabling watchdog, much as that idea galls me.

Same thing happened here, no reboots since disabling watchdog.

Yes, but other issues will rise if your wifi gets loaded.
It can be a temporary workaround but it doesn't solve the problem.

When load on your wifi gets high for a few hours the system will start to generate heavy cpu load after a while and finally crash.
When you look at the profiler that time, you see lots of cpu eaten by "unclassified", this is probably the reason the watchdog reboots the device after all.
I think it happens the fastest when some wireless clients are not-to-close to the router.

And this is in the log when the cpu load goes into the sky:

Now cpu on this particular system came back to normal after 15minutes, but this isn't always the case.

Ok, I received follow up from support.
I gave them access to one of our systems in the field.
They installed a debug package on it, so they can monitor what's going on.
Very happy to hear from them, so I can confirm here they are actually working to find a solution to this problem.

kind regards

Hi Beone, do you have any news regarding the problem? I also have this problem and it's frustrating. I opened a ticket with Mikrotik support, i hope to get an answer. If you find any solution please post it here. Thanks

So, with watchdog off, my 751 ended up in the CPU 100%/low-mem/high flash process usage state that others have reported after 2.5 weeks:

[jacob@RB751U-2Hn] > /sys reso pr
uptime: 2w3d14h48m28s
version: 5.14
free-memory: 6088KiB
total-memory: 29708KiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 400MHz
cpu-load: 100%
free-hdd-space: 29392KiB
total-hdd-space: 61440KiB
write-sect-since-reboot: 6087850
write-sect-total: 10835346
bad-blocks: 0%
architecture-name: mipsbe
board-name: RB751U-2HnD
platform: MikroTik
[jacob@RB751U-2Hn] > /too prof
NAME CPU USAGE
firewall-mgmt all 0%
wireless all 0.5%
snmp all 0%
ethernet all 0.5%
console all 0%
graphing all 0%
flash all 100%
ssh all 0%
supout.rif all 0%
dns all 0.5%
firewall all 0%
ipsec all 0%
logging all 0%
management all 0%
encrypting all 0%
idle all 0%
profiling all 1.5%
queuing all 0.5%
routing all 0%
bridging all 0%
unclassified all 0.5%

I rebooted it (with watchdog off) and it hung. It required a power cycle to restore to function.

I got an answer from support and they gave me this link. Yesterday i upgraded the router to ros5.15rc1 and today i had no reboots with usual traffic. It seems that the problem is solved. Maybe you should also try this so we can confirm if it's solved or not.

I just deployed this new fw version on two locations.
My networks aren't very loaded at the moment due to easter holidays. (we mainly provide internet for students)
I will add more feedback here when I have new results.

No reboots yet on 5.15rc1. 5 days.

Oh, crash and burn.

So, after about a week of zero problems, my AP complete flaked. Couldn't associate, SSID only visible for several seconds every few minutes, not even visible on a WiFi scanner. Reboots didn't restore it, not enabling/disabling. Nothing in the logs, radio still shows under sys reso pci. Downgrade to 5.14 brought it back. That was scary.

So, don't trust 5.15rc1 to solve your problems. I'd rather deal with some reboots.

Oh, crash and burn.

So, after about a week of zero problems, my AP complete flaked. Couldn't associate, SSID only visible for several seconds every few minutes, not even visible on a WiFi scanner. Reboots didn't restore it, not enabling/disabling. Nothing in the logs, radio still shows under sys reso pci. Downgrade to 5.14 brought it back. That was scary.

So, don't trust 5.15rc1 to solve your problems. I'd rather deal with some reboots.

Damn, I was just upgrading a few more.
I still got one monitored by MT support (special package installed), but due to easter holidays there's almost no load (so no reboots) on the wifi.
System should get more load again in +/-10 days from now, so I hope it crashes/reboots and generates something usuable to finally address this issue.

@jhheider: How much simultaneous users you have online on the AP? How far are they away from the AP, any idea?
To me it looks pretty stable with 5.14 as long as you don't have +5 users connecting and especially, clients not too far away from te AP.
I have the impression that when some clients are more far away from the AP reboots increase.

Usually 1 device actively pulling content (laptop), and a couple of others hanging out on the wifi (a tablet and a printer). Distance from the AP is about 3 feet, through a plaster/concrete wall.

And, there we go again. Big upload caused a reboot:

jan/01/1970 19:00:17 system,error,critical router was rebooted without proper shutdown (cause 1)

And, there we go again. Big upload caused a reboot:

jan/01/1970 19:00:17 system,error,critical router was rebooted without proper shutdown (cause 1)

Check the following in your RouterOS settings: Is wireless rate selection "advanced"? is encryption set to only "AES"? is RouterBOOT upgraded to 2.38? Is distance set to "indoors"?

You might need to click "advanced mode" in winbox/webfig to see these settings.

/interface wireless
set 0 adaptive-noise-immunity=ap-and-client-mode allow-sharedkey=yes antenna-gain=0 antenna-mode=txa-rxb area="" arp=enabled band=2ghz-b/g \
basic-rates-a/g=24Mbps,36Mbps basic-rates-b=11Mbps bridge-mode=enabled channel-width=20mhz compression=no country=no_country_set default-ap-tx-limit=0 \
default-authentication=no default-client-tx-limit=0 default-forwarding=no dfs-mode=none disable-running-check=no disabled=no disconnect-timeout=3s \
distance=indoors frame-lifetime=0 frequency=2412 frequency-mode=manual-txpower frequency-offset=0 hide-ssid=no ht-ampdu-priorities=0,1,2,3,4,5,6,7 \
ht-amsdu-limit=256 ht-amsdu-threshold=256 ht-basic-mcs="" ht-guard-interval=any ht-rxchains=0,1 ht-supported-mcs=\
mcs-0,mcs-1,mcs-2,mcs-3,mcs-4,mcs-5,mcs-6,mcs-7,mcs-8,mcs-9,mcs-10,mcs-11,mcs-12,mcs-13,mcs-14,mcs-15 ht-txchains=0,1 hw-fragmentation-threshold=\
disabled hw-protection-mode=cts-to-self hw-protection-threshold=2347 hw-retries=4 l2mtu=2290 mac-address=00:0C:42:D6:A0:2B max-station-count=30 mode=\
ap-bridge mtu=1500 name=wlan1 noise-floor-threshold=default nv2-cell-radius=30 nv2-noise-floor-offset=default nv2-preshared-key="" nv2-qos=default \
nv2-queue-count=2 nv2-security=disabled on-fail-retry-time=100ms periodic-calibration=default periodic-calibration-interval=60 preamble-mode=both \
proprietary-extensions=post-2.9.25 radio-name=000C42441119 rate-selection=advanced rate-set=default scan-list=default security-profile=menagerie2 \
ssid=menagerie2 station-bridge-clone-mac=00:00:00:00:00:00 supported-rates-a/g=24Mbps,36Mbps,48Mbps,54Mbps supported-rates-b=11Mbps tdma-period-size=2 \
tx-power=14 tx-power-mode=card-rates update-stats-interval=disabled wds-cost-range=50-150 wds-default-bridge=lan wds-default-cost=100 wds-ignore-ssid=\
no wds-mode=dynamic wireless-protocol=802.11 wmm-support=disabled

/interface wireless security-profiles
add authentication-types=wpa-psk,wpa2-psk eap-methods=passthrough group-ciphers=aes-ccm group-key-update=5m interim-update=0s management-protection=\
disabled management-protection-key="" mode=dynamic-keys name=menagerie2 radius-eap-accounting=no radius-mac-accounting=no radius-mac-authentication=no \
radius-mac-caching=disabled radius-mac-format=XX:XX:XX:XX:XX:XX radius-mac-mode=as-username static-algo-0=none static-algo-1=none static-algo-2=none \
static-algo-3=none static-key-0="" static-key-1="" static-key-2="" static-key-3="" static-sta-private-algo=none static-sta-private-key="" \
static-transmit-key=key-0 supplicant-identity="" tls-certificate=none tls-mode=no-certificates unicast-ciphers=aes-ccm wpa-pre-shared-key=$KEY \
wpa2-pre-shared-key=$KEY

/sys rout pr
routerboard: yes
model: 751U-2HnD
serial-number: $SN
current-firmware: 2.38
upgrade-firmware: 2.38

please contact support@mikrotik.com with the support output file attached after the reboot.
One suggestion would be to check if the board reboots if you set the watchdog-timer to no.

Uldis,

I have an open ticket with support, #2011121366000676, open for 122 days. I sent supouts on:

2011-12-13
2011-12-14
2011-12-14
2011-12-16
2012-01-10
2012-01-30

The last response I received from support was on 2012-01-03, suggesting I try 5.12rc1 (no improvement).

I will send an additional supout the next time it reboots. It didn't seem to reboot under load with watchdog disabled, but had a high-incidence of lockups on calling /system reboot (all lights solid, no activity) requiring a power-cycle.

If there is anything further I can do to aid this investigation, since this problem has been reported by multiple people, please don't hesitate to let me know.

We also experience reboot problems with one of our RB751U which is used as a hotspot. Usually it reboots every day in approximately a peak time. However currently we have 5d uptime without reboot and only see 100% CPU utilization in peak time when it rebooted. Today we've discovered that CPU is utilized by 'flash' process:
Does someone have an idea what 'flash' process is trying to do? Is it trying to read/write something from/to flash? It's definitely not a log because we are forwarding all the logs to external host... so what else?

To all
We bought about 20 days agò (so new type of hardware) 5 units of this routerbard for test

now
one is ok
the rest show problems when there are traffic or many users
they do not respond on ping and to the other request (snmp, ethernet lookup etc etc)

we want buy 100 or more piece of them but due to this trouble
and due to big delay to resolve it we will move to another board or another vendor (ubiquity )

Mikrotik, please stand up and resolve it
I see troubles on forum from november 2011 (6 months is too much)
i will wait only another week,
after that we will decide to drive my project to another direction and i hope the others do the same

Stefano

I had simillar random reboot issues. They were caused by by higher temperature of environment. After moving to cooler place the problem are gone.

We too are experiencing this on RB750GL. Same process "flash" is using high cpu and eventually triggering the watchdog timer.

We too are experiencing this on RB750GL. Same process "flash" is using high cpu and eventually triggering the watchdog timer.

this is off topic, a different issue. you need to contact support with your RIF file and we will see why Flash process is running so actively.

about the above RB751U problems - you all need to send your RIF files to support, make the files as close to the problem as possible.

this is off topic, a different issue. you need to contact support with your RIF file and we will see why Flash process is running so actively.

Sorry Normis, I wrongly assumed since it was also 7xx series that it was the same issue. I have emailed support.

Please all try v5.15, we have fixed some RB751U problems there.

you need to contact support with your RIF file and we will see why Flash process is running so actively.
about the above RB751U problems - you all need to send your RIF files to support, make the files as close to the problem as possible.

We were trying to create supout.rif while experiencing high CPU load by flash process with no success. 30 minutes wait - and RIF still was not ready. Sorry that I didn't mention this before.

Just replaced RB751U with RB751G in field... wondering does it experience the same problem (hardware is slightly different).

Please all try v5.15, we have fixed some RB751U problems there.

Then I hope there are still changes compared to 5.15RC1.
I got one in the field, 100% CPU, can't ssh / winbox to it (doesn't accept the password).
I had it rebooted by a local user, comes up at immediatelly 100%, still unable to login. I go onsite tonight.
It was running 5.15rc1 for less then a week. I get so bored of that RB751U-2HnD thing!

there have been at least ten v5.15rc releases, so yes, definitely

there have been at least ten v5.15rc releases, so yes, definitely

Ok, we'll see after tonight.
You guys sure owe me (and lots of others...hahahha) a few beers for all the hell i'm going through with that device

New firmware installed yesterday
24 Hours and all seem to working

we'll wait next days but .. at now seem to be a good job

Thanks mikrotik I have not lost hope with you

As I mentioned before we've replaced RB/751U with RB/751G in the field. RouterOS version was left the same 5.14 (not 5.15) to see is there a difference between similar devices. What can I say? 3 days uptime without any issues on 751G where 751U shown issues every day. We leave it there for long holidays until 10 May to be sure that 751G really doesn't have issues discussed here. At the same time, do you know the possible difference between 751U and 751G which can produce issues on first one and does not produce issues on second one? Maybe it can help understanding the root cause of 751U problem.

Still having issues on the release 5.15 with CPU. Just had it spin out to 100% during 100MB upload, but it recovered without rebooting after the upload completed.

U and G differ, by the spec sheet, in port speed (obviously), CPU, and RAM. What does your RAM max at? I always felt that the various issues the 32MB routerboards have had (the 750s spent a long time running out of RAM and locking up on us in late 4.x) has been related to optimistic belief that 32MB is enough RAM. I've never seen a single one of the same problems in an RB with 64MB of RAM.

Today is more than 5 days of 751G uptime without any issues. And, jhheider, you may be right, our 751G has 64MB of RAM. But much more than 32MB is free:
However only developers know exactly how much RAM they need during peak operations. Wondering whether high CPU utilization by 'flash' process on 751U is an attempt to swap memory to disk?

That's my most current guess. I recall having similar OOM issues plaguing 750s early last year, that the 4xx and 750Gs didn't have.

Yesterday we've replaced back 751G by 751U upgraded to 5.15. I would say it works much much better. At the moment 23 hours uptime without any issues like reboots or high CPU utilization. Let's see how it feels next few days.

I am having a problem with defective RB450G hardware. See my post here.

I maintain that they are defective because they perform the reboots when sitting idle performing no function other than consuming watts.

Last night we got a crashed hotspot running RB751U-2HnD and ROS 5.15. CPU was at 100%.
Walled garden was reachable for the users, but hotspot login page didn't show anymore. A reboot fixed it.
I have other RB751U-2HnD's (configured as hotspot) running 5.15 that didn't show any issues so far (uptime +1 week), so many things got better since we 've started this thread. We'll see what the next days/weeks bring us.

kind regards

Ok, another crash today on another router running 5.15.
It doesn't reboot anymore, but all trafic seems to stop. Walled garden stays reachable.
EDIT: Just read there's a beta of 5.16, I mailed support to get a copy.

At Mikrotik's request, I have disabled SNMP on my devices having issues. It does seem like SNMP might be the culprit. I've been up for 2.5 days, which is pretty much a recent record. Of course, I'm quite blind without SNMP, but this seems to at least make the hardware operable until a more permanent solution is found.

I've seen worse results in networks with a greater number of Apple products, specifically Mac Book Pros and iPad2s, that I know of. This might be something to correlate.

Jacob

I have similar issues with RB751-2Hn (or whatever its called), constant disconnects especially with android devices. When android device tries to connect after being in standby rb prints out a bunch ... from unknown client... messages and becomes unresponsive for a five minutes or so, sometimes turning off and on must be done, responds to ping but no traffic and can't connect with winbox or telnet. No queues, firewall or any advanced things, just simple home ap with wireless users in ACL and a pppoe client for internet.

Tried 5.14, 5.15 and now running ver 6 ros, same thing.

Three days ago I have put another device to act as pppoe client, 751 connected with cable to it and now seems to work fine. If this happen to fix rb I will send support.rif, didn't want to do that before I'm 100% sure this is not my fault (placement, wireless settings...).

Since RouterOS 5.15 we have no significant issues. Sometimes CPU usage increases but RB recovers without rejecting service. Currently we have 17 days uptime. Wondering do we have to try 5.16 or leave it as is

Since RouterOS 5.15 we have no significant issues. Sometimes CPU usage increases but RB recovers without rejecting service. Currently we have 17 days uptime. Wondering do we have to try 5.16 or leave it as is

Go for 5.16, 5.15 stops all traffic over wireless after some heavy load.

The undocumented SNMP fixes in 5.17 made a *HUGE* difference. I ran 20Mbps of Debian torrents through my 751 for 2.5 hours without a crash. If it's not 100%, it's very, very close now.

Close, but not quite. If you have watchdog enabled, flash will go to 100% on the first SNMP query of the device, and stay there until the traffic ceases. This will cause watchdog to reboot the router, and management sessions to become unresponsive (making harvesting supouts difficult/impossible). Same behavior on 5.18.

RB951-2n, on the other hand, doesn't seem to have these problems. That was a pleasant surprise. So, that might be my new go-to device.

That is good to hear some positive feedback on the 951! Maybe I wont feel like such a freaking beta tester if I decide to buy more MT devices. I get all excited about MT. But when they have all sorts of problems and its hard to see them take ownership of them, its hard to put any real faith in them. So, here's to the new 951 then...

Sent from my DROIDX using Tapatalk 2

justfishing, I felt the same way about the 951, based on 9 months of issues with the 751U, and mikrotik not being able to make it stable. I was happily surprised, much as I didn't want to be, that the 951 is working without issue. Sometimes, you'd really like a problem to be configuration of endemic software error, rather that specific to the hardware. Makes me worry that it's something that won't be fixable in software, or that will never be fixed.

Here's the steps that will reliably spin up the flash:

Using my config (or any other it seems) do the following:

On a computer on the WIFI AP load up high-bandwidth, multi-stream traffic (I use debian CD ISO torrents). Once it's running, snmpwalk the router. About halfway through (right before it checks the disk, I suspect), the flash process will go to 100%, the management sessions will freeze, the snmp query will timeout, and the router will remain pegged until the traffic is stopped, at which point it will go back to normal.

(updated to ticket # 2012062266000481)

Great, we run snmp on our CPE's every 5 minutes

Yup. Hence the enormous problem that this bug causes. Even with SNMP disabled, it's possible to flood this router, but this is a simple trigger that works basically every time. The 951 seems like a great replacement, since it doesn't suffer from *this* bug in any way, but the wireless does disappear every few hours, until you reboot or re-enable the (enabled) wireless interface. MT support has confirmed this bug has been reported by multiple sources, and they're currently working on it.

The 951 seems like a great replacement, since it doesn't suffer from *this* bug in any way, but the wireless does disappear every few hours, until you reboot or re-enable the (enabled) wireless interface. MT support has confirmed this bug has been reported by multiple sources, and they're currently working on it.

True enough about the the wifi disappearing. I have booted up all my RBs today morning and in the evening when I got home the 951 wifi was gone. The disable/enable trick worked, but that's not the way to go. Any idea hos is this case progressing with the Support?

5.19rc1 doesn't seem to have this problem. I've had one reboot for no obvious reason since loading it last night, but no other issues (yet).

Time will tell...

No change to rb751U-2Hn 100% flash utilization with 5.19.

Ticket #2012062266000481

No change to rb751U-2Hn 100% flash utilization with 5.19.

Ticket #2012062266000481

Yes, I'm with same problem on rb751U, flash utilization goes up to the max, router gets unstable, no winbox access and, if I'm lucky, I can telnet to it and reboot it.
Works ok until some load occurs, then it "flashes" again.

Ticket #2012072366000405

I can't believe that after so many people had the similar issues that there is still no anwser why it happens?
Or, it is simply hardware issue on rb751U that software upgrade can't save...

BR, Petar

Petar,

The RB751U-2Hn has not had one single stable firmware release since the hardware went on sale. The RB951-2n, while it had the disappearing radio problem in 5.18 (haven't tested 5.19 yet, but 5.19rc1 looked good in limited testing), hasn't had a single stability or load problem for me. I'm sad about the 751. If it were hardware, I feel like a recall would be cheaper for MT than the continued erosion of their reputation that comes from the more poorly executed additions to their product line.

That said, I'm willing to keep trying new firmware on the 751s, in the hopes that one will fix them. But it's been 8 months since I've reported my first 751 bug to MT, and they just haven't been able to make it work even as reliably as cheap SOHO gear.

But it's been 8 months since I've reported my first 751 bug to MT, and they just haven't been able to make it work even as reliably as cheap SOHO gear.

+1 and I really admire your patience with this, I gave up this device months ago already.

RB751U-2HnD - downgraded from 6.0 b3 tyo ROS 5.19 - 3-5 reboots per day.
[Ticket#2012080166000114] RE: RB751U-2HnD - Reboot

Ive got about 30 of em... In process of collecting them and sending them back. Worthless device. Pretty much dont work right unless you are within 20 feet of if. Have tried everything short of putting an external antenna on them (Not doing that, shouldnt have to). Even the 2 I have at my house are just quirky.

is this a joke? the problem was reported on Nov 2011 and now it's already 1 year and still not fixed? How can we (system integrator) rely on this product with such bad support? This is a major issue that is a deal breaker for this router. If support is unable to fix it, the company should have recalled the product. How can we trust Mikrotik anymore? We have bought over 100 pcs to be implement and now we have to put the project on hold. We have already spend resources buying and implemented the devices on various locations. Now we need to recall them or something and that cost us double of our costs. MT was a very promising company but having this kind of support really set the reputation back few years behind others.

is this a joke? the problem was reported on Nov 2011 and now it's already 1 year and still not fixed? How can we (system integrator) rely on this product with such bad support? This is a major issue that is a deal breaker for this router. If support is unable to fix it, the company should have recalled the product. How can we trust Mikrotik anymore? We have bought over 100 pcs to be implement and now we have to put the project on hold. We have already spend resources buying and implemented the devices on various locations. Now we need to recall them or something and that cost us double of our costs. MT was a very promising company but having this kind of support really set the reputation back few years behind others.

Please clarify which issue you mean. Most of the above reports are very vague and generic. "disappointing range" is not a specific issue, especially for a SOHO (small office, home office) type of device. What range were you expecting? Most phones and laptops can't get 50m with a clear line of sight, no matter which AP you use.

is this a joke? the problem was reported on Nov 2011 and now it's already 1 year and still not fixed? How can we (system integrator) rely on this product with such bad support? This is a major issue that is a deal breaker for this router. If support is unable to fix it, the company should have recalled the product. How can we trust Mikrotik anymore? We have bought over 100 pcs to be implement and now we have to put the project on hold. We have already spend resources buying and implemented the devices on various locations. Now we need to recall them or something and that cost us double of our costs. MT was a very promising company but having this kind of support really set the reputation back few years behind others.

Please clarify which issue you mean. Most of the above reports are very vague and generic. "disappointing range" is not a specific issue, especially for a SOHO (small office, home office) type of device. What range were you expecting? Most phones and laptops can't get 50m with a clear line of sight, no matter which AP you use.

What are you talking about "disappointing range"? Which part of my post have this 2 word?

The title of this thread is "RB751U-2Hn frequent (daily) reboots". What else do you think I am talking about? Isn't the 2 pages of discussion here all referring to this issue? FYI, we just upgraded to your STABLE firmware 5.22. Instantly the reboot issue happened. Even without much load, reboot automatically by itself. Have since downgraded to 5.17. Seems to be more stable. But not holding any high hope as we still need to do load tests and so on. Feels like a beta tester now...

You can see that the topic is very old, and most of the issues were solved before RouterOS v5.15. In newer posts, people complain about range.

Did you contact support? Please tell me your ticket number, and I will check the progress of this issue. If you have not contacted support, we can't help you. We must see the supout.rif file to be able to find the problem. We have currently no known issues that causes reboot of RB751

Here's the steps that will reliably spin up the flash:

Using my config (or any other it seems) do the following:

On a computer on the WIFI AP load up high-bandwidth, multi-stream traffic (I use debian CD ISO torrents). Once it's running, snmpwalk the router. About halfway through (right before it checks the disk, I suspect), the flash process will go to 100%, the management sessions will freeze, the snmp query will timeout, and the router will remain pegged until the traffic is stopped, at which point it will go back to normal.

(updated to ticket # 2012062266000481)

This is the exact issue we are seeing on RB751U, RB750UP, RB750GL and RB2011. If we swap them out with a PPC router e.g. RB1200 the problem goes away completely.

Here's the steps that will reliably spin up the flash:

Using my config (or any other it seems) do the following:

On a computer on the WIFI AP load up high-bandwidth, multi-stream traffic (I use debian CD ISO torrents). Once it's running, snmpwalk the router. About halfway through (right before it checks the disk, I suspect), the flash process will go to 100%, the management sessions will freeze, the snmp query will timeout, and the router will remain pegged until the traffic is stopped, at which point it will go back to normal.

(updated to ticket # 2012062266000481)

This is the exact issue we are seeing on RB751U, RB750UP, RB750GL and RB2011. If we swap them out with a PPC router e.g. RB1200 the problem goes away completely.

Ok you both. I did the test as described, and had no issues. Please tell me what I did wrong:

Ok you both. I did the test as described, and had no issues. Please tell me what I did wrong:

Hi Normis.

For us this only happens after 3days to a week of the router being up and under heavy use.
Generally it is triggered by The Dude polling the mipsbe router.
I will set up a lab and replicate this and post supout.rif and video.

After 4-6 days of intense outgoing torrent traffic on the radio interface to reload the router. Supout.rif file I sent.

i guess heavy p2p wasn't good for routers w/o FPU.
and otherwise stressful cases.
moderate overclocking[before replace to 1200] orimproving heatsink/cooler could ease it a bit.
also 64Mb and 128Mb is quite small for routers with significant portions of traffic with p2p and/or HUGE bandwith[recently become usual for most providers/customers datalinks].

I assume that the reboot on watchdog is due to the strong CPU load. For some reason the torrent traffic arriving via the radio interface causes severe loading process - "flash". Turning off the radio interface solves the problem.

This has always seemed to be the problem. My original tickets are all still outstanding, but I've stopped trying to use RB751 for SOHO. The 951 was an improvement, in that it wouldn't crash/reboot, but I've since moved away to an RB2011 in front of a cluster of Ubiquiti UniFi.

I love RouterOS, but I don't think Routerboards provide a viable WiFi AP solution. Unsurprising, I suppose, due to their evolution from CPE. What I *haven't* tried is a 2011 with wireless, but it just wasn't worth it to me to keep messing with it.

I can send simple L2TP Server+NAT config to confirm that every RB750, RB750UP, RB750GL, RB751U, RB751G will reboot if run btest on two PC (endpoints). Interestingly this not happens on ROS 4.17, but only on 5.x. Sadly only RB750 supported by ROS 4.17, thus all other RB unusable under high loads, because of random reboots.

In your test Normis CPU load rerely hops over 50% (maybe once, but it can be login via winbox from other PC).

Here's the steps that will reliably spin up the flash:

Using my config (or any other it seems) do the following:

On a computer on the WIFI AP load up high-bandwidth, multi-stream traffic (I use debian CD ISO torrents). Once it's running, snmpwalk the router. About halfway through (right before it checks the disk, I suspect), the flash process will go to 100%, the management sessions will freeze, the snmp query will timeout, and the router will remain pegged until the traffic is stopped, at which point it will go back to normal.

(updated to ticket # 2012062266000481)

This is the exact issue we are seeing on RB751U, RB750UP, RB750GL and RB2011. If we swap them out with a PPC router e.g. RB1200 the problem goes away completely.

Ok you both. I did the test as described, and had no issues. Please tell me what I did wrong:

In my case the problem was solved installing the firmware 6.0 RC6

In my case the problem was solved installing the firmware 6.0 RC6

Interesting. I have some of this random reboots on my router weekly. This problems starts ( i believe ) when I upgrade my router to the 5.24 version. With the original 5.16 version i isn't have this problems.

Interesting to see about this problem. I send an email to Mikrotik and they say i need to send the routerboard to the warranty ... but reading this i believe this isn't solve my problem.

Well, i changing the encryption of my network to AES ( as I read on the first page ) and I will test on the next days.

Hi all again, my setup, 14db it not priorities for best stability, it`s just my choice , but rate selection played a major role, and security profile in wireless section.

Intesting, are you still using this config on your routerboard @Turb0 ?

Here, on my routerboard I believe my problems is with a pendrive on my usb.

When I remove the pendrive ( i have one filesystem on this pendrive to write my logs ) my routerboard is more stable.

Too I made the configs of @Turb0 .

I will wait one or two weeks, but I believe this solves my problem.

I am on RouterOS 5.22 and firmware 2.41 .

I have also problems with strange restarts by watchdog for some time, I try to connect to the event and it happens most often when talking on Skype - even one person in the network. Upgrade to version 6.0 caused a marked decrease of such events, but not a total elimination.
751U-2HnD ROS 6.0 rb fw 3.07, acting as a home NAT router

I have also problems with strange restarts by watchdog for some time, I try to connect to the event and it happens most often when talking on Skype - even one person in the network. Upgrade to version 6.0 caused a marked decrease of such events, but not a total elimination.
751U-2HnD ROS 6.0 rb fw 3.07, acting as a home NAT router

You try this configurations ?

http://forum.mikrotik.com/viewtopic.php ... 26#p303575

You try this configurations ?

Yep, I'm observing this topic from the beginning, but my wifi config was set just before... As I wrote, now resets occur less frequently (literally one since the release version 6).

You try this configurations ?

Yep, I'm observing this topic from the beginning, but my wifi config was set just before... As I wrote, now resets occur less frequently (literally one since the release version 6).

Here with this configs my router was online without reboots for 20 or more.

It was a Nat router and I have 2 vpns and a 6to4 tunnel too


Sent from my GT-I9100 using Tapatalk 2

Installation of ROS 6.1 (and higher) with an upgrade included RouterBOOT ended my problems (I hope).