wait, what? So… if attacker gets access to sub 7.17 device they will upgrade to 7.17 to get the token, that will allow them to downgrade? 
That’s one part I said. Read my full comment and/or don’t quote an excerpt which makes no sense standalone quoted.
You seem to be forgetting that reverting “dumb” device to “uber-smart” device is one button-push/power cycle away. This is merely a convenience for people controlling thousands of devices. “Normal” users could simply ignore it, and their routers would lockdown after n hours post-upgrade. Resetting this password could be implemented the same way.
Actually, now that I think about this a little more, instead of forcing an arbitrary device setting requiring reboots and button voodoo, perhaps what we all are looking for is some “superuser” (superadmin?) mode that requires the knowledge of an out-of-band password, like the one you can find on a sticker on the device? This way all routers could start in “home” mode, and enabling superadmin mode would allow setting which features are available to normal admins, and which require superadmin.
Ways to get the superadmin password:
- remotely in /system routerboard menu - using this option would require a button-push / power cycle confirmation, and then it would be possible to see the password only once, before reverting to previous locked state. Admin would make a note of it, or, in our case, our management system would make a note of it)
- one exemption to the above would be the upgrade to 7.17 from a version that didn’t have the feature - it would be possible to see the password only once during first 24 hours after an upgrade.
Since this is only relevant to post 7.17 devices, the fact that some theoretical attacker could get hold of the password by upgrading to 7.17+ doesn’t matter, since they could already downgrade to whatever vulnerable version they wish without doing pointless steps.
Well, what is then this whole discussion about when it is all just a “button-push/power cycle” away?
You can really piss someone’s leg really hard by changing device mode to “dumb device” mode when physical access is not easy.
lte - added provider specific firmware update (FOTA) for Cosmote GR networks on Chateau 5G;
so can anyone explain in depth what is that? It could be interesting
I’ve been always using container running on USB on my Mikrotik device.
When tried switching from 7.17beta2 to 7.16 → none of the containers would start.
I’ve noticed, while extracting - they were filling up internal memory, despite usb device path is set for pulling containers.
Does anyone know - how to go back to stable and still have containers running?
And what about if Mk create a tool in Mk account portal like the branding tool that generate a special package that you install on the device and reboot that will allow to enable the device to advance mode
They can create some sort of authentication that validate that is really you that trying to perform that change..
Or something like that…
Or, hear me out, what if they just allow people upgrading to v7.17 to keep existing functionality and simply introduce these new lockdown measures on new devices? That would still improve security while simultaneously not screwing over existing users in some way or another.
ok, the main points of what I was proposing to ease this transition:
On first upgrade to 7.17, or initial power-on or netinstall with 7.17+
- Display or have available (/system/routerboard/get device-token) a secure device token string for a limited period of time (30 minutes)
- The admin can copy this token and record it against the device
- During this 30 minutes the admin can CHANGE the device token (/system/routerboard/set device-token=“newSecureToken”)
- During this 30 minutes the admin can SET secure device options as needed (downgrade, boot partitions, container use, etc) without being prompted to power-cycle/reset.
After 30 minutes/Second+ boot
- The device token becomes inaccessible (/system/routerboard/get device-token returns null)
- Changing secure device options, including the device-token would require adding the a device-token=“…” to the command to enable it without requiring a power-cycle/reboot - this critically enables enterprises/ISPs/SMBs to continue to manage these and any future options without visiting/remotely power-cycling devices
- The admin can also set the secure device options and device-token without using the device-token, but they will then be prompted to power-cycle or reset in the next 5 minutes
Rational
- This would give a ‘grace’ window for setting options without having to go through the power-cycle/reset procedure
- This would enable enterprises/ISPs/SMBs to record, and/or set their own device token in a way that works with their existing procedures
- For instance, unique device token per device can be recorded in a database using a script to obtain them in the 30 minutes post upgrade
- Or the admin can set a known device-token across a group of devices and have that recorded in a password manager
- It also allows for the existing set and require a power-cycle/reset procedure
This will not satisfy everyone, if your device is already compromised, then netinstall it, or ‘recycle’ it.
I would hope that it covers the vast majority of needs out there, and allows for easy integration with existing workflows, would work with scripting.
It is constructive, flexible, and I hope, achieves the presumed goal of ESTABLISHING a secure base in-case of FUTURE compromise.
On restart hap ac3:
No routes injected from pppoe.
No routes injected from LTE.
Uploaded 7.16 files, downgrade button did nothing → had a look, device mode probably.
Eventually, after rebooting for 5 times, got a default route from pppoe, downgraded via quickset.
Please Team Mikrotik can we have a new tester firmware for the AX devices to some what work with AX CAPS in CAPsMAN
the reauthenticating errors and disconnects are getting annoying and shouldn’t be there as we cant use the full functions on the devices.
PS yes i do have wpa3 disabled but why should i have to? and i have tried just about every trick test under the sun to get working from this forums but still no go
so has to be hardware / firmware / ROS
PPSS Yes i did a reset of the devices to default up dated all firmware all running current beta and a complete new config still issues GGGRRR
Maybe this is the time to “re-activate” the development channel.
It’s a beta. Issues are to be expected. If it doesn’t work properly for you, just downgrade and maybe try the next beta.
In case it was targeted at me: I have not the guts to try this beta at all. I am done with betas. First and last time I tried was 7.15beta6 and I had to involuntary netinstall because device did not boot up.
Coughy volunteered as tester for new firmware containing possible wifi fixes. That's why I proposed to use the development channel for that case. Testing channel progress is probably too slow. So let's use development channel to go edge.
Can Mikrotik team say that Kernel version that is used has nothing to do with the inability to do hardware offload of VXLAN, MPLS L3VPN and L2VPN, and several other features?
If you say that it has nothing to do with it, I will not suggest anymore that should be updated.
But, SKDs of switchchips are offenly demanding that kind of updates.
So you Don't read the forums??
there is literally everyone complaining about the AX series in everything Mikrotik
so we are all trying to get a fix and get the working hardware we all shelled out good money for to work as Mikrotik have marketed it to do
but so far nothing fix's the ax series Wi-Fi is behind the competitors And very unstable since its release
it has been Meany months now and still no fix this is why we try betas and try to get them more often
lets be honest here we don't need all the 1000000000 implementations they doing on the next beta
LETS JUST GET A SOILD PLATFORM and FIRMWARE to start with and all its features working as intended like the AX series then they can build up from there
then i wont have to come on here and ask every few weeks for a new beta as my devices will just WORK
cheers rant over
Please TEAM Mikrotik solid base to start then use betas to add and test
I would like to see the development channel back for this area to test
On this development testing
Why cant we have the update broken down in to smaller manageable updates like the list is so long
to be honest I’m not interested or wont to no about 1/2 of it but some do
so why Mikrotik team cant we break the updates down in to like 3 or 4 sections and use the development update as like this
7.17 beta2 A with 1/3 of fix’s with base ros
7.17 beta2 B with next 1/3 of fix’s with base ros
7.17 beta C with last fix’s with baser ros
7.17 beta2 as all combined
this way we can test and see if anything is fixed on a smaller beta
so this way i can test the areas i need to test and should get faster betas as im not waiting for all the tests to get finished which im not worried about really at the moment
and i can test the ones i wont to test and upgraded firmware’s
please consider this option
so we as end user don’t loose customers and or hardware becaues it is getting silly now
my hapax3 was released with 7.8 and it still isn’t working as intended after NUMEROUS updates
So pls think about us the end user
No, I don't read "the forums", the signal to noise ration is too low in many cases. I read selected threads in this forum in search of information and maybe to contribute some information if I just found a way to solve or work around an issue. If you have issues with your stuff, open a support ticket. Once they start working on your bug they might even give you test-firmwares which address just your specific thing. It really works 
In my experience so far Mikrotik are a lot more responsive than what I am used from the likes of Cisco and Fortinet …
I guess everyone has it's own perspective. I for one do not have issues with AX on my Chateau, it is running quite fine. But again: If a beta fixes a bug for you, that's great. That means it will quite probably also be fixed in the next stable. If there are new issues (so far I see none for my setup), please open a bug report so it can be fixed for next stable.
Creating support ticket is the most effective tool we have.