v7.17beta [testing] is released! - Page 2 (2024)

(NB: Quotes below are paraphrasing, not literal quotes, obviously)

Sorry, but people upgrading on a unit with a factory version <7.17 (or whatever build this feature eventually ships in) need to /at least/ have an opt-out from mandatory device-mode (I would sooner device-mode was opt-in for these devices).

You have made an ideological decision about hardening the O/S to prevent abuses in a way that you admit you have no evidence for, and just expect your customers to eat a truck roll to every remote device to re-enable btest.

Make this feature apply to devices with factory >7.17, fine, make that improvement, as you see it, to improve the security posture going forward. Over time, all devices still in active use will have the feature.

We're going to need the ability to manage this using netinstall, by the way, before this becomes a stable feature. Surely you understand this. There is no reason to rush this out before the tooling is available to properly manage it, when you have no evidence that this is a extant, much less significant threat.

"end user devices do not need btest!"

in your opinion and even if that was universally true*, end user devices in their house/office actually are not the problem. We can ask those end users to push buttons, if we really needed to, even though you are now mandating a full outage just to enable diagnostics in a situation where maybe only a (perceived) service impairment exists.

"What if hackers (that we have no evidence actually exist) exploit any bypass to enable nefarious features before you upgrade to 7.17? what then?!!??!"

ok, well, you have already said that all 'already enabled features' will be preserved on upgrade. So you have already built a bypass for /most/ of these dangerous features that these theoretical** hackers could exploit, they just have to turn on these desired nefarious features before carrying out the upgrade. Just not one that allows us to preserve btest client on devices already in the field, something we want available on every device we have deployed (in our case, mostly RB4011, RB5009, CCR*).

Zooming out:

The problem is not *only* the inconvenience of having to make end users push buttons and reboot their routers just to enable btest to/from their device, but also the many tens of thousands of mikrotik devices that are deployed without someone nearby to push buttons, that are not just sat on a cupboard in a home. It is not clear to me why you seem to think you only sell direct to consumers. You are disabling btest *and* btest-server on every single device. Even if we accept the premise that this is to save consumers from themselves, how many consumers who need "protecting" have a CCR2004+ in their home?

Don't make your service provider customers - the people who I wager are responsible for actually driving a sizeable chunk of mikrotik devices into the homes and offices of end users, rather than consumers selecting these routers for themselves - eat thousands of man hours collectively on fixing existing deployed devices to make them behave as they did when they were deployed.

Deliberately and materially changing the way an existing device works in any way that requires physical intervention is just a cardinal sin for a network vendor, IMO. If a service provider has to send a team out to push buttons, they might choose to just change the device entirely to another vendor whilst they're there.

Please, seriously, reconsider this implementation to instead make it opt-in for devices with older factory releases, and also please stick a pin in it entirely until it can be fully customised with netinstall. There is - by your own admission - no need to rush this.

* (it is not, at all - we and I am sure the vast majority of service providers use btest routinely during diagnosis, as every mikrotik we supply to an end customer is /managed/.)
** (remember how quick you were to scold your customers and their "theoretical" situations they have illustrated where device-mode harms them. You are taking a decision to implement something that you think will improve against theoretical attacks, and implementing it in a way that will cause actual harm to your paying customers.)