We’re an almost all MT network, roughly 8000 units in the field between tower infrastructure and CPEs. We’ve been following a firmware management practice of maintaining our network with a consistent firmware version; waiting several months between versions we test in order to try to test the most stable versions possible (and only really doing upgrades for necessary bug fixes or features we benefit from). Our current “approved” firmware is v6.5 (excepting CRS/CCR equipment which had a needed bug fix in v6.13).
The most recent case of RB911-5HPnD boards we received shipped with v6.18 on them. When we attempted to downgrade to v6.5, the units came up in unlicensed mode and complained about no software key. Support indicated to us that the boards will not have a supported license except on v6.18 or higher. The conversation is replicated below:
We are very disappointed by this sudden and unannounced policy change by MikroTik to prevent us downgrading to known stable firmware. If the hardware we were purchasing was 802.11ac equipment that required wireless-fp, the inability to downgrade would make sense, but (according to the model number) these are the same 802.11n boards we’ve been purchasing since well before v6.5 was released. Hopefully MikroTik will either come forward with the technical reason that the boards cannot be downgraded, or will remove the restriction preventing the downgrade if there is no technical reason.
Mikrotik tend to ignore the fact that your firmwarepolicy is necessary to run a stable network. As soon as you file a bug you get the “you have to upgrade to the latest…”. We are not as restrictive as you but we do a very slow rollout of new versions, too. At the moment we stopped as we lost some Sectors with V6.15 and higher. 2 Testsectors with .ac/6.19 do reboots or hang completely from time to time. So we assume a recently introduced SW-bug which bricks devices under seldom circumstances we dont know.
As MT do not ensure SW Quality they should not hinder you from implementing their systems in a safe/stable way.
as you might have noticed - router consists of many parts and for some of them there are updates from time to time. While we try to have same parts for same router type it is not possible all the time. As a result in newer RouterOS there are certain additional changes done so that new parts work nicely. Once you downgrade below a certain threshold you can run in different problems with most severe - router not working at all as RAM or NAND access is not possible due to incompatibilities.
Also, for CCR i would not recommend staying on version below 6.18
In the future, can you modify your hardware numbering, even with a -v2 or something tacked on to the end, to indicate when hardware revisions have changed? Or at least have some notation in a change log or some where that hardware shipped after X date is going to require a specific firmware version?
In our case, we’re left scrambling now because we’re down under 2 weeks of inventory that we can install with a tested firmware version, and we didn’t have any opportunity ahead of time to verify we were going to get new hardware that worked with our tested firmware – we just ordered the exact same part number that we’ve been ordering for months and then got a surprise when we opened the box.
And I just went on routerboard.com, and the datasheets for this product all have file names such as xxx-1405xxxxx – indicating to me they haven’t been updated since May or earlier. (And if you actually open the quick guide, it has a date of 21-Aug-13 in the footer!)
Stealth hardware updates shouldn’t occur from a major manufacturer. Please modify your procedure to help clarify this going forward – we simply can’t deal with getting caught short in front of our bosses like this.