That just doesn’t make sense. Even starting from version 7.0 migration was supported officially. Of course there were many problems, and depending on your usage scenario versions below 7.10 may be completely unusable, but with every higher version it generally becomes better.
(of course new bugs are also sometimes introduced)
I advise you to study the material cited above and the experiences posted by users on the forum before trying the upgrade, especially on critical or remotely located devices.
In my opinion it doesn’t, all it states is that 6.49.8 includes the fix which was implemented in 6.49.7. The release notes for neither reference this CVE being fixed, so I don’t see how the inclusion or absence in 6.48.7 LTS can be inferred.
Given that 6.48.7 LTS was released 2023-May-23 it should include any critical vulnerability fixes which were included in 6.49.7, released some seven months earlier, otherwise what’s the point of having an LTS branch? And why wasn’t there an LTS release at that time either?
Thanks!
Not tested on 6.49.8 but probably applies to this version as well:
Security Issue: Changing rights / disable / delete the users has no effect on already logged in users. [Tested on 6.48.7 and 7.10.2]
http://forum.mikrotik.com/t/security-issue-changing-rights-disable-delete-the-users-has-no-effect-on-already-logged-in-users/168574/1
That was a bust. Upgrading from previous long-term did not go well on a 750gr3.
Basically lost all entries in all but one address-lists, and even the one that had entries had been truncated badly after the upgrade (~29000 entries showing only). What is interesting is that the address lists names were showing in Winbox, even though there were zero entries in each (command line showed zero as well). Needless to say that device was borked for service and had to be replaced with another device that was on site (a cold-spare backup of the same device that unfortunately had 2.5 year old configuration). Total number of address-list entries in the pre-upgrade configuration was just shy of 70000, of which about 69000 in one address-list (both static and few dynamic entries) another address list had 846-900 static only entries in it and another 6 address lists had between 3 and 25 static-only entries.
Another lesson learned - always make and download a backup of a device before upgrade.. I didn;t expecting that this was a simple long-term to long-term upgrade with changelog identical to currently running release.
Maybe you should read the first post in the release topic:
Before an upgrade:
- Remember to make backup/export files before an upgrade and save them on another storage device;
Probably the storage in your device was full and/or the database had been corrupted. The same problems may have occurred when you simply rebooted the device without upgrade!
I would say 70000 address list entries is too much to ask of this low-end device, but I have no hard numbers for that.
Your problems are 99% sure not related to the upgrade or the new version.
My experience: I’ve had my hAP ac2 running 6.47.x and four lengthy address lists, two were IPv4 address lists (5.4k and 8.8k subnet addresses) and two were IPv6 address lists (1.9k and 2.7k subnet addresses). It was working fine with something like 0.5MB free storage (but I did have it installed with unbundled packages, this might have helped). Then I netinstalled the device to 7.9.1 and it worked just fine until I tried to install those address lists again. At this stage storage space was exhausted (with incomplete address lists installed) and I couldn’t even clear the address lists. But otherwise device worked fine. I don’t remember if there were any ill effects when rebooting device since I noticed the problem with lack of storage pretty soon.
So it was netinstall again, this time without those address lists (and with 0.8MB storage free).
Yes, I agree with @pe1chl that devices with less than 128MB storage (hEX has 16MB as well) should not be burdened with lengthy address lists … where “lengthy” is anything larger than 1000 addresses.
Yes, but hAP ac2 is even worse than hEXr3 because the ARM architecture uses way more space than MMIPS or MIPSBE.
Still, one has to understand that so many config items take space in the config database, and some of that space is not reclaimed when deleting them, so when it in fact is a kind of dynamic list that is regularly changed (downloaded from an external server, for example) it is even worse.
Well, I don’t agree fully with you pe1chl. Yes, the HEXr3 only has 16mg flash, which is extremely surprising. It is more expensive to buy 16mb flash chips than 128mb flash chips and has been for the last 4 years at least, but even with that:
a) after copying the lists from another device that had them, the full encrypted backup is 990kb. And a good part of that is PKI certificates.
b) the lists were not the last thing in the configuration, yet they are the only ones that got mangled. the configuration that is after the lists came over just fine
b) free space on the device with the lists back on is 23% - so 3.6mb - that is more than enough to backup the config
d) even if the space was not enough, MTK software should detect the inability to perform the upgrade successfully and abort it with appropriate log entries to ensure that the device remains operational.
It was unusual to have those lists that big, normally they get built by the router due to firewall rules hits, but once a month get pulled back, aggregated (and some other processing), and replaced with the aggregates, which reduce them to about 1200-1400 total entries. The update was done just a few days before this process.
New version v6.49.10 has been released:
http://forum.mikrotik.com/t/v6-49-10-long-term-is-released/169053/1