I am sure this has been ranted about many times before but here goes again:
WHY WHY WHY is MT STILL using a binary .backup system ?
Why do we not have a good old startup-config.txt and running-config.txt based system yet ? most of the time a generic .backup file breaks wireless so this means a remote site visit.
Mass upgrades are EXTREMELY COMPLICATED and NEAR IMPOSSIBLE with the existing .backup compiled binary backup system.
Many of you will say, ‘but my upgrades work fine’. Yes that is true MOST of the time. But the problem is due to the fact that new versions always have something broken, so most of the time it ends up getting rolled back.
Try doing that to 1000 remote wireless CPE’s automatically.
There seems to be a race to add new features whilst accidentally breaking existing features in the process. It happens with almost every release.
The other huge problem we see is upgrading from 2.9 to 3.x. Approx 20% of the units upgraded have a 100% CPU issue post-upgrade. The ONLY solution is to system reset and manually reconfigure. End config / net result is the same but no high CPU drain this time. The binary .backup thing is utter and total junk and subject to corruption between upgrades / downgrades.
If we had a .txt based system none of this would be a problem, and I could automatically push out a mass upgrade to 1000 CPE’s in under 5mins, AND get some sleep for once.
also, if you use xen (highly experimental) you can see, that when you create new guest you can supply rsc file, that way you can see, how it will look like, when you use it in normal RouterOS install (to test out script)
or import that script into clean router and see result.
currently you can give Netinstall an RSC file when installing/reinstalling RouterOS, and that will be used when doing system reset.
Bummer… we’re talking LOTS of 133’s already deployed remotely and wirelessly. The nearest is 1km away. The farthest is 500km away. Netinstall is out of the question. They are all running 2.9.x
The objective is to upgrade them all to 3.02 in a CLEAN MANNER. Eg system-reset then upgrade then configure.
3.02 is actually labelled 3.2 - this is the only stable version 3 that runs on 133’s we have found from experience.
ALL later 3.x versions are broken when running wireless and PPPoE client on a 133. It’s the PPPoE client that kills the 133. Not only does PPPoE client overload the CPU, but NAT is also broken in all the latest releases.
The reason that 3.x is required is for WMM. Yes, WMM works fantastic too. But it only works without nstreme.
Back on topic..
I guess my rant still stands then:
There is no simple CLEAN way to automate the upgrade of already deployed wireless 133 CPE’s for the purpose of activating WMM ?
Plan B: How about the MT guys create a WMM backport for 2.9 ?
eg wireless-test-2.9.51.npk that includes WMM ?
As I understand WMM is done in the Atheros chipset. The O/S only has to set a ‘flag’ to enable it. Surely this is possible ?
i wondwer - how you imagined to access the board after you clear all the configuration that is there? If you have other routerboard near by in same ethernet network you can reset-configuration and then connect using mac-telnet from that box and set up configuration.
Thats the exact purpose of this thread. I want to be able to completely reset, reconfigure and upgrade in one hit WITHOUT having local access.
The reason this is a rant is because industry standard dictates a startup-config and running-config text based configuration system, to avoid all of the problems we are discussing here.
This is a fundamental feature that MT should have, but currently does not.
If the router hardware is different, it’s very hard for ROS to know which addresses need to be applied to which interface, which wireless cards should be used etc. And then there are different drivers and so on.
Although I agree, we need to improve this function so that at least it could be imported back to the same router.
But actually there is no “import” it just executes all the commands in the file.
also, i would like to note, that you had a chance to set up default load configuration before you installed router in place in some obscure place using netinstall tool as noted before in this thread.
as normis said - that functionality could be improved.
Would a “/system reset-configuration file=name.rsc” do what you want? It would reset, and then apply the config in the RSC file so that your CPE could connect to the AP for example.
Would a “/system reset-configuration file=name.rsc” do what you want? It would reset, and then apply the config in the RSC file so that your CPE could connect to the AP for example.
Normis - yes this would be perfect in the long run. In fact, I was just about to suggest this in an email to support@mikrotik…
The downside for us right now is:
Most of our CPE’s are 133’s and the only known ‘reliable’ v3 build is 3.2 (3.02) on this platform. So I think this is our only option*
They are already deployed and would need to be upgraded to get this feature if it was to be added… it’s a catch 22.
*how about a backported system_with_restore_config_patch-3.2-mipsle.npk ?
?