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.
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.
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];
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…
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.
