Upgraded without issues my hAP ax^3.
I don’t know what you have done in beta4 or more probably in beta5, but the wireless is much improved. It’s stable as hell and I’ve got 647 Mbps in speedtest (5GHz, no supperchannel, WPA-3). That is, it was able to use all my 600 Mbps connection and it seems it could do more.
In previous versions it was much worse. So, thank you and keep up the good work!
A previously created webfig status page does NOT work, despite the release note… I upgraded a wAPacR with status page showing LTE stuff, running 7.16.1 to 7.17beta5 — no status page is shown.
Tried on RB1100AHx4 by downgrading from 7.17beta5 to 7.16.1 — to test the status page. RAID mounted, but didn’t show any files - not sure why…but a 2nd reboot (apply firmware) did get the files. But then containers still didn’t start and showed nothing in log . Dunno why those would break in downgrade…
I added a status page under 7.16.1 and upgrade back to 7.17beta5. Disk and containers did come back once at 7.17 again. But like wAPacR, the status page was GONE in the “improved” webfig on RB1100 too… So the “old status page config will work” commentary was not my experience. I use the “status page” to provide a “customer friendly” dashboard – so I know that they do need to change over time. So even if status pages was correctly “preserved” that won’t help for too long (i.e. the .id of the status page element may need change). While the status page far from ideal… but now I got nothing for a customer friendly view.
And that’s going to be on top of not being able to test speeds remotely. I got sold a Swiss Army knife, but now getting a very stylish butter knife.
On a positive note :). I have a KNOT with LoRa (+ 3rd party temp sensor) running 7.17beta5, connected to mosquitto and an old erlang lorawan-server container on RB1100 to run entire LoRaWAN ecosystem entirely on RouterOS. This has [surprisingly] worked flawless in 7.17 (other than the various broken RAID issues I’ve reported) … while previously in 7.16 with the same setup, the KNOT occasionally seems to lose LoRa messages over time (which could be a lot of things too). So despite the long list of IOT and LoRa changes in 7.17… those did NOT break anything. And FCnt is pretty useful to check for lost messages. The KNOT is actually one of my test devices for a few months, and it has not had any issue with beta/rc from 7.15+ - why y’all don’t hear about that one as much as the wAP and RB1100 ;).
Still it’s one step forward, two steps back here…
and others
Are you guys serious? People who have their devices "on mountains" or other similar locations, ALWAYS install some kind of additional device that allows to power-cycle their hardware by remote request or automatically by timer or if some condition is met. Of course if they are adequate and don't want to "sponsor helicopter teams" or "send someone on a trip".
I was trying to figure out why the new version was bricks on my ax3. I decided to load my backup to CHR 7.17b5 on VmWare. Yes, I know it’s not right, but this is the experience of investigating the problem.
As a result, I got a cyclic reboot.
I attach a screenshot.
I suppose my ax3 has the same effect.
Dear MikroTik,
I’d like to suggest focusing on enhancing the “flagged status” feature rather than restricting the default feature set of RouterOS. A better approach might be to analyze system configurations for abnormalities. Many forum threads highlight cases where users have been hacked and locked out of their systems—often showing the same warning signs. These cases could serve as excellent references.
The “flagged status” is already a strong foundation. As it stands:
If the system has this flagged status, the current configuration works, but it is not possible to perform the following actions: bandwidth-test, traffic-generator, sniffer.
Why isn’t this enough?
I think improving the analytics to better detect unauthorized or compromised systems would be a far more effective solution.
Looking forward to hearing your thoughts!
There’s one other detail in being hacked/locked out as well. Intruder can disable button/jumper reset before changing the password and that can really make device a paperweight for the owner. Therefore flagged status should take care of re-enabling jumper/button reset as well.
There’s one other detail in being hacked/locked out as well. Intruder can disable button/jumper reset before changing the password and that can really make device a paperweight for the owner. Therefore flagged status should take care of re-enabling jumper/button reset as well.
good point !!! 
What? 
If anybody disable the button/jumper reset method and login credentials is unknown then that device is bricked forever? Can’t support revive it either?
netboot aka netinstall is initiated by reset button press.
agree 100% !!!
Hi,
I’m working for an ISP and we use a lot of Mikrotik devices on customer sites. BTest is a very important feature for us for validating and supporting. Please don’t disable it in advanced mode. I can understand that you want to make product for home users with some security but in this case please create a different brand than Mikrotik home users. Disabling things like btest is just like giving us more difficulties to make our work. We don’t need that.
Regards,
Jerome.
*) container - improved container shell;
Any details?
On the flip side of the Coin, I buy Mikrotik Gear to keep ISP’s OUT!
Strange world we live in.
about device-mode - install-any-version.
how to get that?
By the push of a button or power-cycle 
I have this remote-controlled robot arm for sale:
lol