Our latest batch of Knot came with factory version 7.20.8. Earlier this year, 7.20.7 released in “Long Term” channel, so we vetted our scripts and configuration for 7.20.7 and hoped we could run on that version for a while. But since new knots has a more recent version as factory version, we can no longer downgrade to the version we have tested.
Does anyone know the logic behind how factory version is set on new batches of mikrotik hardware? Do they expect all customers to potentially test, run and support every new version of routerOS they release? That is a very big ask of their customers…
Well, you are assuming that they are actually have a logic and implement it.
Very likely they - in good faith BUT often very wrongly - believe that once a version has been assigned the "long term" badge, it means that it will be "long term", while in reality it will be soon be replaced by a NEW long term version (for one reason or the other).
In other words, it is difficult to make predictions, expecially about the future.
Devices now ship long-term versions? This is new information. I always assumed they ship latest version from stable channel available at time of initial device programming in factory.
Of cource they do, In this IT World goes so fast, so be proud of buying a device that have bug fixes and security fixes and they also add more features without you have to pay more.
When a device is shipped with new components that require an update to RouterOS to function (this can even happen on existing designs!) there will be a new version and it is set as “factory version”. That means this particular device cannot work with 7.20.7
How much that impacts you will have to be checked every time. It may be that this version only adds some driver and fixes some functions, it may also be that it introduces incompatible changes to commandline parameters.
Yes, that is unfortunate. Especially because it is so difficult to write commands that will work on multiple versions that have different parameter structure.
Our problem is writing commands, supporting devices that are already deployed and cannot have their firmware easily updated, and handling bugs that may show up on different versions of routeros once the routers have been deployed… Without having access to stable versions that does not change every month, this is not easy to do with limited manpower..
Well, yes that is the fact of life with MikroTik. When you are a shop that believes in validated software releases that you test and then can use for years, then probably it is not the proper equipment to buy.
But I would not know which other manufacturer would remain to get stuck on some software version on a device that is connected to internet. Maybe you need to review your company policy.
It will not happen every month, you just hit an unlikely coincidence. And it probably will not be as dramatic as you think, the two versions can likely be handled as equivalent for now. Of course in a years time you may well find a version on newly bought devices that is not so similar as this one.
You might also want to look into some way to admin the devices once deployed, e.g. by configuring BTH VPN on them and registering the xxxxx.sn.mynetname.net of each unit.
MikroTik does not like to document/communicate things
"mass provisioning" remains more complex than it should be
Those two are somewhat inter-related in that it's hard to build a reliable mass provisioning scheme when you have to make assumptions on "historical precedents". For example, while it's easy to say MikroTik always "ships the stable" and "factory-version is immutable for life of device"... if you have provision scripts/process/scheme around these things, its always a issue that one of these "undocumented understandings" could bite you eventually.
Like here, are all new devices going to ship with a factory-version set to long-term, or was this a "one-off" because some KNOT features do need newer RouterOS support? "Likely" the later (a KNOT specific thing) — but we really don't know! If it the former (e.g. MikroTik desire to "tight up" security by blocked older version using factory-version)... many folks may expect that be able to "downgrade" (perhaps with device-mode needed) to their org's desire "tested/deployed version".
It's easy to say "oh just change your script to use 7.20.8" – and that very well be true here – but not everyone want to update their processes/script/docs/etc on a per-version, or "per-batch from distributor". If you use netinstall or netinstall-cli as your basis provisioning you're a bit more isolated from these vagaries.... but these kinda of things do fowl up the flashfig.exe cases, since you do NOT replace the version, so stability in what you get from MikroTik becomes important, since on the "flashfig" path you do not control without more scripting/reboots/etc (more time).
A lot would be solved if you could "lookup" the factory-version for a device, and what version(s) ship on them... today that's only found buy buy a new batch (or sometime even with same batch of MikroTik devices bought). IMO the "factory version" should actually be immutable, and version shipped on a particular device should at least be predictable and documented someplace. Even a few extra columns in the www.mikrotik.com/products/matrix "CSV" could easily track the factory-version so there is no guessing... If something like factory-version could change over life of a devices, well that seem like a perfect "callout" in help.mikrotik.com so at least there awareness of that possibility.
Just my two cents, since while I think OP issue is seemingly minor, it is why I say there remain "holes" in "mass provisioning schemes" since it exactly stuff like this bites someone by surprise. And, yes, if everyone used netinstall you are more "protected" against...but they do support other schemes and other invented their own on top with custom business logic. e.g. something like KNOT may be included as part of large system, so the MikroTik device is a mere component that you'd rather not have "flakey" and "support"/fireld tech/docs/etc may all need to be re-aligned if something changes in "MikroTik land" for your larger product/service/offering ...
Well, the issue is that MikroTik does not want to add a “v5” (for example) tag to each device when the hardware has changed. That happens when there is a big change (like another processor) but not when there are relatively minor changes like a different flash chip or maybe in this case LTE modem chip. Changes that should be invisible to the end-user. I know that at least in the 4011 and the 5009 it has happened before that the factory version increased without noticible difference and you suddenly could no longer downgrade. This may sometimes even mean that a device type that was originally shipped with v6.xx suddenly requires v7.xx, quite a dramatic change when you want to support them in the same network.
Of course there are reasons to hide these changes from the user (e.g. suppliers not ending up with a stock of Vn devices when Vn+1 is spotted somewhere, and people being reluctant to buy “old version”). But it is very inconvenient in cases like that of the OP, that is for sure.
It's that reading tea leaves that gets old on these topics. Here I can speculate the factory was ready for manfacturing of KNOT, and the "plan" was to use the new 7.20.8 long-term... but the software was not quite ready/shipped when the factory was ready to run, so early one shipped 7.20.7 since it was "close enough" and "someone can upgrade later" and we/MikroTik not going to waste $xK on delay to wait for it. And when 7.20.8, shipped factory updated it to use "long-term" since the was the orginal plan.
I just have sympathy that someone may have done a lot of system testing using one version, and now faced with a decision "do I need to repeated that for 7.20.8?"... abstractly, depending on reliability goal of course, but generally "changes should be tested". Critically the KNOT use case are different from a hAPax3...why I highlight the "mass provisioning" angle since it more pronounced on something like the KNOT.
The question is not what was the current version at the time of shipment, the question is what version was set as “factory version”, a label that should have been “minimal version”. Devices are shipped with some RouterOS and Firmware version but have a lower “factory version” for them, which can even be different (i.e. a Factory Firmware higher than the RouterOS factory version).
So it is not (and this has been posted by MikroTik people as well) just a random version that happened to be available at the time, it is an indication of what release will fully support the device you have. There are cases where you can downgrade a device new out of the box to an earlier version than that comes with it. When that isn’t possible (as in the case of the OP) there is a good reason for it.
I think main point was they changed that "underlying assumption" based on OP's reporting. And it's not always true that units ship with "current stable", in past seen same models with various versions... could be distribution channel differences for sure... just saying they make a batch, those have some factory-version and shipped-version for some set devices manufactured - so it be good if that were "written down" someplace. So just knowing a unit could be version 7.20.7 or 7.20.8 is helpful, and if new "in-flight" batches are using 7.21.4 or 7.22.2? Some CSV with this info go a long way and/or help.mikrotik.com that formalized whatever is already going on.
No, it is not surprising that a new unit comes with some version (7.20.8) that is not the current long-term or stable version. What is different is that factory-version was set to 7.20.8 as well, which means that 7.20.7 does not run on it.
That is not just a matter in which batch it was made, that means that the devices he received now are hardware-wise different from the ones he got before and that could run 7.20.7 (either factory installed or upgraded to that).
This is not related to new devices being shipped with 7.21.4 and then a factory version of 7.20.8. Because the user who cares about exact versions could downgrade them.
Rather rude, but yes I can read. Again, I'd rather READ it from MikroTik not us kibitzing. The OP highlight some assumption changed... the specifics matter less to me, than the "assumed truth" being violated.
And no where in MikroTik docs/website/etc does it say the factory-software cannot be moved up, and thus "break" someone who depended on it. Since they do not state anything about factory-version other than:
The factory-software is the oldest version supported by this device.
but what it does not say is it never changes or any temporal reference... so from MY READING, they can change it to version whenever they want, i.e. if viewed with a "glass is half-empty".
This is what I wrote above. That, together with “The factory-software is the oldest version supported by this device” which you quote above should be enough to assume that factory-software is not being arbitrarily increased for new production batches. The fact that it has changed points to a hardware change, not to some “oh we have this new version so let’s put that on the devices currently in production”.
But our latest batch came with 7.20.8 as both factory version and installed version
