Long time ago, Long Term / Bugfix channel really good for mission critical system, because its already stable n tested. But now LT channel is just a name. In fact, the only latest real stable LT is 6.43.16. So why MT create LT n Stable channel if both unstable just like Testing channel?
+1
That’s why Mikrotik must stop prevent users downgrading ROS version!
Do they prevent? (O_o)
Mikrotik have to choose between being enterprise os which is offering stability, or soho os which is offering alot of features but unstable.
Mikrotik always, I mean always, sell new hardware before make the software for it. Everytime we buy new hardware, we must wait for about 6 months before that hardware can be stable. After that hardware become stable, next version can be unstable again. Man, do u guys sell hardware for business/enterprise or soho/toys?
Yes they prevent. I was working alot with RB951UI-2HnD with the most stable ROS 6.32.4. After some times, MT put factory version. Since that time, RB951UI-2HnD that I bought with factory version post 6.32.4 can’t downgrade to 6.32.4. Netinstall prevent it. I was curious, I disassembly older n younger hw, n they both have exactly the same hardware. They prevent downgrade for what purpose?
Did you contact support with this question?
The features can be in packages. Enterprise is not forced to install them.
In a fast changing IT landscape, rigidity in approaching marketplace is not considered a smart strategy for any business. That’s given. Enterprise-class products are are more stable because of their better specs, longer development and testing time. And more expensive, as a result.
On the other hand, MikroTik would not be where it is today without having been accepted in many many developing markets as best value products at selling price points.
That somehow reminds me of a car analogy. Lexus cars are better quality and more reliable than Toyota ones. They are both manufactured by the same company.
My point: there is a trade-off in there when using MikroTik products. Some time the trade off may be a bit too much. Sure. But that should not invalidate its strategy.
P.S. I put on my former business analyst hat to offer no more than a bird’s eye viewpoint. Wishing you a good day.
When they create CCR n CRS, that time they aim for enterprise router. But guess what? There are alot of CCR n CRS problem caused by software. After sometime, they can make a good software for CCR n CRS, but the next update will be unstable again.
I was working with CCR n CRS for a big factory. I ordered the latest CCR n CRS model but because it’s really unstable, the boss dont wanna know any reason, i had to change to PC with x86 MT n HP switch. I lost my money for buying that CCR + CRS. I wait for long time before they can be stable n I can sell it to another factory. But when new bugfix update come n unstable, the boss dont wanna know if its software problem. I offer to revert to previous software version but he said its a bad product. He cancel my last payment because of that. Since then, I dont wanna use new MT hardware. They just give a big headache.
Sorry to hear you lost money over the purchase of some MT gears which had issues at implementation time.
I stopped wondering why tradesmen (such as plumbers and electrical device installers) prefer to work on products on which they had plenty of experience, rather than others. It was after I experienced a moment or two of ‘not sure why’ as answers to my clients.
Since then, I always try to implement products that I am reasonably sure of their functionalities and reliability for my clients. After all, they rely on my knowledge, however limited it was. Once or twice, I bought new products, set them up and had them running in my lab prior to installing it at client site.
It’s fail-safe approach for me.
My two cents. Cheers.
Mikrotik devices can’t be downgraded below factory-software version, which is the current ROS version at the time of manufacture.
rb4011igs. after update, bridge mac address changes non stop
my log filled with
"bridge" mac address changed to xx:xx:xx:xx:xx:xx
version 6.44.6 don’t have this problem
Always set an admin mac address for bridges, or it will cause trouble sooner or later. Just my experience..
Here we go again with another long-term headache…
Hopes for thew solution to 6.45.x + RB1100x4 problem have been destroyed again. First testing produces loss of internal DNS resolution and therefore DNS server settings propagation through DHCP also stopped working - and that with /ip dns set allow-remote-requests set to NO!
This means, that even 7 day interval for scheduled reboots is too long - as failure occured on 6th day…
The only thing I can maybe add .If you guys do a security update like 6.44.6 only put in the security update and leave further upstream patches to a following update , so we don’t have to choose between security and stability.
ah, it works!
thank u
6.43.16 was released exactly one year ago and it was about last long-term release, which had none of the problems 6.44.x and 6.45.x release tree had introduced.
With 6.44.x we got huge increase in DFS radar detections making some of 5 GHz frequencies essentially unusable and some of RB3011 devices started having spontaneous reboots.
6.45.x gave big headaches to al21400 devices and state of DFS radar detections remained about same as before. Only thing to hope is that 6.46.x long-term will turn out better than last 10 months of long-term releases have been giving us…
need to fix this small cosmetic problem. it seems introduce on 6.45.8
Paul
and this bug has not fixed yet..
i found this on my RB4011iGS+5HacQ2HnD-IN and audience; the problem only for radio 5GHz card
Paul
Well… I am not sure how can this get more embarrassing, than it already is…
Two diffenrent locations, both have RB1100x4, one has 6.45.8 and other has 6.45.9.
When CPU usage goes crazy and internal DNS resolution stops working, I try to make supout.rif and guess what? It is not possible, because process stops somewhere about 56% and I get disconnected. Another try gives same result. No desire to try this repeatedly as there’s no guarentee about device being accessible after this. Reboot gets rid of the problem, but there’s no use of making supout file after that.
What the hell is going on?
P. S. There’s no easy way to access device physically on the location if somebody would try to suggest use serial connection.