Hi,

Is anyone else having issues with the 133c and v3.16. I am being driven crazy with random failures all over my network. The same thing every time - customer calls saying there is no internet access and when I log into the box the NAT rule has zero hits - even though everything else works either side of it. A reboot will SOMETIMES bring it back but more often it takes several tries.

Further testing with filter rules shows that none of the firewall is working. Conntrack is on so that is not the issue.

Seems to me like there is some kind of race condition in the code for mipsle that is only failing randomly during startup.

Anyone else with this? It does not seem to affect the 411.

Malcolm

This is still present in v3.17. RB133c users BEWARE!!

Malcolm

I think I ran into this problem with v4 also today.....

me too!

i've seen on x86 and 133c, not yet on 433a. From 3.14 to 3.17 it's the same, 3.13 it's ok for me.

The same problem on RB112 and RB133C (FW is upgaded to last v2.18.).

/sys route upgrade

y

reboot


T

This seems to be only a problem with mipsle boards.

I have a ticket open with support but was suprised I had not heard anyone else report the problem. I am baselining at 3.10 until its fixed.

If anyone has 3.16 on an RB133c it is vital they dont try to downgrade to an older version via wireless. The result loses the wireless package. To downgrade install v3.17 first and then go back from there - I have done this with several boards now.

Malcolm

Mine was a 133c also.

Is 3.13 OK?

That's what I am at now for most of our clients.

Is 3.13 OK?

That's what I am at now for most of our clients.

I am told by a reliable source that 3.11 is ok. Someone mentions 3.13 being ok earlier in the thread but I don't know them personally so would not want to rely on the information myself.

I might try 3.13 out on my test rig - basically a script that reboots the 133c board if the firewall works and halts when it fails - with each test result sent to kiwi syslog. If its still rebooting after an hour or so then I'm happy the firmware is ok. This is what I used to verify 3.10 is ok:

:local bytes;

:if ([/interface wireless get [find name="wlan1"] running] = yes) do={

/ping 208.67.222.222 count=1

:delay 1s;

:set bytes [/ip firewall nat get [find out-interface="wlan1"] bytes];

:if ($bytes < 1) do={
:log error "FAIL";
};

:if ($bytes > 0) do={
:log error "PASS";
/system reboot
};

};

Upgrade the firmware

T

Upgrade the firmware

T

Already upgraded to 2.18. That makes no difference.

Malcolm

routeros 3.x just isnt stable on rb133c, use 2.9 instead.

For me, 3.13 "seems OK"

I must admit, we did have fewer support calls with 2.9

It seems with v3 we are telling our customers to power cycle often, we almost never had to do this before.

I'm sure MT will sort it out, they always do

I had this again today on the beta.

I had to downgrade to make it work to 3.13

I could not make the out file, router was disconnected when I tried.

I did not not traffic was being counted on the masq rule if that helps.

The good news is that Mikrotik have now confirmed the problem in an email to me and can create the same in their lab. So now we just need to wait for 3.18........

Until then its 3.10 for me:-)

Malcolm

Thanks for that

I use 3.11 and 3.13 to be stable

We've run into this as well - the unit is associated, can be accessed from either wireless or ethernet, but absolutely no traffic passes through the NAT rule. All thus far have been RB133C units - we've not logged any calls from clients with RB411's.

My counterpart swears that rebooting the unit from the CLI works every time (warm boot), but power cycling it doesn't (cold boot). I also noticed on one unit that disabling the NAT rule and re-enabling it brought functionality back, so it would lend some credibility to the software race idea.

It's not happened often enough to crank off too many customers, but we've not been able to reproduce it on the bench either. But we did start getting calls about it after an upgrade of all clients from 3.9 to 3.15.

So, now that it's a confirmed issue, when can we expect 3.18? I'd rather not wait a month for a new release and have customers cranked off at us over a known and presumably fixable software bug.


Brad

The good news is that Mikrotik have now confirmed the problem in an email to me and can create the same in their lab. So now we just need to wait for 3.18........

Until then its 3.10 for me:-)

Malcolm

This is how I am getting round the problem at the moment. These commands will keep rebooting the box until the firewall starts to work!!

/ip firewall filter add chain=input action=accept dst-address=127.0.0.1 comment="firewall-test-rule" place-before=0

/system script add name="check-firewall-script" policy=reboot,read,test source=":local bytes;\r\n/ping 127.0.0.1 count=1\r\n:delay 1s;\r\n:set bytes [/ip firewall filter get [find dst-address=\"127.0.0.1\"] bytes];\r\n:if (bytes < 1) do={\r\n/system reboot\r\n};"

/system scheduler add name="check-firewall-scheduler" on-event="check-firewall-script" start-date="jan/01/1970" start-time=00:01:00 interval=0s

When booting, sometimes RB133c seems to run out of memory with ROS 3.17 and NAT stop working. Ive also seen the wireless interface vanish too.

some news?

I've been battling this issue since we did a mass upgrade of our network, and have been fighting with lots of customers who have 133c boards. I'm glad I found this thread. I sure hope MT fixes this soon as I really don't want to have to downgrade a ton of boards.

jcremin - I feel your pain here. I had a few stressful days dealing with this problem.

I feel that I am justified in getting very annoyed with Mikrotik in this matter as they have failed to address this problem in a professional and timely manner. Christmas came and went and there is still no fix. This deserves an emergency v3.18 build to resolve the problem as it is BLOODY SERIOUS!!!

And it also makes a complete joke of the Mikrotik ethos of not allowing old versions to be downloaded or requested on here. People are suffering worldwide I suspect with this problem and yet weeks go by with no fix.

So to Mikrotik - either fix the problem NOW or allow us to download a known good old version. I cannot believe I had to use some (maybe dodgy - who knows) third parties web based file store to get v3.10 back.

Yours,

A very pissed off Malcolm

Hey Malcolm,
I wrote back and forth with MT's support, and I agree, it was not very helpful. All they said was that they would fix it in 3.18 and to use 3.13 in the meantime. I asked if they had an ETA for 3.18, and they simply said NO.

Here is a link to download 3.13: http://files.quicklinkwireless.com/mikr ... e-3.13.npk

UBNT had a problem with a firmware that introduced some bugs, and they pulled it right away and released a "fixed" version. I don't know why MT feels they should let people keep downloading broken versions which could potentially be losing us customers and not releasing a fixed 3.18 right away, even if this is the only bugfix it has in it.

Joe

To MT Support:

Guys, listen up - when you have a confirmed issue with something as basic and widely used as NAT, it would behoove you to put out a new release - even if as jcremin said was the ONLY fix in it. I read the changelogs, and have noticed that this has been done many times before, so it's not as if it's an uprecedented move.

I also realize it's the Christmas / New Year holiday timeframe, but I posted about this issue almost three weeks ago now, and we still haven't seen 3.18. It's been right at a month since the first post of this thread, and we still have no hints at resolution.

I've already had this issue waste a fair amount of my time in the way of support calls and having to downgrade the problem units to 3.9, and will have to re-invest that time in upgrading clients back to the new release once it's proven to resolve the issue.

MT has also said "if it's not broken, don't upgrade" - which is misleading advice at best. The changelogs rarely indicate subtle benefits (or pitfalls) of a new release versus previous releases, so the only way to tell the benefits is to deploy it in our own network to see how it reacts. In the case of the NAT issue I saw, it didn't show up until it was deployed on a wider basis than my "test bed", and even then it didn't seem to have a pattern until I started collecting more data and reading the forums, by which time it was too late.

For what it's worth, I left Valemount / Star-OS because of the attitude and lack of response to fixing issues that were longstanding and affecting my ability to serve customers. Since that time, there have been a lot more options show up in the wireless equipment and software field. Don't force history to repeat itself.

Brad

Hey Malcolm,
I wrote back and forth with MT's support, and I agree, it was not very helpful. All they said was that they would fix it in 3.18 and to use 3.13 in the meantime. I asked if they had an ETA for 3.18, and they simply said NO.

Here is a link to download 3.13: http://files.quicklinkwireless.com/mikr ... e-3.13.npk

UBNT had a problem with a firmware that introduced some bugs, and they pulled it right away and released a "fixed" version. I don't know why MT feels they should let people keep downloading broken versions which could potentially be losing us customers and not releasing a fixed 3.18 right away, even if this is the only bugfix it has in it.

Joe

The changelogs rarely indicate subtle benefits (or pitfalls) of a new release versus previous releases

One more comment about this, MT makes bug fixes and changes all the time that don't show up in the changelog. Isn't that what the changelog is for? And when questioned numerous times, MT's response is "well some things just aren't put in the changelog. How dumb is that?

I haven't checked on this specific issue, but there have been times in the past where MT has changed something "minor" and not put it in the changelog, only to find out later that it causes issues. If it were in the changelog, we would know to test that functionality before deploying and could help us troubleshoot the problem much faster. For people like me who upgrade 5 or 10 minor releases at a time, there's no way to know how far back to go to find a stable version if something like this does happen.

MT: please hear our voices and help us out here.

Thanks,
Joe

changelog can't show you all changes. for example if a bug that causes minor issues in 30 facilities - is fixed, you will see one change, not 30.

I can see the internal changelog, and I can guarantee you - there is nothing you would understand. Programmers fix their own code, not "features".

Something that would appear to you as "wow my weird firewall rule finally started to work" to the programmer is something like "do not set bogus init func while reco false"

Omw, another one i was seriously affected by!!!
I should learn to trust my instincts and always assume its a ROS bug till proven differently.

On our side lost few customers because of the NAT issue.


Also have suggested working in a different manor and also commented myself on the changelog at:
http://forum.mikrotik.com/viewtopic.php?f=1&t=27587


Don't agree on changelog it should show you what all is affected , even if its 30 points!
Otherwise there is no indication whether to upgrade or wait it out in fear of new bugs along the line.

But not gonna go into this again, just my 2p