For starters, I have a fleet of hAP AC2 routers that’s in the multiples of thousands of devices (among other models). Over the last month or so I’ve been receiving a number of cases of the hAP AC2 where the INTL hardware has been relabeled as US version, either by putting a US label sticker over the INTL sticker or even adding “-US” in sharpie. At first I thought this was a one-off thing, but having spoken with my distributor it’s now confirmed they are coming directly from MikroTik like this. While that by itself isn’t a big deal, what is a big deal is that these units also come with device mode lock enabled and set to basic or home (forget what it’s called) instead of advanced as is the norm, and that lock is much more time consuming to deal with than on units that were manufactured natively as US versions and don’t need unlocked.
For anyone doing large-scale provisioning, the difference is significant.
On routers properly manufactured as US models, configuration/programming runs smoothly.
On these rebadged INTL → US units, the process becomes a major time sink.
To put numbers to it:
-
It takes ~30 minutes of extra time per case (20 devices per case) to deal with the rebadged units.
-
I have 37 cases being ordered in the next 1–2 weeks, which would mean ~19 additional hours of configuration time just because of the device-mode behavior.
Out of the past 6–7 cases I received, 5 were rebadged INTL units with the device mode lock issue, so this is not an occasional occurrence anymore, it’s starting to look like a normal thing.
The problem isn’t that they don’t work, I do have a process to deal with them, but at scale when programming hundreds of devices it becomes a real burden. For integrators, MSPs, ISPs, and anyone doing batch rollouts, that time adds up very fast. And from a distribution/reseller perspective, I can easily see these having a much higher return / trouble-ticket rate, because many users are going to hit configuration roadblocks.
My objective here is to make sure that the right people at MikroTik hear this, and understand it’s a problem, and that customers who are orders not just ones and twos of devices, but dozens of cases at a time, many hundreds of devices at once, need this behavior to stop and consistency in the products we are shipped. Device Mode as designed is already a horrible implementation (whomever thought a power cycle to confirm needs fired, and worse whomever decided to ship routers that even block file uploads like .npk and .dpk files?!?) If you want to ship a router that has default devices restrictions, make certain that the user confirms they want it when they first login, don’t lock us service providers doing bulk installations out of using the devices before we even get our hands on them.
Even something like changing the minimum ROS version for a device causes issues, because when you are supporting many thousands of routers, stability of the build is your absolute #1 concern, far far far far above any new features being added, so being forced to switch from a proven and tested stable version that’s predictable and reliable to one that’s unknown and unproven, just because the new batch of routers arriving is locked to a minimum version, sometimes forces us to adopt versions before we consider them to be stable and proven.
I would love to have a conversation with the team in Latvia to discuss how MikroTik can help be a better manufacturer for companies like mine that are buying hundreds of thousands of dollars of their equipment per year, but even multiples of 6 figures USD of annual spending don’t get a phone call, much less an account manager to talk through problems or feedback with (which ironically would be the first piece of feedback I would give them, provide their larger customers account managers for feedback and dedicated support).