Something NEEDS to be done about the default passwords

millenium7 · Wed Apr 19, 2023 4:17 am

MikroTik need to keep it for EU compliance, frustrating as hell and should not apply to products sent outside the EU but whatever..... the main issue is make the password readable!
Stop using characters like O/0/I/l/1/8/B as trying to decipher what they are gets really old really fast after repeated failed attempts on every device. I don't want to play a game of chance on every mikrotik device I have to set up
And for gods sake make the font readable, change both the font and the size, It's utterly horrible on a hAP AX2
And add a barcode so it can just be scanned, doing this process manually over and over and over again in bulk is a nightmare

Buckeye · Wed Apr 19, 2023 5:43 am

Good ideas.

If you find it hard to distinguish between B and 8, what about Z and 2, or S and 5 ?

I particularly like the suggestion about the bar code.

Did you have a specific recommendation for the barcode type?

Wed Apr 19, 2023 8:40 am

Oh yes, those are known letters to make almost anyone trip.
1, i, l, L, I ?
o and O or 0 ?
Presents nicely here but use another font and you're started for a guessing game ...

AX2 is bad (I've got that one too) but have a look at AX Lite. A lot worse (and what makes it even more worse, there is almost 30% blank space on that label so they could EASILY have made the font larger)

I come from a time where I, O and X where forbidden characters for product codes or passwords (X was a wildcard character).

I like the suggestion about barcode. But what are you going to use to read it ? Not everyone has a barcode scanner (ok, most smartphones can handle it too but that may be the wrong medium when you're in front of your computer, so extra steps to be taken).

Wed Apr 19, 2023 8:54 am

Solution could be to combine part of a serial number or MAC address which are unique and eg. 4 random letters printed in CAPITAL on a sticker.
These 4 letters could be quite BIG on a sticker and MAC could be read from the rest of a sticker or from WinBox

Buckeye · Wed Apr 19, 2023 9:07 am

Just found this with google

Characters to avoid in automatically generated passwords

A good font makes a big difference. OCR B used to be my favorite, but Consolas (the default in Windows Notepad) is much better (as the zero has a slash).

Consolas is much better than arial.png

But it is still best to avoid things that can be easily confused (especially when having to read them in poor orientation and lighting conditions).

There should be something obvious in the packing/box that tells users they should copy it into their password manager before deploying to an inconvenient location.

Buckeye · Wed Apr 19, 2023 9:15 am

Solution could be to combine part of a serial number or MAC address which are unique and eg. 4 random letters printed in CAPITAL on a sticker.
These 4 letters could be quite BIG on a sticker and MAC could be read from the rest of a sticker or from WinBox

That's not a very large set to brute force. Especially for a local user that can see the mac address and knows the "algorithm". 4 random capital letters is 26^4 possibilities, or just under 1/2 million 456,976. That's much better than no password, but a pretty low bar from a security standpoint.

Wed Apr 19, 2023 9:22 am

But remember:
It's JUST a DEFAULT password needed to obey EU rules.
Add the 5th letter to the "suffix" to make it stronger.

Wed Apr 19, 2023 9:27 am

Convenience is the worst enemy of security.

Do it properly or not at all.

millenium7 · Wed Apr 19, 2023 11:03 am

Convenience is the worst enemy of security.

Do it properly or not at all.

This goes way beyond 'convenience', these sorts of random passwords absolutely will result in a lot of pointless e-waste, financial waste and needless man-hours solely because the device got factory reset and can no longer be accessed due to credentials being inaccessible (company out of business, stickers faded/lost/removed etc)

There are a lot of better ways to handle this. But regardless this is beyond the scope of MikroTik as it's an actual regulation requirement

What is in MikroTiks control is what I'm referring to in my initial post. The way they've done it is horrible and needs to be rectified
'Bring a magnifying glass and keep trying combinations of 1/I/l/8/B/0/O until it works' is not a better security mechanism

Wed Apr 19, 2023 11:16 am

I hear you (loud and clear) and something definitely needs to be done.

But lowering the standards towards something which can partly be extracted from existing info is not the correct reaction.
That was the mean intent of my response.

Znevna · Wed Apr 19, 2023 11:39 am

And remember that we're at this stage because of the various clueless "installers" that contributed with customer devices to botnets over the years, leaving them with no passwords and management exposed to the wild internet.

I'm sure that if you convince "The one and only Kevin Myers" (as MikroTik likes to call him, some celebrity for some reason) that there's something wrong with the quality of the printed passwords and that he has to tell MikroTik about it, MikroTik will do something about it.

Wed Apr 19, 2023 12:58 pm

Convenience is the worst enemy of security. Do it properly or not at all.

BTW ... what if I reset configuration to factory settings. Is that password set to the printed one?
If yes than it has to be stored somewhere in ROM or it is generated by an algorithm and based on ... who knows what on ... but the algoirithm could be reversed so the level of security falls down like a crashing plane

If we netinstall what happens then? Same question arise.

Wed Apr 19, 2023 1:17 pm

Yes it does (so I understood) but that would already require physical access to the device.
As it was in the past (no password) anyone could potentially gain remote access if device was accessible from outside.
And then the botnets had their fun ...

Same with a key of your house.
You can copy it but you first need to have physical access which is already more difficult.
(don't get me started on those electronic key fobs for key-less cars...)

Someone REALLY putting in the effort, will ALWAYS be able to gain access to your house, your car, your router, ... whatever. Some way or the other.
The point is to make it enough difficult so they loose interest.

Wed Apr 19, 2023 1:44 pm

So what is the problem with random 4 letters as a suffix to the part of serial number .. which is different as well each time ... as a default password?

Is it random? Yes, it is.
Does it obey rules? Yes, it does.
Is it easy to print four big letters on a sticker ? Yes, it is.
Could you set better password? Yes, you can.
If somoeone has physical access to the router makes it difference how complex is the password printed on the sticker? No.it make no differnce.

That's not a very large set to brute force. Especially for a local user that can see the mac address and knows the "algorithm". 4 random capital letters is 26^4 possibilities, or just under 1/2 million 456,976. That's much better than no password, but a pretty low bar from a security standpoint.

If we limit letters to distinguishable enough we loose a lot of randomness and security.
https://www.lexology.com/library/detail ... 09983ab184

bpwl · Wed Apr 19, 2023 2:52 pm

netinstall what happens then? Same question arise.

Well my intended workaround was ...
Netinstall with custom script, that sets 'my' password, or adds an 'admin enabled' extra user ?

Klembord-2.jpg

Wed Apr 19, 2023 3:25 pm

So what is the problem with random 4 letters as a suffix to the part of serial number .. which is different as well each time ... as a default password?

Extending the serial number might be okay, depending on how difficult it is to make the router give it up over a LAN link. The only measure I'm aware of is "/export", at which point you're logged in already, but I worry that I'm missing a side channel.

(Don't tell me to restrict WinBox access to a super-special administration VLAN. This default password measure is clearly not for people who were already doing that.)

Appending it to the MAC, as I believe I have seen proposed, is a terrible idea, since the router announces that to anyone who asks. Even if you turn off MikroTik's discovery protocol (CDP) it's easy to nmap the subnet and check your ARP table for any of the 16 MAC prefixes currently assigned to "Routerboard.com." At that point, your password-guessing attack devolves to the half-million case calculated above, at which point all that saves you is the router's rate limiting features.

I've just had a hAP ax² through here for testing, and I've still got an "ax lite." While I do support the inclusion of default passwords, I can tell you from direct experience that they are indeed currently printed too small, and in fuzzy text besides. This exacerbates the problem of ambiguous characters.

Someone brought up use of better fonts, but at these sizes and at these low printing resolutions, arguing over fonts is like holding a debate over whether the red or the blue crayon will produce more legible refrigerator art.

anav · Wed Apr 19, 2023 3:39 pm

You have to purchase the add-on. The Llama MT Password Reading Magnifying Glass!!
All proceeds go to lobbying MT to add Zerotrust Cloudflare tunnel as an options package.

Wed Apr 19, 2023 4:29 pm

The Llama MT Password Reading Magnifying Glass!!

You joke, but while I do have solutions to that problem, they all suck:

The benchtop illuminated magnifier with auxiliary lens I bought for micro-soldering works great for reading the new password labels, but only when I'm in my lab, it being clamped to a workbench several feet from the nearest computer that'll run WinBox. It's back-and-forth until I can transcribe the immemorable string of noise a few characters at a time.
The Sherlock Holmes style magnifying glass I inherited from my grandmother solves the mobility problem, but only when I'm at home, and I look like a twit using it besides!
My smartphone's camera/magnifier app lets me take the pic at the router, then transport it to where I actually need to be to use it, but my hand shakes, blurring the already blurry text.

The final option is the one I'll actually use, since it also gives me a backed-up record of what the default was should the device ever be factory-reset. I just want a better chance of a readable shot given my shaky hands and the low lighting where these routers get placed.

Wed Apr 19, 2023 5:19 pm

I reverted to x3 zoom using my smartphone and then take a picture at the moment of unpacking. Not even applied power to the device.
(and yes, might require some object to rest your arm/hand on to have an as stable as possible picture and adjusted lighting).

That picture then immediately goes into my password vault so I got the MAC address of the device and accompanying passwords with it.

AX Lite is the worst I have seen so far. That's simply stupid how that is done (no disrespect meant to anyone but it is what it is).
I also don't understand why it has to be a different format/printing/layout for each and every device type.

millenium7 · Wed Apr 19, 2023 5:55 pm

Barcodes would go a very long way to helping this situation. Not everyone has a barcode scanner, but it's a pretty easy sell if you have to configure lots of them
For individual units and field techs at least they can use a phone to snap a pic and have it convert that to text. At least it would.be correct and not mix up ambiguous characters

If Mikrotik wants to go this route (I am highly in favor) then the barcode should be printed both on the device AND the box
The device only needs a single barcode for the password
The box should have 2 or 3
- password
- Mac address
- optionally the serial number

This way inventory can be easily and rapidly scanned as it comes in using a barcode scanner and saved into records. Box does not need to be opened it can go immediately into storage/shelf/van/whatever and will be ready for use
It's very simple to open up records and do a search for MAC/Serial and find the corresponding password for the device. Importantly it will be accurate. The way it is now is highly error prone. Photos of text alone can (often are) blurry and unreadable, it needs to be a regular old barcode

mkx · Wed Apr 19, 2023 6:27 pm

The box should have 2 or 3
- password
- Mac address
- optionally the serial number

While this would definitely make life of an ISP easier, it would also expose lots of sensitive information to whomever would have a chance to see the box. Specially if S/N would be included (due to how MT's own DynDNS works).

IMO includiing this information inside the box would be enough, possibly on a sticker right below the cover of box so a short peek inside would do. Breaking the "genuinity seal", so the buyer would be alerted if somebody did it (ISPs could re-seal the box with their own company-branded adhesive tape to put customers' minds at ease).

mada3k · Wed Apr 19, 2023 6:29 pm

Will this apply for higher end models as well? (like CCRs) What will happen when you do a reset? Go back to the on-label password?

mkx · Wed Apr 19, 2023 6:34 pm

When you reset a higher-end device, you're screwed anyway ... re-reading the garbage-like password from hardly readable label will not be the biggest problem IMO.

But then it might not apply ... those come without any sensible default firewall which is a giant security hole as well.

Amm0 · Wed Apr 19, 2023 6:48 pm

Barcodes would go a very long way to helping this situation. Not everyone has a barcode scanner, but it's a pretty easy sell if you have to configure lots of them

I believe the kids call them QR codes and when read by a mobile device's photo app can launch a URL.

On idea be that the QR code launch the Mikrotik mobile app, which then display the relevant wi-fi/admin password in LARGE font. I'm not sure it can do both, but QR code can also connect to a Wi-Fi network – but think the mobile app can offer to connect the Wi-Fi after the password/wi-fi was displayed.

+1 to a QR code

mkx · Wed Apr 19, 2023 7:01 pm

On idea be that the QR code launch the Mikrotik mobile app,

Well, if mikrotik app would be made to read QR code, then why not, it could automatically connect (via MAC connectivity). But idea to mandate to use any kind of proprietary app (or even connect to some internet server) is a horrible idea. There are generic QR code readers (many of which support reading various kinds of 1D var codes as well) and those should be able to display in code embedded information ... loud and clear.

millenium7 · Wed Apr 19, 2023 7:07 pm

Not a QR code, should just be a regular old barcode
QR codes work better for things like wifi passwords as it can contain a lot more information (such as URLs) but provide no benefit in this instance and have some drawbacks
- most handheld barcode scanners don't do QR codes
- much slower to read/recognise
- much harder to read when not perfectly clear or in focus

I'd be in favor of preconfigured wireless SSID and password with a QR code directly on the device for easy connectivity, but not for admin password/serial/MAC

Buckeye · Wed Apr 19, 2023 8:28 pm

Not a QR code, should just be a regular old barcode
QR codes work better for things like wifi passwords as it can contain a lot more information (such as URLs) but provide no benefit in this instance and have some drawbacks

I thought that one of the advantages of QR codes was the built in QR Code error correction feature, with level H providing 30% reed-solomon redundancy.

I haven't seen the labels, the only MikroTik devices I have are RB260GS (CSS106-5G-1S), RB760iGS (hEX S) and RB5009, none of which came with the labels.

If the labels are large enough, they could have both QR and some other 1D (linear) barcode, but as far as I know, these 1D barcodes only provide error detection (e.g. a check digit), not correction capability.

bpwl · Wed Apr 19, 2023 8:49 pm

What is the story here? I'm confused. Multiple scenario's mixed together?
In my cases ... This is not an ISP owned Home AP, where the customer (me) does not even get the admin password, but just a limited user password.
The printed password on the bottom of the device is that user password, and the wifi password.
And that user cannot change the user password, and has no admin rights (fortunately the wifi SSID and PSK password can be changed)

As an owner of the Mikrotik this password is "the initial power-on password" ready for the first setup, and which is reset to the same value when the configuration or device is reset to default.
(soft or hard, reset button pushed, unless Routerboot protection is on). With initial setup the password protection is there. So if you are lazy or ignorant there will be a username/password already set.
You do not leave that password unchanged, do you ? So the operational password, after setup, and any MAC relation of it or not, is just your choice.
Already most of you on this forum will rename the "admin" user name or replace it with another user, as good security practice.
Legislation may enforce that there IS a password when the device is delivered, so it is not operated without password, out of the box.
Legislation might even enforce that this password modified later may not be blanc or a copy of the default user name.

The initial password comes in the picture again, when you or someone else does reset the device. And that's when the potential lockout or desperate password search starts.

E.g: I'm not happy with the printed password on the Cube60 side. Those Cube things are outdoor. Very easy to read the information by anyone passing by.
Changing that password, to my security experience, should be mandatory, before you put it outdoors. Otherwise it is' "the key under the doormat" security.
Even worse: It's the wifi link password, and the admin password. It's the same on both sides for the "wireless wire" kit with Cube60. Export the initial config and you have it documented.

millenium7 · Thu Apr 20, 2023 1:30 am

What is the story here? I'm confused. Multiple scenario's mixed together?

There are plenty of scenario's where random default passwords are atrociously piss poor. The only one i'm addressing specifically in this thread is the difficulty in reading it as its so small and uses ambiguous characters. This is bad for everyone, from the single device thats privately ordered to be used as their home router, up to ISP's that do mass deployments
Especially for the latter as no barcode makes this incredibly difficult to do at scale, netinstall is not always an option either and it isn't a very good one. Plenty of scenario's I can give as to why thats bad, here's just 1 - you aren't configuring them all in the same physical location, you're a managed service provider doing this at multiple locations remotely. An extremely common occurrence of this is deploying gear on radio towers

---------------------------------
If you want to look at the regulation as a whole and why its incredibly bad, there are plenty of scenario's that can outline why its just not the right approach. For instance

- CompanyX who is a MSP for many clients goes insolvent and all credentials die with them (as well as the stickers over the years), this may mean sending hundreds or even thousands of otherwise perfectly good working devices to landfill as there is no way for any other company to take over the operation of the deployed gear by simply factory resetting it, as the password is gone. Multiply this across the entire industry, a hell of a lot of pointless e-waste

- Devices on radio towers and remote sites, this is going to be an utter nightmare for a lot of people. Where something happens like a failed upgrade, misconfiguration, software bug, [insert whatever here] and the device needs to be reset and reconfigured (many vendors have procedures to do it from the ground). This is a fairly trivial task to perform with a laptop by a field tech or remote assistance to get it up and running again. Except oops we don't have what is written on the sticker so now someone has to climb the tower and read it, except the sticker has faded from the elements. Even if the sticker was intact it means you can't use Bob who is currently onsite to get the site back up and running, as Bob does not climb towers. Now you need to arrange Steve to fly out to the remote site in the middle of nowhere and climb the tower just to read a sticker

- MikroTik and any other manufacturer may potentially be able to assist in the above instances, but even ignoring the insane inconvenience and impracticality of having to attain serial numbers across who-knows-how-many physical locations and awaiting responses from support on each device individually. They may goes out of business at some point in the future and that completely eliminates that possibility

Not to mention this regulation does NOTHING for devices that have inherent vulnerabilities and exploits which is often how devices get compromised without ever needing the know the login credentials

Thu Apr 20, 2023 2:29 am

netinstall is not always an option…you aren't configuring them all in the same physical location

You know what we need to fix that problem? A global network that will let us coordinate data across multiple sites, each with their own local network, like an inter-network kind of thing.

Hey, I know, we could call it The Internet Superhighway.

Hmmm, needs work, but I'm on to something, I'm sure of it.

deploying gear on radio towers

I agree…you should not attempt netinstall at the top of a tower.

there is no way for any other company to take over the operation of the deployed gear by simply factory resetting it, as the password is gone.

I haven't tried it, but my understanding is that "netinstall-cli -s myscript.rsc" lets you apply any password you like during the reinstall. You get the default password again only if you do "netinstall-cli -r".

oops we don't have what is written on the sticker so now someone has to climb the tower and read it

What kind of mickey-mouse shop are you running there that you don't keep that in a database somewhere? If the passwords of devices in remote, difficult-to-reach locations are available only on a label on the device itself, your management controls are…wanting.

this regulation does NOTHING for devices that have inherent vulnerabilities and exploits which is often how devices get compromised without ever needing the know the login credentials

Yes, you're so right: one mitigation doesn't solve all problems.

This one only solves the problem where people install routers without changing their passwords, permitting LAN worms to trivially add your router(s) to a botnet, merely by having a table of default user names and passwords to try.

Don't you think that risk is worth killing dead? I do.

Amm0 · Thu Apr 20, 2023 5:24 am

I'm not normally the Mikrotik apologist, but I do think they are trying here. Like Wi-Fi, each country has rules... but on default passwords, way more varying regulations. Here in US, even each state can theoretically have their own rules (AFAIK only California does). I don't get the impression this password stuff was Mikrotik's idea. And no amount of complaining is going to change the law.

Should they improve the implementation of it? YES! There are plenty of good ideas and concerns to mitigate. As titled "Something NEEDS to be done about the default passwords". It seem to me there missing a "help page" with devices and cataloging the approach to managing it. Various threads cover them, but it should be documented formally.

While I get Mikrotik like their no-notice "surprise features"... but on the password defaults, being 100% clear on what devices this does or WILL apply is more critical. Especially if it is going to bleed into "ISP" things. But I suspect they won't do that unless really forced by regs. So at this point, I'm not sure anyone is putting a hAP ax* on tower. If you were...well, powering it on before climbing be a good idea as first step anyway, and that be a time to set the password (and other settings you may not want to be doing at the top of a tower). If these hAP ax* devices are ISP CPEs, you'd like want to netinstall and/or use branding package already anyway...

rextended · Thu Apr 20, 2023 12:45 pm

Please, we can discuss everything, but not about some i–ot who mounts antenna on tower before even set it up and tested it.
We don't talk bullshit. If someone really does it (to mount them on tower without EVEN trying it first) they deserve it...

With netinstall, which also works remotely (if anyone doesn't know it), and which will be added on RouterOS 7.10+ as a standalone feature,
for companies that really work on it, there isn't the slightest problem for passwords.

millenium7 · Thu Apr 20, 2023 2:09 pm

We've done plenty of mergers/acquisitions of equipment. Doesn't matter how perfect 'your' records may be, if you take over responsibility for other equipment you have get absolutely zero documentation and your only option is to factory reset the device to take over control of it. Well now you can't do that due to the randomized password
Has nothing to do with pre-configuring the device before it goes up. Even the idea of netinstall is terrible because of the exact above situation, it's no better than a randomized password as that gear is unserviceable to anyone other than you and your company

Think outside your own box, I don't care how perfect you personally feel your record keeping is. That just isn't always the case in the real world. Even inside the company you work for there is a very real probability that projected forward there is a change of policies/restructuring/employees leaving/whatever that screws up your perfect system
I've seen it time and time again with people that have the very best of intentions with documentation and it eventually falls apart for XYZ number of reasons. This just tells me you havn't seen many environments outside of your own

rextended · Thu Apr 20, 2023 2:34 pm

I'm not here to brag about this or that. I'm talking about facts.

If you need to take control of MikroTik devices for which you don't have the credentials, don't you still have to reset them?

Your reasoning makes water from all pearts:
If you have the credentials and you reset them... Well you have the credentials and you can keep them in the reset (or change default-script-on-reset).
And if you have the credentials you can run netinstall without climbing the tower.
If you do not have the credentials you must have physical access to the device, therefore password or not you must go up the tower,
and when you go on top, if is possible the reset from there, who cares about the password if you use netinstall...

A different matter is if they have protected-routerboot enabled.
Now that's a problem if you don't know the password or the exact time...

Larsa · Thu Apr 20, 2023 2:44 pm

@Millenium7, totally agree with all the problems involved in taking over someone else's network and lacks adequate documentation is definitely more common than the other way around. Been there, done that as they say.

And as @Ammo pointed out, formal documentation really needs to be put in place, at least regarding equipment for professional use.

Thu Apr 20, 2023 5:37 pm

the idea of netinstall is terrible because…it's no better than a randomized password as that gear is unserviceable to anyone other than you and your company

Someone else's password is as good as random already.

Or that's the idea, anyway, since the alternative is that you can guess the password, which means anyone else can pull the same trick off, thus giving it nearly no value over having no password at all.

If you were expecting to be able to walk up to a router someone else installed and used to manage, but get full admin access on it without a reset of some kind, you're either dreaming or hoping for a world without any security at all.

Buckeye · Thu Apr 20, 2023 11:32 pm

Does someone have a link to the actual EU requirements?

I would think the following would be at least part of the requirement.

When a consumer router (one that is expected to be used by a non networking savvy user) is taken out of the box, it should be:

easy to setup by the user
Not a clone with a fixed access password that can easily be discovered online with a google search for "default router password".
The SSID should not be a fixed string like "MikroTik" so multiple routers in a high density apartment will not "interfere with each other" by default, i.e. allow roaming between different networks.
There should be a randomized password on the wifi (if the device does have wifi), and it should use at least WPA 2 by default. (to avoid accidental roaming to another access point with the same SSID)
The "Internet" connection should have a firewall and not accept any connections for local services (with possible exception of icmp) by default. (no ssh, no web, no winbox, no http, no telnet (in fact I would argue this should not be enabled even on the local side by default), no SMB, UPnP disabled on Internet, best if not enabled on LAN by default).

The reason for not having a fixed password (that only works from LAN side) is to protect against an "infected PC" inside the walls of the firewall (a trojan horse). Management from the WAN interface should already be disabled by default.

I am not sure if the standard would care about protecting against someone with physical access to the device. I think the primary concern is "no touch" ability to gain access to the router with the ability to make configuration changes.

Although I do think that the MicroTik devices make reset too easy; i wonder how many routers have been reset by toddlers, that seem to love to push buttons, especially if doing so will result in sound coming out later. I prefer the hole with a paper clip that is inconvenient enough to make "accidental" resets nearly impossible.

Thu Apr 20, 2023 11:55 pm

At your service

https://www.etsi.org/deliver/etsi_ts/10 ... 10101p.pdf

Page 8 is where it really starts.
IoT is to be taken as a very broad term... as in: every consumer network device connected to internet.

4.1 No universal default passwords
Provision 4.1-1 All IoT device passwords shall be unique and shall not be resettable to any universal factory default
value.

Many IoT devices are being sold with universal default usernames and passwords (such as "admin, admin") for user
interfaces through to network protocols. This has been the source of many security issues in IoT and the practice needs
to be discontinued. Following best practice on passwords and other authentication methods is encouraged. Device
security can further be strengthened by having unique and immutable identities.

mkx · Fri Apr 21, 2023 12:09 am

I guess some will try to argue that Mikrotik routers can not be considered as "Consumer Internet of Things" ... but document states that it covers "... consumer devices that are connected to network infrastructure ..." and MT routers definitely are connected to network infrastructure. Now, are MT devices "consumer" devices? They are if they're sold "over the counter" to end users.

So, all those ISPs that need to bulk provision devices, unite in purchasing "non-consumer" variants of same hardware which come without the new security features and without any configuration what so ever (also without firewall, just like the "pro" line already does). And then make sure they do get configured according to policies set forward in linked document before you pass devices to end users or else you shall be deemed responsible for everything bad happening, including dog poop.

rextended · Fri Apr 21, 2023 12:10 am

The next step to unlock the device is to put the device to the gps position of the first power up...

Buckeye · Fri Apr 21, 2023 12:25 am

The next step to unlock the device is to put the device to the gps position of the first power up...

So send back to factory testing location?

rextended · Fri Apr 21, 2023 12:48 am

The next step to unlock the device is to put the device to the gps position of the first power up...
So send back to factory testing location?

It was a joke, but some garmin gps you can really unlock them where for the first time (outside the factory) they lock the gps...

millenium7 · Fri Apr 21, 2023 1:55 am

If you were expecting to be able to walk up to a router someone else installed and used to manage, but get full admin access on it without a reset of some kind, you're either dreaming or hoping for a world without any security at all.

You are completely missing the mark here. Not one person here is assuming you leave the default password (or lack of one) alone and use it indefinitely. That's idiotic and not what anyone is talking about
The problem is when you need to factory reset it. You also need a method of getting in and reconfiguring it. If it's randomised and the password is lost/missing/whatever then the device needs to be removed and scrapped needlessly

This idiotic EU regulation is dragging the rest of the world down as it has the simplistic viewpoint you cling onto, that you and your company are the only ones that would ever touch the device, you have fairy tale levels of perfect and accurate records from now and until the end of time, and the default password is never needed beyond the initial install

Regardless this is not what my original post is about, it's about not making this process as painful as possible with miniscule fonts, ambiguous characters and no method to onboard/configure/document in bulk, I.e. barcodes

Buckeye · Fri Apr 21, 2023 2:02 am

https://www.etsi.org/deliver/etsi_ts/10 ... 10101p.pdf

Thank you!

Those appear to be guidelines from 2019-02. Is this now a requirement? If so, when did it become law?

So it oddly doesn't include routers (but it did say non-exhaustive list). Another odd omission is printers. I think the primary goals are "secure by default", at least more secure.

What does "shall not be resettable to any universal factory default value." mean. Does that mean you shouldn't be able to manually create a user admin and set the password to admin? Or does it mean, when the "factory reset" is activated, it should not return to a "universal value"?

Since I have no affected device, and have never used netinstal myself, can the devices be reset using netinstal without knowing the password (given physical access)? I see that as much less of a problem than being able to initiate a reset without a password or physical access from the LAN side. I think the primary goal is to avoid a small set of "master keys" that be used to access many devices from an infected computer, to enlist devices into a "bot army" that can be controlled from the internet. As long as some phyical action is required (e.g. pushing a button for a prescribed amount of time or some pattern, e.g. pulsing a number of times, like it used to be possible to dial a phone using only the handset disconnect button), then I don't see this a threat of someone on the internet gaining access without resorting to social engineering. "Hello, this is <name of ISP>. We have had reports of problems in your neiborhood. Is your router working? Oh, good to hear the problem isn't affecting you. So we can know what devices are being affected, and not being affected, can you please tell the your Router ID? Yes, it is printed on a label..."

4.1 No universal default passwords
Provision 4.1-1 All IoT device passwords shall be unique and shall not be resettable to any universal factory default
value.
Many IoT devices are being sold with universal default usernames and passwords (such as "admin, admin") for user
interfaces through to network protocols. This has been the source of many security issues in IoT and the practice needs
to be discontinued. Following best practice on passwords and other authentication methods is encouraged. Device
security can further be strengthened by having unique and immutable identities.

woland · Fri Apr 21, 2023 11:02 am

Hi, here are my 2cents: the ETSI regulations are not the (only) reason, they are more about IoT.
I think it´s rather the GDPR (Data Protection), which is manadatory in the EU. https://op.europa.eu/en/web/eu-law-in-f ... aa75ed71a1
The GDPR itself does not mandate such details, like the "password must be unique". But it says: data protection through technology design and secure by default principles must be implemented.
Then there is an implementation guide, which further refines, what is meant by data protection through technology design:
"Guidelines 4/2019 on Article 25 Data Protection by Design and by Default Version 2.0 Adopted on 20 October 2020" https://edpb.europa.eu/sites/default/fi ... 2.0_en.pdf

Basically it´s just requiring to do something, which is considered to be enough to keep data private. This must be effective and state of the art.
It´s not a technical description, it´s lawyers speak, so there is always room for interpretation, but the manufacturer has to do something, which is enough to not let anyone access your data.

Therefore everyone picks some security standards/frameworks. In Europe the most relevant one is mainly ISO27001. ISO27002 are the "controls" for the ISO27001, meaning something like an implementation guide. In there there is an Article 5.17 Authentication information, which basically says: personal passwords or PINs generated automatically during
enrolment processes as temporary secret authentication information are non-guessable and unique for each person, and that users are required to change them after the first use
There is also an Article about Secure Coding (8.28), which prohibits the use of hardcoded passwords.

So forget common sense and well defined rules, MT just had to do something which is considered to be enough, so that they will never have to pay a fine.
Fines can be very high for GDPR non-compliance.

Ps. there are hundreds of ETSI standards, which I might have missed

bpwl · Fri Apr 21, 2023 5:13 pm

Although I do think that the MicroTik devices make reset too easy; i wonder how many routers have been reset by toddlers, that seem to love to push buttons,

Not only toddlers ... impatient teens , just press the hAP ac2 reset button, when there is an internet outage, or a slower internet than they expected. The label "reset" and its place close to the power connector look like it will do just a fresh restart of the gateway, a softer alternative to power off/on, which they cannot do when the PoE ether1 port is secured. Where in fact it does a configuration reset to the default config.

rextended · Fri Apr 21, 2023 5:29 pm

The routers that I supply can not be resetted (I rent only CPE and MikroTik AP)...
Just activate the protected-routerboot and just by pure chance, or someone who knows the exact time, manages to reset them...

Amm0 · Fri Apr 21, 2023 7:38 pm

I stand by the need for some doc, not video, on this topic as relates to the DEPLOYMENT changes that may be needed...

But I think it's important to separate out "Something NEEDS to be done"...as there are "minor" tweaks that help that Mikrotik should look at...
a. "O/0/I/l/1/8/B problem" is a very real – don't care: just exclude them or make longer/use lower case to keep same brute-force level
b. Font size can be increased and/or label rearranged to make easy to read – ax2 is even smaller than already too small ax3...
c. Include extra sticker in/outside/somewhere box
d. Use barcode, QR code, etc., so the password can be machine-read.

But how this effect mass/bulk deployment is TOTALLY different situation – that could be explained better in docs...

For example, In another thread, it was suggest putting the units into CAP mode by button gets you admin/nopassword. So if someone was using SSH/API/REST/etc script to provision the router – didn't test but seem like it should work. Only change be the need to hit the reset button for exact amount of seconds while powering to trigger CAP mode, and any previous external script should work (or only require minor adjustment).

All of the netinstall methods for bulk deployment are not really changed by the default password, since you can override them in a configure script (or branding). So if someone is using netinstall today for bulk provisioning, the default passwords are not a big change.

I know how all* the deployment stuff works myself after years of using Mikrotiks. But it's really is spread among protected-routerboot, default-configuration, reset-configuration, netinstall page, and scripting – but they all relate to bulk deployment – but to someone wanting see the "menu" of deployment choices, it's not easy to deduce without a lot reading/thinking. (*except flashfig, never tried that one).

Some unified "bulk provisioning guide" be mighty helpful in the docs I think.

millenium7 · Sun Apr 23, 2023 11:14 am

Just regarding netinstall...
Anything physical is a no-go on remote applications and isn't an appropriate solution. Even if you get a layer2 tunnel to every site (lets be realistic, its just not feasible en-masse nor on most radio tower installs) you need to physically do something to the device, that requires physical hands
The default password does influence this, if it were default/blank then you can have a script run that reboots it into network boot/netinstall mode
MikroTik does check for a netinstall instance on boot, but only on the first very power on. If you miss it, you need to either physically touch the device and hold buttons in just the right sequence, or use the random password and first login to do it

r00t · Sun Apr 23, 2023 4:27 pm

If Mikrotik really wants to be compliant to that directive, they can't just put random passwords on regular access and leave say API open with default passwords. That will just not be possible. Any login method that allows you to configure and use router in any way must be using random passwords to be compliant.
So only way out I see is what I described in another thread:
5 minutes after reboot with original unmodified default configuration, allow login as "netinstall" locally (MAC telnet) and this would trigger the netinstall procedure
While it's not as simple as current method, it would make automatic provisioning possible with some scripting. And it sidesteps the regulation about default passwords as you can't configure the router by rebooting it into netinstall mode. Time limit and requirement of original configuration with no changes are just safeguards this can't be used remotely later to DoS the device or do anything nefarious once configured.
As for scripting to do the provisioning, it would maybe take 30 seconds longer to do everything now due to netinstall, but hey... at least it would still be possible.

millenium7 · Mon Apr 24, 2023 4:04 am

I'm no lawyer but I wonder if they would remain compliant if they did revert back to a blank password, but the device is essentially unusable until a new password is set. All routing/switching/wireless functionality is disabled and nothing can be assigned except for very minimal management functionality. Even IP traffic only works via responses to incoming management traffic, it can't even so much as initiate an outgoing ping until a new password is set

This may still meet the regulations in that the device is essentially inoperable as a network device until the user intervenes and is forced to not just leave it with default credentials. As well as actually working for the rest of us as a sensible middle ground

Mon Apr 24, 2023 4:22 am

the device is essentially inoperable as a network device until the user intervenes and is forced to not just leave it with default credentials.

Hang on a sec. Your plan is to have a mode where someone remote can blank out the configuration and provide a new one, including a new non-empty password, in order to get around a regulation passed to avoid having routers completely taken over by LAN worms?

Are you proofreading your proposals or just throwing out a repeated wish for no security whatsoever?

Buckeye · Mon Apr 24, 2023 4:59 am

Hang on a sec. Your plan is to have a mode where someone remote can blank out the configuration and provide a new one, including a new non-empty password, in order to get around a regulation passed to avoid having routers completely taken over by LAN worms?

First, this would only affect new routers, if it wasn't possible to configure the router without setting a non-blank (possibly requiring using a password that wasn't one of the "common defaults" like admin/admit).
I assume your "attack senario" is something like the following:
1) before the new router is deployed, infect a machine "inside the LAN".
2) Have something to watch for MikroTik device announcements, and when a new one shows up, reconfigure it before the user has a chance to configure it with their own password. Note that configuring protected router boot now requires a physical press of a button on the router, at least that's my understanding.

So while I think that blank passwords are not good, I am not sure I agree that the problem is as dire as you make it sound. I do agree that what you state is a real possibility, I think that there are lower hanging fruit to worry about before that.

What if setting the initial password also required pressing a button within 1 minute after setting the password, and requiring the button to be pressed before the new password would be set, and configuration allowed. This would be slmilar to the requirement for setting up protected router boot, which was done to make it less likely for a remote attacker to be able to lock the local user out and make recovery hard.
Note that the "lower hanging fruit" is a human, unknowingly helping the attacker by doing things like pressing buttons, power cycling, etc. Hacking people (social engineering) is usually easier than hacking software. That's how most scams work; taking advantage of peoples trust and doing what they think is "the right thing to do" (e.g. rebate scams).

millenium7 · Mon Apr 24, 2023 5:27 am

Hang on a sec. Your plan is to have a mode where someone remote can blank out the configuration and provide a new one, including a new non-empty password, in order to get around a regulation passed to avoid having routers completely taken over by LAN worms?

Are you proofreading your proposals or just throwing out a repeated wish for no security whatsoever?

Are you actually thinking through real world situations and the implications?

Firstly its no worse from a security perspective than the current implementation, which is that MikroTik devices boot up and scan for a DHCP server with the appropriate options set (netinstall) which if a LAN is infected can literally do anything it wants. But this only happens once (first boot), subsequent boots do not happen thus aren't useful for people who actually need to work with the devices and might use that method. Having to push a physical button a subsequent time does not improve the security, it will still get hijacked
Secondly, since it can't do any routing or even LAN communication outside of management traffic, the device isn't useful unless 1) the password is changed and 2) the device is reconfigured

In a scenario that the LAN is infected, sure it could be taken over (and lets ignore about all other potential exploits that go beyond default passwords). But lets talk about the real-world implication, because i'm gonna go out on a limb and say a mikrotik device is probably going to be connected to a network segment and powered on, because it intends to be used in some way. Ergo its not useful in its default state to anybody, and if infected and taken over then the technician would not be able to log in as the password will have had to be changed for the device to be operational. Therefore they will factory reset it and try again. If it's still happening then there's clearly something wrong in the network. It must be on that same network segment since the device cannot do any sort of routing. At this point the network already has bigger problems, it's a bit like wondering if the front door is locked while there's already burglars inside and happily moving out all the valuables. We don't care about the front door at that point

I would argue its actually more secure in some ways than the current implementation of a fully working default config (including ability to obtain an IP, get to the internet and route traffic). If an exploit is found (as has been the case with MikroTik before, as well as many other vendors) then the password makes absolutely no difference whatsoever as it's simply bypassed. And definitely does absolutely nothing for devices that have had their password changed to something simple and insecure anyway

Mon Apr 24, 2023 5:48 am

I assume your "attack senario" is something like the following:

Partly, but I'm taking the OP's prior statements into account, where he's apparently in charge of a WISP that's taken over other smaller WISPs and now needs to take control of all the equipment they left behind and to do it without sending someone up a tower and without being able to recover the password. What I want to know is, how do you do that without giving everyone else the ability to do that, too?

OP sounds like someone who wants to point at a router on a map and say, "MINE," and never mind what this does to the rest of the world's security.

millenium7 · Mon Apr 24, 2023 7:27 am

You are impossible to get through to. No that isn't what I've been saying, you are twisting my words around and clearly you've not gone through any of the scenarios I've proposed and thus it doesn't make sense to you

rextended · Mon Apr 24, 2023 10:54 am

I haven't seen any practical examples yet from you, except highlight that you don't know how RouterOS works.
(I don't know everything either, but we are talking about this point of view)
In a nutshell, to take the control of 3rd party device (ignoring protected-routerboot, that make useless any reasoning about default password):
1) If you don't have the initial password, you still have to reset the device with physical access, and if you have that, the default password is not a problem.
2) If you have the initial password, all subsequent reasoning implies not knowing how to do your job,
if you can't reset the device and reboot it with the credentials one wants.

If you have access to an admin account, you can "default" or completely "blank" the router with your password and/or branding
and you can save the default password to a file for future reference, even if the label is not legible.

All this is valid until they change something about how RouterOS works now…

Mon Apr 24, 2023 1:25 pm

Passwords are available in CSV format from the distributor accounts.
You guys are good with scripts, come up with a script that takes these passwords from CSV as variables and uses them in your SSH mass config scripts

Or ... just Flashfig routers en-masse with some big switch.

anav · Mon Apr 24, 2023 4:08 pm

Just host a password server securely using Cloudflare ZeroTrust tunnel......
OOPS.......... we need to get that in an options package for all routers for that to become true.

)))

rextended · Mon Apr 24, 2023 7:24 pm

Passwords are available in CSV format from the distributor accounts.
You guys are good with scripts, come up with a script that takes these passwords from CSV as variables and uses them in your SSH mass config scripts

Or ... just Flashfig routers en-masse with some big switch.

[SOLVED]

Buckeye · Mon Apr 24, 2023 10:52 pm

Passwords are available in CSV format from the distributor accounts.

This seems like it would be a good solution for distributors, but what about a small ISP? And hopefully, the distributors only have the passwords for the routers they bought for resale, i.e. not all routers.

Mon Apr 24, 2023 11:28 pm

Passwords are available in CSV format from the distributor accounts.
This seems like it would be a good solution for distributors, but what about a small ISP? And hopefully, the distributors only have the passwords for the routers they bought for resale, i.e. not all routers.

distributor know passwords
distributor know which devices sell to you

i think is time to chat with the distributor about this

Mon Apr 24, 2023 11:30 pm

Passwords are available in CSV format from the distributor accounts.
You guys are good with scripts, come up with a script that takes these passwords from CSV as variables and uses them in your SSH mass config scripts

Or ... just Flashfig routers en-masse with some big switch.
[SOLVED]

just 3 lines hahahahahaha

BrianHiggins · Tue Apr 25, 2023 12:04 am

Passwords are available in CSV format from the distributor accounts.
You guys are good with scripts, come up with a script that takes these passwords from CSV as variables and uses them in your SSH mass config scripts

Or ... just Flashfig routers en-masse with some big switch.

Few problems with this
1) Distributors don't know ANYTHING about this, I already spoke Carl at Streakwave, he had not heard anything before I asked.

2) mass config scripts only work if the script is able to associate the device it's connecting to with it's specific password, so please explain how that will be possible, and get technical we want details. Will the password lists be indexed by serial numbers? by MAC addresses? If serial number, how does our setup script extract the serial number of a device it can't yet log into? If MAC address, exactly which MAC addresses will be contained in the document available through the distributors to us, because by default we cannot log into the devices through ether1, so if we're looking up the MAC address that we are connected to for a new device, then it will be ether2-ether5 that we are connected to (assuming for the moment we're talking about a hAP XXn type consumer router), will the document only list the ether1 and ether5 MAC addresses?

3) Flashfig seems to have been removed from current versions of Netinstall, and even when it was still there it never seemed to work EVER (I've literally tried it a dozen+ times over the years and I never got it to work even once). The entire reason we built our automated deployment process and need a predictable default password for the automated deployment tool to login is because Flashfig has never functioned even once for us.

4) If we are going to need to use a flashfig type process, can you document the protocol and/or release some open source code on how the PC side works so that it can be integrated directly into automated deployment processes?

5) assuming we are able to get a reliable and supported version of flashfig to function correctly, can you *guarantee* that every router you ship with a default password set will bootup correctly to the flashfig protocol so we don't have to login directly to the router using your temporary default credentials placed on a sticker?

5) Please answer my suggestion regarding creating an API which installers can get approved access to which will allow us to directly lookup these default from your system, once a device has been looked up once it can be blocked from future automated lookups, and you can record what installer did the lookup.

6) you already have an algorithm that you use to generate default SSID's [:pick $wlanMac 9 11]$[:pick $wlanMac 12 14]$[:pick $wlanMac 15 17] where $wlanMac is the wlan1 MAC address, device MAC addresses are only known within the Layer 2 segment they are connected to, why don't you use a similar algorithm that uses the ether2 MAC address to compute a default password for a given device. The password will be unique, they won't be reused, an attacker over the internet won't be able to eavesdrop anything that would contain the information needed to compute the password, a wireless scanner won't be able to compute the password from the BSSID or broadcast frames as the WLAN MAC addresses are not sequential to the LAN MAC address. You would be left with a password which is both 99.9% as secure as the one on a sticker, but also such that shops that need to do bulk installations can fairly easily integrate that into their process to allow enterprise installations (you know, they guys that buy hAP and CCR routers by the hundreds or even thousands every year, not one or two devices every 3-5 years).

woland · Tue Apr 25, 2023 9:44 am

Hi,

I got my first device with a default psw set: a HAP ax lite. I must say, the default psw is a pain in the a...
It´s printed with maybe 2,5mm character height? I had to take a photo and enlarge it to have any chance reading.
I am no WISP and don´t have to install hundreds of devices, but MT please have mercy on the endusers as well:
It should also be printed with a decent character size on a piece of paper, packaged with the router, or at least use somewhat bigger font please !

Tue Apr 25, 2023 12:05 pm

1. Distribitors got all needed information some time ago, please ask Your distributor to check their email and their account, where relevant info is shown in a giant popup.
2. Here is a real sample of the file the Distributor is able to give you:

"item_code","item","master_nr","serial_nr","manufacture_code","qty","soft_id","mac_first","mac_last","mac_count","imei","user","password","ssid2","ssid5"
"C52iG-5HaxD2HaxD-TC-US","C52iG-5HaxD2HaxD-TC-US hAP ax²","HAC19PAAK2B","HAC19PAAK2B","314","1","AFKW-BAAJ","41:A2:83:A0:1C:20","41:A2:83:A0:1C:26","7","","ADMIN","16YADDTAL8","",""

You should be able to do something with the first and last MAC

3. Flashfig is a separate app available on our download page: https://download.mikrotik.com/routeros/7.8/flashfig.exe

4. Can't do that, you can use SSH script to do a fully custom solution

5. An open APi to get passwords?

P.S: login is shown in caps for some reason, this is an error in the CSV generator, will be fixed. Password is correct as output.

Larsa · Tue Apr 25, 2023 12:35 pm

Instead of sending out a separate email to each distributor in pure text, why not publish a database that you can search by mac address? Way more easier!

Znevna · Tue Apr 25, 2023 1:06 pm

The .csv file is not sent to distributors in "pure text", pay attention.

Larsa · Tue Apr 25, 2023 1:26 pm

An open database to look for passwords? C'ome, it was a joke!

Ps....
Note to self: watch out using irony and offhand jokes.

rushlife · Tue Apr 25, 2023 2:09 pm

the stickers with password make me feel old

BrianHiggins · Tue Apr 25, 2023 10:50 pm

1. Distribitors got all needed information some time ago, please ask Your distributor to check their email and their account, where relevant info is shown in a giant popup.
2. Here is a real sample of the file the Distributor is able to give you:

"item_code","item","master_nr","serial_nr","manufacture_code","qty","soft_id","mac_first","mac_last","mac_count","imei","user","password","ssid2","ssid5"
"C52iG-5HaxD2HaxD-TC-US","C52iG-5HaxD2HaxD-TC-US hAP ax²","HAC19PAAK2B","HAC19PAAK2B","314","1","AFKW-BAAJ","41:A2:83:A0:1C:20","41:A2:83:A0:1C:26","7","","ADMIN","16YADDTAL8","",""

You should be able to do something with the first and last MAC

3. Flashfig is a separate app available on our download page: https://download.mikrotik.com/routeros/7.8/flashfig.exe

4. Can't do that, you can use SSH script to do a fully custom solution

5. An open APi to get passwords?

P.S: login is shown in caps for some reason, this is an error in the CSV generator, will be fixed. Password is correct as output.

1 & 2) We spoke and I think the confusion partially came from that the most recent order they got didn't have the imei, password, ssid2 or ssid5 columns in the list. This data, while not ideal (a lookup process from your servers would be better), does appear to provide a workable solution, though far from optimal.

3) the flashfig documentation should be updated, it still shows it as part of netinstall.

4) please elaborate on how you propose SSH (or anything) would be able to script flashfig

5) Yes, instead of you emailing a CSV file to the distributors for each container you ship, which means that for them to supply me a password they first have to find what container the device was shipped to them in, or build a database they can log and later search for the passwords in themselves, you should have that information in a searchable database that you grant limited access to, access for distributors, or access dealers like me who submit an application to you to gain access to the system (I'd even pay an application fee). You can log the fact that a dealer has looked up a password to a device, and to prevent abuse, once a password has been looked up once, you can "lock" that record and prevent additional lookups from any other dealer without going through.
It would be a simple to develop API (I could build the whole thing in a few days, and I'm not particularly fast at that), pass the correct authentication header to your API server with a GET request, something like https://api.mikrotik.com/lookup?firstma ... 3:A0:1C:20 and the server returns back:

 {
   "item_code": "C52iG-5HaxD2HaxD-TC-US",
   "item": "C52iG-5HaxD2HaxD-TC-US hAP ax²",
   "master_nr": "HAC19PAAK2B",
   "serial_nr": "HAC19PAAK2B",
   "manufacture_code": 314,
   "qty": 1,
   "soft_id": "AFKW-BAAJ",
   "mac_first": "41:A2:83:A0:1C:20",
   "mac_last": "41:A2:83:A0:1C:26",
   "mac_count": 7,
   "imei": "",
   "user": "ADMIN",
   "password": "16YADDTAL8",
   "ssid2": "",
   "ssid5": ""
 }

In conjunction with that return you update your database to show that my dealer ID has accessed that device / the device is "linked" to me, and going forward any other dealer ID that tries to access it will not see the password field in the response, if someone needs that field they will have to open a support ticket and provide the appropriate proof of ownership to you.

rextended · Tue Apr 25, 2023 11:38 pm

Do you have any idea of the extra workload, on this way, then there is for anyone?

Do you work with RouterBOARD?
Just netinstall-it-all.

1) Our distributor sends us all the devices he distributes already branded with a branding package and a default password which is not empty (but for us is the same).

2) When devices arrive in our labs, all individual devices are tested, it is not the end user,
hotel or tower installation the correct way and place to first test/set up a device.
The first step is netinstall ignoring completly previous or default password.
Our branding package grant on software reset (except on another netinstall, obviously) the same default password we want.

3) Our technicians already have the device ready. In case for any reason they need another,
they certainly don't go and buy it themselves, but it is already given to them ready by one of the labs.

4) In case of taking over work done by third parties, unless protected-routerboot is involved (that's another story),
it takes a moment to take control of the device if you have the credentials,
and a moment to reset it completely (without netinstall) by setting the credentials you want (and, if needed, apply the branding package at same time).
If you do not have the credentials (and the protected routerboot is not involved) the device must still be reset,
often open if they are devices that have MikroTik cards inside and the reset is not exposed,
so that you know the default password, or not, since they are resetting and reinstalling with netinstall, nothing changes.

5) If you do not know the password, if the device needs to be reset, you still need physical access and press reset.
If the technicians you use aren't even qualified to hold down reset at startup until the device appears on netinstall, that's another matter...

The final sum of what I wrote is:
A) For those who work seriously on it, nothing changes.***

B) For end users, MikroTik seems to have made an agreement with the opticians. All young people without vision problems in the company?

*** I still haven't read a valid example (other than protected-routerboot) where this default password is a problem.
But a concrete example, not bullshit.
Of course I too could be wrong, but for now I have no data regarding something insurmountable that you haven't made me consider yet.

Wed Apr 26, 2023 7:59 am

I did not say you can script Flashfig. I gave an idea how you can modify your existing SSH scripts to get the password and pass to the SSH script.

Just to get the ball rolling

./script.sh 41:A2:8A:9F:FA:CC
"9D1HA45GAYG"

script.sh:

#!/bin/bash
mac_address=$1
awk -F "," -v mac="$mac_address" '$0 ~ mac {print $13}' data.csv

most likely you want to use the SERIAL NUMBER, as this is on the barcode of the device.

You can just execute the SSH script that sends your config, and the script asks for your SN, where you beep the barcode scanner and it pastes the SN into the script. The script gets the password from your CSV database.

Easier is to use Flashfig though.

Wed Apr 26, 2023 8:25 am

So with my example above and with a basic barcode scanner, you can have a workflow like this:

1. plug PC into port 2 of the router
2. run command
3. scan barcode
4. router is provisioned

Flashfig could be faster. There is no mass-config because all IP addresses are the same (and they were before, nothing changed)

millenium7 · Wed Apr 26, 2023 8:48 am

*** I still haven't read a valid example (other than protected-routerboot) where this default password is a problem.
But a concrete example, not bullshit.
Of course I too could be wrong, but for now I have no data regarding something insurmountable that you haven't made me consider yet.

If you havn't had a situation where you have had to take control of devices that were previously owned or managed by another company, then you've not had much exposure to the networking or managed services industry as a whole. It's a very real scenario where device passwords are lost (or just never provided in the first place) and devices need to be factory reset. Stickers absolutely do get faded/damaged/removed as well
If you cannot even envision this as a real scenario and see the very real issues posed by having randomized passwords, then as far as i'm concerned you are woefully unqualified to be weighing in on this argument. No better than the opinions of a school student on how the real world works

Even if we ignore everything past 6 months from now and don't give a crap about how many pointlessly trashed devices this stupid EU regulation will cause, MikroTik's implementation right here and now is still utter trash. Just print the damn thing on a sticker that is readable, and put a barcode on so that it 1) be read and understood 2) be used to mass config devices
@MikroTik please tell me why this is a bad idea. Why is your existing solution so fantastic that it doesn't need any reworking or improving

Wed Apr 26, 2023 8:49 am

the sticker has only the DEFAULT password which you must change.
this is not comparable to "I inherited a router that somebody password protected"

millenium7 · Wed Apr 26, 2023 8:55 am

the sticker has only the DEFAULT password which you must change.
this is not comparable to "I inherited a router that somebody password protected"

Yes it is normis. Re-read what I said as you clearly misunderstood it
If I factory reset a device then guess what password it gets? THE DEFAULT ONE
And if that password is lost (for any reason at all) then the device is garbage and must be replaced, even if it was otherwise working perfectly because it cannot be logged into and reconfigured out of its default state

I am perfectly fine with keeping records of passwords of equipment I manage (though as has been mentioned over and over in this thread, make it readable so as to avoid mistakes in recording them)
But I do not control the rest of the world, I cannot make every other person and company out there to do so, nor force them to hand over said details when they lose a contract or go out of business

Wed Apr 26, 2023 8:55 am

have you read my posts at all?

Rox169 · Wed Apr 26, 2023 9:04 am

Normis,

when I change the password and do reset of the device what will be the password for the device? Will it be the password on the label? Im just worried after many years the sticker can peel off and I will need to reset device I will be in trouble.

Thank you

Wed Apr 26, 2023 9:20 am

Please read above discussion. Label is not the only place where you can get the password.

millenium7 · Wed Apr 26, 2023 9:21 am

have you read my posts at all?

Yes I have, there is some merit in theory but not always in practice
1) I may not have any clue who the original distributor was of equipment that I take over. Or I may not have access to get those records
2) Netinstall/flashfig is a PITA at best, and completely useless at worst. Even when I have physical access to the device and am configuring it in an office, i've not had a 100% success rate (not even close) with it. Doing so remotely is an enormous PITA as I can't use my own physical hands to get it into that mode and retry several times over. At the end of the day its a huge downgrade in functionality and usefulness of just a default/blank password

That said, #2 is something I can accept as not really being in MikroTik's control right here and now, as its an EU regulation requirement. However if you can find a better method (such as what I proposed, device being useless until its password is changed) that meets the EU requirements as written and no more, or any other way of bringing control back then i'm all for it

But what I can't accept is leaving the current stickers as they are and pretending there's no issue with them. The size and font is horrible, the use of ambiguous characters is very poor practice, and no barcode so it can't be mass read and deployed is hugely detrimental and a massive waste of time typing out manually. Something I expect from a D-Link home router perhaps, not MikroTik gear which is clearly used en masse globally and not just one off home products

Wed Apr 26, 2023 9:27 am

So let us repeat the basic facts, so that everyone is up to speed:

1. If you know Serial Number or First/Last MAC address, you can get the password from Distributor or MikroTIk (only if Distributor is unknown, so that MikroTik support is not overwhelmed)
2. Password will be on the device itself and also on a similar sticker on the quickguide paper inside the box (in later batches)
3. Netinstall can remove the password
4. Flashfig can reconfigure the device with other config (that can include a different password).
5. Netinstall CLI version will be able to mass-reinstall routers sometime soon (still need to boot them with pressed button)
6. You can use a barcode scanner to scan serial number label and paste the password directly, when using a script that parses the CSV file you can get from Distributor (see above example)

rextended · Wed Apr 26, 2023 10:50 am

[...]
If you cannot even envision this as a real scenario and see the very real issues posed by having randomized passwords, then as far as i'm concerned you are woefully unqualified to be weighing in on this argument. No better than the opinions of a school student on how the real world works
[...]

Here's another user, like others who have already been banned twice in a month on this forum, who begins to talk about graduation and various bulls–t.

I'll answer in your own way, since you keep saying that I'm not able to do or understand, or I'm not qualified enough.
You are unable to do "your job", for two reasons:
1) Who cares about the default password.
2) Netinstall fails, due to RouterBOARD, only if the device is broken or has protected-routerboot enabled and you don't know the time.
As you can see, these two points alone are enough to make your statement of not being able to take control of a MikroTik device ridiculous:
it is you who are not able to.

Obviously I am referring only and exclusively to perfectly functional MikroTik devices and which do not have the protected-routerboot active.

EDIT: The problem of labels not correctly readable or with misunderstood characters will now be corrected in the next batches,
it is impossible to fix what is already put in distribution.

woland · Wed Apr 26, 2023 10:52 am

Thank you very much @normis!

Looks like MT listens to it´s customers, which I highly appreciate!

Amm0 · Wed Apr 26, 2023 5:58 pm

Password will be on the device itself and also on a similar sticker on the quickguide paper inside the box (in later batches)

Thanks!

BrianHiggins · Wed Apr 26, 2023 7:01 pm

Do you have any idea of the extra workload, on this way, then there is for anyone?

Do you work with RouterBOARD?
Just netinstall-it-all.

you don't seem to understand that THIS REQUIRES LOGGING INTO THE ROUTER FIRST. you can't take a brand new hAP AC2 router out of the box and simply netinstall it, you have to log into the router first to change the boot settings.

1) Our distributor sends us all the devices he distributes already branded with a branding package and a default password which is not empty (but for us is the same).

Lucky for you, but you don't understand that this means the issues I and others are bringing up apply just as equally to your distributor, because this is essentially exactly what we do for our customers. You are not dealing with the same issues we are so stop telling people it's not an issue simply because someone else has to deal with your problems. Did you even consider that your distributor might not even be able to continue doing for you this as a result of this change, or they may charge you extra money to continue to do so?

2) When devices arrive in our labs, all individual devices are tested, it is not the end user,
hotel or tower installation the correct way and place to first test/set up a device.
The first step is netinstall ignoring completly previous or default password.
Our branding package grant on software reset (except on another netinstall, obviously) the same default password we want.

You are referring to the branding package that your distributor installs for you, so you don't have to deal with the problem being discussed here that you're telling everyone else to stop complaining about and just deal with?

3) Our technicians already have the device ready. In case for any reason they need another,
they certainly don't go and buy it themselves, but it is already given to them ready by one of the labs.

While this is irrelevant to the conversation about default passwords, just for comparison so you don't feel too special, we too supply the routers ready to plug in and be used by the end user without any configuration needed onsite when the install is happening (because we've automated the whole process).

4) In case of taking over work done by third parties, unless protected-routerboot is involved (that's another story),
it takes a moment to take control of the device if you have the credentials,
and a moment to reset it completely (without netinstall) by setting the credentials you want (and, if needed, apply the branding package at same time).
If you do not have the credentials (and the protected routerboot is not involved) the device must still be reset,
often open if they are devices that have MikroTik cards inside and the reset is not exposed,
so that you know the default password, or not, since they are resetting and reinstalling with netinstall, nothing changes.

Again, this is irrelevant to the challenges caused by shipping routers with random default passwords.

5) If you do not know the password, if the device needs to be reset, you still need physical access and press reset.
If the technicians you use aren't even qualified to hold down reset at startup until the device appears on netinstall, that's another matter...

the whole point of this thread is that the default password being set creates a huge slowdown in provisioning of new devices, and nearly impossible to do them at scale. NOT that it makes it impossible to configure routers one at a time. No one programming routers one at a time cares about the default passwords. Come back and talk to us when you're programming a couple hundred routers in a single day.

The final sum of what I wrote is:
A) For those who work seriously on it, nothing changes.***

There's no question you understand scripting better than most people, but it sounds like you have little to no experience doing bulk deployments and what is required to deploy hundreds of devices cost effectively or quickly.

B) For end users, MikroTik seems to have made an agreement with the opticians. All young people without vision problems in the company?

finally, something we agree on! I have excellent 20:10 vision and even I have trouble reading those damn labels. Once they get a little faded it's straight impossible.

*** I still haven't read a valid example (other than protected-routerboot) where this default password is a problem.
But a concrete example, not bullshit.
Of course I too could be wrong, but for now I have no data regarding something insurmountable that you haven't made me consider yet.

You are so confident you know the answer already, you failed to even comprehend the problem. The issue was never that the default passwords prevent configuration of the router, it's that the default passwords break the workflow of automated deployment tools that are necessary for enterprise users like myself to be able to deploy hundreds of routers in a single day and do so profitably. manually running netinstall on every router would add hours upon hours to every project and require significant changes to the workflow which add cost and complexity and raises overall operating costs to perform installations. When your business model relies on the ability to do efficient deployments at large scale, something that adds 5 minutes for you adds days for me.

And of course that's ignoring the fact that you won't actually deal with issue because apparently your distributor is the one that will be suffering while you tell everyone that it's so easy to just netinstall and stop complaining.

rextended · Wed Apr 26, 2023 7:18 pm

you don't seem to understand that THIS REQUIRES LOGGING INTO THE ROUTER FIRST. you can't take a brand new hAP AC2 router out of the box and simply netinstall it, you have to log into the router first to change the boot settings.

*** ALL ABSOLUTELY WRONG ***
It seems to me that it's you who don't know how the devices work...
Netinstall launches with the reset button without even having opened winbox or webfig before...
Another user who says he has problems with the default password because he doesn't know how the product has always worked...

[...] You are not dealing with the same issues we are so stop telling people it's not an issue simply because someone else has to deal with your problems. [...]

Another bullshit, if you read, I wrote that I don't give a damn if it arrives already branded by the distributor or not, I netinstall it instantly without even putting the password...
Another use that do not read...

2) […]
The first step is netinstall ignoring completly previous or default password.
Our branding package grant on software reset (except on another netinstall, obviously) the same default password we want.
You are referring to the branding package that your distributor installs for you, so you don't have to deal with the problem being discussed here that you're telling everyone else to stop complaining about and just deal with?

No, it says exactly what it says: The first step is netinstall ignoring completly previous or default password.
Our branding package = Our branding package, not the distributor package, understand the differencies?
Another user looking for another meaning in what has been written...

[…]
Again, this is irrelevant to the challenges caused by shipping routers with random default passwords.
[…]

Don't you read what other peoples write?
The topic is from @millenium7, the OP, who worries ALSO about when to take over other networks, so I'm also replying to him, not you.
Another user who doesn't read all the posts, but only some...

Did you join the discussion later, did you think you were the only one I was replying to?
I remind you that I'm not bragging, I wouldn't gain anything, I'm just indicating how things go, because for me the default password changes absolutely nothing...
Physically the device must be taken out of the box and connected to the ethernet directly on ether1.
First run netinstall, installing at the same time branding OR autoconfig script, by holding reset without never use winbox or CLI
is faster than
running commands via another cable on one ethernet on bridge by CLI, and then wait for it to reboot for netinstall on ether1...

Amm0 · Wed Apr 26, 2023 8:13 pm

Like it or not, I think all roads go through netinstall for the mass deployment scenarios. No amount of discussion is likely going to change that home device will have a default password. No doubt this is PITA, but needed and totally manageable IMO.

I think there are some under-appreciated advantages to "always netinsall" - even if it means re-training for your staff...trusting that the devices come with a "good version" is NOT always true & and ensuring all version match in the field is generally desirable.

If you doing "hundreds per day", did you talk with your distributor and/or sales@mikrotik.com to see if you can place a custom order for ones without passwords. I'd imagine that be possible at HIGH volume, but dunno.

BrianHiggins · Wed Apr 26, 2023 8:29 pm

Like it or not, I think all roads go through netinstall for the mass deployment scenarios. No amount of discussion is likely going to change that home device will have a default password. No doubt this is PITA, but needed and totally manageable IMO.

I think there are some under-appreciated advantages to "always netinsall" - even if it means re-training for your staff...trusting that the devices come with a "good version" is NOT always true & and ensuring all version match in the field is generally desirable.

If you doing "hundreds per day", did you talk with your distributor and/or sales@mikrotik.com to see if you can place a custom order for ones without passwords. I'd imagine that be possible at HIGH volume, but dunno.

I've already worked out a solution with the distributor to supply the raw password file data so I can match the mac address the deployment system is currently connected to and lookup the password. It's a bunch of extra work, and it causes extra work for the distributor also which they aren't thrilled about, but it should enable us to continue working after this rolls out.

I've talked to them about custom production runs, we're not doing enough volume yet to justify it due to the minimum order quantity. We aren't doing that kind of volume each and every day, but whenever an order comes in we generally have 2-3 business days to turn the order around with the correct config loaded on the routers, and those orders can be hundreds of routers per order, and sometimes multiple orders come in at the same time.

BrianHiggins · Wed Apr 26, 2023 8:55 pm

you don't seem to understand that THIS REQUIRES LOGGING INTO THE ROUTER FIRST. you can't take a brand new hAP AC2 router out of the box and simply netinstall it, you have to log into the router first to change the boot settings.
*** ALL ABSOLUTELY WRONG ***
It seems to me that it's you who don't know how the devices work...
Netinstall launches with the reset button without even having opened winbox or webfig before...
Another user who says he has problems with the default password because he doesn't know how the product has always worked...

[...] You are not dealing with the same issues we are so stop telling people it's not an issue simply because someone else has to deal with your problems. [...]
Another bullshit, if you read, I wrote that I don't give a damn if it arrives already branded by the distributor or not, I netinstall it instantly without even putting the password...
Another use that do not read...

You are referring to the branding package that your distributor installs for you, so you don't have to deal with the problem being discussed here that you're telling everyone else to stop complaining about and just deal with?
No, it says exactly what it says: The first step is netinstall ignoring completly previous or default password.
Our branding package = Our branding package, not the distributor package, understand the differencies?
Another user looking for another meaning in what has been written...

[…]
Again, this is irrelevant to the challenges caused by shipping routers with random default passwords.
[…]
Don't you read what other peoples write?
The topic is from @millenium7, the OP, who worries ALSO about when to take over other networks, so I'm also replying to him, not you.
Another user who doesn't read all the posts, but only some...

Did you join the discussion later, did you think you were the only one I was replying to?
I remind you that I'm not bragging, I wouldn't gain anything, I'm just indicating how things go, because for me the default password changes absolutely nothing...
Physically the device must be taken out of the box and connected to the ethernet directly on ether1.
First run netinstall, installing at the same time branding OR autoconfig script, by holding reset without never use winbox or CLI
is faster than
running commands via another cable on one ethernet on bridge by CLI, and then wait for it to reboot for netinstall on ether1...

Ok, I re-read documentation and never knew they added a reset button straight to netinstall function, that didn't exist when I started using netinstall, so I learned something new, but it absolutely changes nothing because the whole problem, which you still utterly fail to comprehend, is that time=money, and netinstall ads lots of time and manual processes to a deployment scenario.

Our process almost fully automated such that no human ever logs into a router, scans a serial number, reads a label, or uses a keyboard or mouse or scanner of any kind. There is no user input interface they could even key in information from a keyboard or barcode. They don't put fingerprints all over the routers, they try to avoid touching them at all. All that is done is plugging in an ethernet cable into ether1 which supplies PoE and ether5 which the automated system logs into the router through to load the configuration files, in the room there are two visual indicators when the router is done as well as an audible one, the user simply moves the deployment ethernet cable from one router to the next, and roughly 15-20 minutes from when the case of 20 routers is opened up, all 20 routers are fully programmed and ready to give to end users, The cable in ether1 also allows our system to simulate that router going online and checking into our backend to confirm that it is successfully programmed. At that point all that's left is to close and label the box and print the shipping label to send the order off. Needing to netinstall those routers would change that from a 20 minute job or less into an hour or two maybe more, not to mention that the router probably has to be fully removed from packaging to be able to hold the reset button, which means they now need to wear gloves to avoid getting oily fingerprints on the quite nice looking soft touch black plastic cases, which show fingerprints very easily (and before you go off on a conspiracy theory about why we don't want fingerprints on the routers, dirty fingerprints all over on a product you are selling simply looks bad & unprofessional when a customer unboxes something already covered in visible fingerprints)

As for the concern about ensuring the config is clean, our branding packages includes our custom autoconfig script and performs a fully clean setup when ran. Our install process above also includes performing a factory reset on the router once the branding package is loaded. Once the router is deployed in the field if a reset is necessary, if a user uses the reset button, or it can be remotely reset from our customer portal, it reloads our config not the factory defaults.

rextended · Wed Apr 26, 2023 10:22 pm

Just as you assumed you knew everything about netinstall, and you were wrong,
you also shouldn't assume that everyone else is wimpy and messing things up...

[ And I wouldn't be surprised if you find something I wrote in the autoconfiguration code you use...

]

You are not a know-it-all and the perfection of how things on earth should be done...
I only stick to things that can actually be done without giving a damn about the default password.
Nothing more, nothing less.

P.S.: I don't mind, don't worry, it's not a personal matter, everything's fine.

Thu Apr 27, 2023 4:29 am

never knew they added a reset button straight to netinstall function, that didn't exist when I started using netinstall

I traced it back as far as February 2020, in RouterOS 6.

rextended · Thu Apr 27, 2023 4:58 am

RouterBOARD RB133C3 on 2007 with RouterOS 2.x already have that function........

millenium7 · Thu Apr 27, 2023 5:06 am

I only stick to things that can actually be done without giving a damn about the default password.
Nothing more, nothing less.

Ahhhh now it's starting to make sense. So if you encounter a situation like a radio/router/switch being factory reset on top of a tower, you just walk away and don't do anything about it.
Here I am stupidly trying to solve problems as they are presented and come up with practical solutions, how silly of me. No wonder none of this makes any sense to you

Here I was thinking it would be practical and sensible to make this a 5 minute fix where I simply log in through any of the transit paths, backup 4G service or laptop of whoever is onsite on the ground and log in via mac-telnet, you know the way its been done up until now....
Since that is no longer viable and requires a site visit to climb the tower and read stickers or push buttons. The right solution is to just give up on the job and walk away. Put absolutely no effort into actually fixing the problem because then I would have to acknowledge it as a real world problem, gotcha. I'm so glad you've been a part of this thread, its really closed my world right up

Thu Apr 27, 2023 8:17 am

Just to make things short:

It should work as "packing transport seal" which proves that noone tinkered with it during transport but noone cares about that seal after "grand unpacking".
There should be default password for the fresh new device and you HAVE TO CHANGE IT after the very first run. Then, resetting should behave like it goes now ... empty password + the need to set it.

Thu Apr 27, 2023 8:24 am

Just wanted to add, that yes, you can launch Netinstall just by pushing it's button, no need to log in. Also Flashfig is even easier - it is on by default when you first (!) boot your device. For devices with a beeper, this is indicated by a chirping sound. It means you can Fllashfig a device in seconds, just power it on

rextended · Thu Apr 27, 2023 10:32 am

Ahhhh now it's starting to make sense. So if you encounter a situation like a radio/router/switch being factory reset on top of a tower, [...] my world right up

I didn't think anyone could ever come up with all this bulls–t in one post.
Never written anything like this, you made it all up.
My posts are always there, and nowhere does it say what you invent.

But it does not matter. As the other user didn't know about netinstall at startup, you are also ignorant of the facts.
To me if YOU work badly or well, I don't give a damn, so do as you like, you don't listen to reasons and you make things up just to come up with ridiculous comments.

@all
Anyway, thanks to everyone in this post for fervently expressing their beliefs without being rude.
If you need a hand or some ideas, I'm always here.

rextended · Thu Apr 27, 2023 10:36 am

Author: normis

[…] no need to log in […]

Let's hope they believe you... It's from the beginning of the topic that I've been saying that the speed of installation doesn't change for those who distribute.
Obvious if one has a bad start from the beginning who has gotten into the habit of having to run winbox, ssh or api, (or ftp) to start netinstall, branding or whatever....

Znevna · Thu Apr 27, 2023 11:24 am

There's always the alternative in which you let the users configure their own routers.
Or provision them at actual install time, avoids having piles of hardware configured to maybe something obsolete that needs redone anyway.
But hey, you're the boss.

rextended · Thu Apr 27, 2023 11:54 am

Effective as always in the synthesis, Bravo!...

Buckeye · Thu Apr 27, 2023 11:09 pm

Just wanted to add, that yes, you can launch Netinstall just by pushing it's button, no need to log in. Also Flashfig is even easier - it is on by default when you first (!) boot your device. For devices with a beeper, this is indicated by a chirping sound. It means you can Fllashfig a device in seconds, just power it on

@normis

This topic would be a good subject for a Mikro Tip video. You made some on notes, branding, and skins and there were some on Netinstall, but not on how it could be used for mass deployments.

Edit: 2023-05-02 Done: See Mass-config MikroTik with flashfig (oddly, Druvis shows using "system/routerboard/settings/set boot-device=flash-boot", perhaps because that leaves the router in a permanent "flashfig ready" state, and will probably generate fewer "support calls" from users that don't bother reading the documentation. End Edit 2023-05-02

The biggest issue I see with Flashfig is that it is evidently one shot (for good reasons), but it also seems that it is there to modify the config, but not the default config for future resets. And if someone powers on the device without the it isn't 100% clear to me what happens; it seems that it disables the flash-boot Bootloader setting, if I understand the "flowchart" in https://wiki.mikrotik.com/wiki/Manual:Flashfig (which by the way is much easier to read than the one in https://help.mikrotik.com/docs/display/ROS/Flashfig)

A Mikro TIp with a demo of using flashfig with one of the new "random password" routers, along with what to when that doesn't work (there is no longer any audio feedback in many routers that have no beeper, or console) by using netinstall would help quench this thread. In your MikroTik branding packages video you said "and to completly remove all configuration, you would have to do a reinstall, which for normal users is more difficult I guess, they can find the reset button on the device, but to learn to use netinstall, they would have to dig deeper somewhere."

Also, the docs say this:

"If RouterOS reset-configuration command is used later, Flashfig configuration is not loaded, but the RouterOS default configuration. (To permanently overwrite factory default configuration, use Netinstall process not FlashFig). Therefore using Flashfig is normally a one time process."

rextended · Fri Apr 28, 2023 1:46 am

but it also seems that it is there to modify the config, but not the default config for future resets.

False, with flashfig, for example, you can blank admin password and proceed as usual for who have prepared some complex for first setup,
or why not send instruction from flashfig to load directly the branding package with default config wanted, and reboot..... and is permanent, also after full reset (except netinstall)

Buckeye · Fri Apr 28, 2023 2:29 am

False, with flashfig, for example, you can blank admin password and proceed as usual for who have prepared some complex for first setup,
or why not send instruction from flashfig to load directly the branding package with default config wanted, and reboot..... and is permanent, also after full reset (except netinstall)

So I took this too litterally "If RouterOS reset-configuration command is used later, Flashfig configuration is not loaded, but the RouterOS default configuration. (To permanently overwrite factory default configuration, use Netinstall process not FlashFig)." Where you just saw it as an opportunity for a second stage.

Amm0 · Fri Apr 28, 2023 5:05 am

the main issue is make the password readable!
Stop using characters like O/0/I/l/1/8/B as trying to decipher what they are gets really old really fast after repeated failed attempts on every device.

It actually this problem that is rather annoying in this thread IMO.

Fri Apr 28, 2023 9:12 am

We did also notice the issue with ambiguous characters and bad font. We will find a solution ASAP.
One option is to switch to all caps letters only, another is to avoid O/0/I/l/1/8/B. In any case, we are workinng on it.

Larsa · Fri Apr 28, 2023 9:42 am

Looks promising. Capital letters AND without ambiguous chars would be a great combination I would say.

Znevna · Fri Apr 28, 2023 10:42 am

We did also notice the issue with ambiguous characters and bad font. We will find a solution ASAP.
One option is to switch to all caps letters only, another is to avoid O/0/I/l/1/8/B. In any case, we are workinng on it.

Bitwarden, which is open source, in its password generator, has an option to avoid ambiguous characters, maybe you can use that function as a starter.

rextended · Fri Apr 28, 2023 10:53 am

Why not use just 12 lowercase HEX characters? Are unambiguos and are 281.474.976.710.656 possible combinations....
0123456789abcdef

Just a random number from 0 to 281.474.976.710.656 converted to HEX.....

Larsa · Fri Apr 28, 2023 11:56 am

Just curious but why do you prefer lower case? Otherwise, I believe the rest of the suggestions were great options.

Fri Apr 28, 2023 12:03 pm

when using HEX, somebody will still enter "O" because they will not know it's hex

Larsa · Fri Apr 28, 2023 12:26 pm

But of course, better get rid of all possible ambiguous chars as you told.

rextended · Fri Apr 28, 2023 12:45 pm

Just curious but why do you prefer lower case? Otherwise, I believe the rest of the suggestions were great options.

B / 8 or b / 8

rextended · Fri Apr 28, 2023 12:46 pm

when using HEX, somebody will still enter "O" because they will not know it's hex

Right...
Just choose a font with striked 0? Like 0123456789abcdef

Fri Apr 28, 2023 12:56 pm

Striked zero ... good old days ... never confusion about what that is.

rextended · Fri Apr 28, 2023 12:57 pm

That font is already used on MikroTik labels...

Fri Apr 28, 2023 1:00 pm

True but in upper case.
So that removes 1 ambiguity.

rextended · Fri Apr 28, 2023 1:07 pm

Better lowercase, but regardless the case, with big size....

hex_code.png

millenium7 · Sat Apr 29, 2023 1:21 am

We did also notice the issue with ambiguous characters and bad font. We will find a solution ASAP.
One option is to switch to all caps letters only, another is to avoid O/0/I/l/1/8/B. In any case, we are workinng on it.

Fantastic! that's a good start, and is 90% of why I originally created the thread. The next 10% is please include a barcode for the password, not just the serial number as that then involves multiple more processes to extract out the password (and tbh we have not received anything from distributors about default passwords). Please just simplify this process immensely and stick it straight on the box - optionally the product as well

Striked zero ... good old days ... never confusion about what that is.

Unless your password only contains an O and not a 0, then you dont have a reference to know if its striked or not and you're still questioning what it is. Makes so much more sense to just exclude ambiguous characters entirely

Buckeye · Sat Apr 29, 2023 1:50 am

What is the significance of the /204/r4 at the end of the serial number on the label? Is the 204 a date code and r4 a revision level?

bpwl · Sat Apr 29, 2023 2:00 am

Last edited by bpwl on Wed Apr 19, 2023 8:13 pm, edited 2 times in total.

rextended · Sat Apr 29, 2023 2:59 am

What is the significance of the /204/r4 at the end of the serial number on the label? Is the 204 a date code and r4 a revision level?

204 is the production batch
r4, yes is the revision number

BrianHiggins · Sat Apr 29, 2023 5:04 am

[ And I wouldn't be surprised if you find something I wrote in the autoconfiguration code you use... ]

considering that the initial version of the CPE autoconfig scripts was written in 2015, and based largely on an earlier autoconfig script I'd written in 2014, most certainly not. However one of the post installation change management scripts it installs, absolutely does. Your feedback helped solve an issue using the fetch output as an array.

I understand that you know a lot more about scripting than most people on here, but you also obviously don't understand this issue and how it stands to negatively impact people, or that simply because something can be achieved in more than way doesn't mean that all methods of doing so are equally good and fully interchangeable. I programmed and shipped 6 cases of routers today (that's 120 units) using the process & tools we built and been refining for several years now. These 120 routers we all checked and as necessary either upgraded or downgraded to v6.49.7, our branding package with skins, logos and autoconfig scripts were loaded / default configuration updated, and then they had a reset configuration ran. Then after the rest completed the config functionality was checked to verify they were properly configured and finally they were then repackaged, labeled, and boxed for shipping. The whole process for 120 routers took me just over 2.5 hours in total (100 hAP AC2, 40 hAP AC Lite). Overall the reboxing and labeling took as long as the configuration did.

How long would it take you to netinstall v6.49.7 and load a branding package on 120 routers and ensure they run the default configuration? I challenge you to time yourself doing just 10 routers and let us all know how fast you can get 10 routers done. I can program over 400 in normal workday, more if a 2nd person helps repackage label and box, what is the most you can do in a full workday? Answer these questions first and then we can discuss the merits of any proposal you want to offer. Just remember that for every single minute longer it takes your method to configure a router than what we've been doing, would have cost me 2.5 hours of time today. Simply adding 10 seconds per router would have cost me an extra 20 minutes today. With big orders it's extremely important to be efficient.

The new standalone Flashfig (as opposed to the one that was part of netinstall) sounds like it could be unreliable to implement at scale given that it only works on the initial boot since if that fails for any reason then your entire automation sequence is broken and then you halt the entire workflow, assuming it even works any better than the build previously contained as part of netinstall. I'm going to look into it but given that it probably also requires a wired PC running on the same switch to function it's still a bigger headache even if it does work. However given that it appears to only support loading a txt/rsc file, even if it does reliably run, it would only work as a tool to change the default password back to blank as we still need to verify/update the OS version and load the branding file. Ih it appears there's no way to do that via flashfig alone so at the very least it requires an additional step and tool running to get us to the same spot we are today, and that's assuming that the stand alone version even runs reliably (as already covered, previous tests on the netinstall integrated failed to ever work even once).

Amm0 · Sat Apr 29, 2023 6:37 am

The next 10% is please include a barcode for the password

Not quite a barcode. But I suspect if the font/size was better, OCR would likely work. I use the iPhone with IMEIs and ICCIDs and surprised how well it works to read them.

stick it straight on the box - optionally the product as well

I believe Normis said it will be on the Quick Start guide. That seems easier for an end-user save than the box.

millenium7 · Sat Apr 29, 2023 7:04 am

The next 10% is please include a barcode for the password
Not quite a barcode. But I suspect if the font/size was better, OCR would likely work. I use the iPhone with IMEIs and ICCIDs and surprised how well it works to read them.

stick it straight on the box - optionally the product as well
I believe Normis said it will be on the Quick Start guide. That seems easier for an end-user save than the box.

Anything else is far slower at scale. Forget OCR and all the associated issues (highly inaccurate for one), even just trying to scan a QR code takes far longer and has issues with being out of focus, too far away etc before it works. Barcodes typically 'just work' and are very fast which is why they are still used everywhere. At the end of the day all it needs to do is type out the read string via a simulated keyboard, thats how barcode scanners work. You can scan a dozen items (serial and password) in as many seconds
Having to piss fart about with a phone, different apps, integrating or moving data around etc, it largely defeats the purpose

I don't care too much where it is, but if its on the box then it doesn't even need to be opened. Much faster to scan in 100 routers by just using the outside of each box than having to open them up and rummage around and close them up again

Znevna · Sat Apr 29, 2023 9:09 am

[...]The whole process for 120 routers took me just over 2.5 hours in total (100 hAP AC2, 40 hAP AC Lite). Overall the reboxing and labeling took as long as the configuration did. [...]

You slap your Aditum label over MikroTik that fast? amazing.
Anyway, other countries are fighting to get rid of someone's force-provided ISP/whatever router and bring their own, and here you are doing the exact opposite. 'murica.
Good luck.

Sat Apr 29, 2023 9:40 am

Forget OCR and all the associated issues (highly inaccurate for one)

Ever heard of the Dunning-Kruger effect?

OCR has been used in critical real-time industry-scale applications for decades. For computer-printed text, it's a solved problem, to the extent that researchers have been focusing on handwriting recognition instead, the original problem from the 1980s considered too easy now. Provided the text is printed big enough, at high enough resolution, and you aren't working from a blurry scan/photo, accuracy is as close to 100% as any real-world system involving humans can hope to become.

I brought up the blurry photo issue above, but realize that I was doing so in the context of the current tiny, low-res printing. The bigger and sharper the letters, the less percentage error introduced by a given amount of hand jitter.

even just trying to scan a QR code takes far longer

It's essentially instantaneous, once the app is open.

I think you're trying to have it both ways. Yes, it takes time to open the QR code scanning app and get it to take its first picture, but then you go and misuse that fact to justify why scanning "at scale" will be too slow. At scale, you'll leave the camera app open all the time, and you're likely even to have it mounted on a tripod, pointed at the spot on the well-lit bench where hundreds of codes go by every hour.

has issues with being out of focus

Add light. Focus problem solved.

Oh, I know, I know. You'll next come up with some story about one lone tower guy trying to take a picture at arm's length inside a bat cave at night under a new moon and gleefully point out how the picture came out blurry. Thing is, that isn't "at scale." This wee fictional vignette is literally a one-off anecdote.

If you're going to crank these out at scale, such as with the mass-deployment CPE case, you'll put the camera on a tripod, add a light, control for reflections, etc., same as professional photographers have been doing since forever. You don't need to reinvent the world here, merely take some advice from people who know what they're doing.

Barcodes typically 'just work' and are very fast which is why they are still used everywhere.

All true. Problem is, linear barcodes are space-inefficient, which matters here since we're already talking about running out of space on the device labels.

(And yes, I'm aware of the plans for bigger carton labels and inserts, but you've also made a lot of noise about the on-device labels, so here we go.)

If you scroll up-thread and look at the photo of an actual hEX label in the current scheme, you find a linear numeric barcode that appears to be in UPC format. The barcode itself is maybe 20% wider than the actual numbers it encodes, but a lot taller to account for jitter in hand-scanning.

If you then switch to something like Code-128 to allow for full alphanumerics, the problem gets much worse because you need a wider encoding. The barcode ends up needing to be about three times as wide and high as the text it replaces. (The prior link gives a good example of this.) TANSTAAFL.

Space efficiency is one of the big problems that matrix codes (a.k.a. 2D barcodes) solve.

You can scan a dozen items (serial and password) in as many seconds

Given enough CPU power, scanning rate is the same for all barcode types, plus OCR: approximately 1/30 of a second, a typical frame rate for a modern video camera under indoor lighting.

The CPU power problem is a solved one in a world where everyone's got a supercomputer in their pocket.

Having to piss fart about with a phone, different apps, integrating or moving data around etc, it largely defeats the purpose

Everyone's got multiple barcode scanners to cover the disparate symbologies involved and didn't spend any time to integrate those into their systems?

Someone's going to have to write some software regardless.

Amm0 · Sat Apr 29, 2023 4:18 pm

Yeah I wasn't trying to get into a debate about value of barcode type. But they do have some barcode on the units, that could be used to lookup the password (or other things) in the CSV file available to distributors.

But I'm with OP that 90% of the problem is the font/size and confusing letters. The last 10%, I'm more on Tangent's side here...

After one accepts the regulatory requirement to do something

... I think it lost that from Mikroitk POV, there are two cases that come into play ):

(1) home users where they plug in a WAN into ether1, and want to connect to the Wi-Fi using default password. QR make perfect sense here, since there is a spec for Wi-Fi passwords in QR that phone will use. And router sticker and quick start seem a good place for it.

(2) ISP/etc need bulk provision where is router password is more critical. Here I'm not sure what's wrong with the barcode they already used to do a lookup? Someone want to use a handheld bar scanner read the password into winbox or custom script, that seem a little odd...

Re OCR... Perhaps suggestion to Mikrotik's testing department ... If iOS (and guess Android does same) can read the numbers in the Photo app, the font is big/readable enough

BrianHiggins · Sun Apr 30, 2023 12:25 am

[...]The whole process for 120 routers took me just over 2.5 hours in total (100 hAP AC2, 40 hAP AC Lite). Overall the reboxing and labeling took as long as the configuration did. [...]
You slap your Aditum label over MikroTik that fast? amazing.
Anyway, other countries are fighting to get rid of someone's force-provided ISP/whatever router and bring their own, and here you are doing the exact opposite. 'murica.
Good luck.

Yes, with the current default password scheme our average time to program a case of 20 hAP AC2 routers works out to a touch over 1 minute per router since we have everything running in parallel. We *can* do it closer to 15 minutes for a case, but that takes two people as there's too much time spent opening boxes and reboxing for one person to get it done that quick. 99% of the time it's just one person doing orders as there's usually in inverse correlation between size of the order and the speed the customer is expecting it, so most of the time we don't need to double up people for rush jobs. Also that speed per device does not apply to hAP AC3 routers as they have more intricate packaging and a warning sticker over ether1, and they come 10 to a case, but the time per case is roughly the same (i.e. it takes twice as long to program them as it does the AC2). hAP AC Lite routers, which we don't sell that many of anymore, take about 90 seconds per device averaged over 20 routers because they simply take longer to install the OS and perform their configuration. You can see why any change in the process that slows down the process is extremely unwelcome.

As for the labels, we don't actually affix any labels to the routers themselves, we only label and seal the box. To open the box you have to break the label seal. Our customers generally want to white label our service to the end users so labels on the hardware goes counter to that. I've considered with letting the customer provide labels that we'd install, which would obviously increase time some, but so far that hasn't been implemented.

One point of potential differentiation here, our routers remain fully defaulted (our default) on their config until they are in the end user location, and once powered on the routers then connect into our backend and await programming instructions. Within 30 seconds of being assigned to a subscriber, assuming itt's already booted up, it downloads all the necessary config for that subscriber account including wifi config and completes its configuration then reports back its status and various configuration variables for verification, and then our system emails the end user a welcome email template about their new service being online and their wifi credentials, so there's no customer specific data that is part of the setup process or the autoconfig scripts, and no customer specific configuration applied during setup.

That may sound like TR-069 (and it might have been easier to develop if it was), but we've been doing this since before TR-069 was supported by MikroTik, including pushing OS updates and tracking update status, so we built our own C&C system purely using scripting and web services to accomplish all of that, so it would require a lot of time and cost to test and implement a TR-069 implementation, and it really wouldn't be able to directly replace everything we're doing with the current system either.

millenium7 · Sun Apr 30, 2023 6:56 am

OCR has been used in critical real-time industry-scale applications for decades. For computer-printed text, it's a solved problem, to the extent that researchers have been focusing on handwriting recognition instead, the original problem from the 1980s considered too easy now. Provided the text is printed big enough, at high enough resolution, and you aren't working from a blurry scan/photo, accuracy is as close to 100% as any real-world system involving humans can hope to become.

Have you ever actually used OCR? Or are you just quoting from a sales brochure?
Simply googling 'typical OCR accuracy' shows its roughly 90-98% accurate, and in my experience thats exactly the ballpark. Anymore more than that is a tightly controlled environment - everything scanned very clearly with precise dimensions, very clear fonts etc. Not even remotely close to the real world implication of taking a photo with your phone. No OCR application out there is even remotely close to what you're proclaiming, and they still have the exact same problems this thread is based on - getting confused with ambiguous characters 8/B/I/l/1/0/O

More importantly, you're massively overcomplicating this for no tangible benefit that I can work out. What do you propose is your pitch for going with an OCR approach over a simple regular barcode?
A barcode is very easy on both sides of the fence, this is not rocket science to implement for MikroTik. About the only argument is space, in which case stick it on the box. I'm yet to see a MikroTik box that doesn't have gobs of unused space to stick one, or inside the box if for some reason they would have to rework their entire production line at great cost and complexity (doubtful)

A barcode - unlike OCR or QR - is simple, clean, accurate, effective and cheap. It doesn't require piss farting about with building systems, integrating apps, dealing with blurry photos, crap camera's, building a light studio and all this other nonsense. You just scan it and you're done, it works from single use with a barcode scanner directly into Winbox right up to large scale rapid deployments, with zero extra software having to be built. You don't need fancy software or setting up for a photo shoot, you can give a junior a $20 USB barcode scanner off ebay, ask him to fire up excel and pull the trigger twice per box - once for the serial, once for the default password. Juniors logged 100 routers in as many seconds, job done
Or you can go as fancy as you want with complicated software integration, barcodes still work perfectly there. The point is it 'just works' at the most basic simple level and up, OCR and QR does not and simultaneously provides no tangible benefit that I can work out

Cha0s · Sun Apr 30, 2023 1:37 pm

I wonder how for example TP-Link gets away with using admin/admin and (actually) forcing users to change it on first login and MikroTik cannot...

BrianHiggins · Sun Apr 30, 2023 9:33 pm

A barcode - unlike OCR or QR - is simple, clean, accurate, effective and cheap.

They also generally continue to work much better when the label is partially worn or damaged. There's a reason that the barcode is still universal standard at retail and grocery stores for all UPC codes, the scanners to read them are very reliable and work even when packages are worn or lightly damaged.

One point not addressed, Personally I would vastly prefer if they do print the default password somewhere (print and barcode format ideally), it would be on a loose sticker left inside the box, not actually attached to anything (exactly the way an extra serial number label used to be included inside the box). If someone wants to attach the default password sticker to the device they can easily do so with the included sticker, if like me they don't (because we're changing them, and don't want a password sticker on the device that will never be applicable again), we can toss the sticker in the trash as we run through our provisioning process. The factory workflow to do already exists since for years a spare serial number sticker was included inside each box, if they just printed the default password info on that sticker (but NOT the one that is stuck to the hardware), then you aren't causing confusion for the end users when they get a router that was bulk deployed, but still compliant with your interpretation of the rules (though I think a standard default password that must be changed at 1st login would still be a better option, edit to add change password at first login rule should only apply to winbox and webfig, NOT via API or JSON)

rextended · Tue May 02, 2023 4:38 pm

https://www.youtube.com/watch?v=gticPeOdN54

Buckeye · Wed May 03, 2023 2:40 am

In Mass-config MikroTik with flashfig (what rextended linked above), Druvis shows using "system/routerboard/settings/set boot-device=flash-boot", perhaps because that leaves the router in a permanent "flashfig ready" state, and will probably generate fewer "support calls" from users that don't bother reading the documentation. I suppose the users that do read the docs can find the more secure "system/routerboard/settings/set boot-device=flash-boot-once-then-nand" which automatically goes back to boot=device=nand after the first boot.

I am not sure how big of a real risk it is in practice. But since the latest TP-Link Mirai problems with https://nvd.nist.gov/vuln/detail/CVE-2023-1389 were also limited to "AV:A" Attach Vector: Adjacent, and its been in the news for the last 8 days, it is at least worth thinking about. Mitigating factors: vulnerable only during boot and on "boot port". But remember that no buttons need to be pressed.

Does anyone have any comments on the advantages and disadvantages of system/routerboard/settings/set boot-device=flash-boot vs system/routerboard/settings/set boot-device=flash-boot-once-then-nand

rextended · Wed May 03, 2023 4:29 am

it doesn't matter, in the initial configuration script just put it to nand-only, as it should be done.

millenium7 · Wed May 03, 2023 5:04 am

I could be wrong but the other issue is the device will never boot back to RouterOS if its set to flash-boot (unsure if there's an integrated time-out?)
I can see this being a problem, especially if flashfig doesn't work. Your device is essentially soft-bricked and you'd need a console cable to set it back to NAND boot

I agree it should be recommended to set flash-boot-once-then-nand and mentioned that this will check first and if it doesn't receive a response it will boot up as normal. It's a much better practice

rextended · Wed May 03, 2023 11:18 am

The possible values on v7.7+ are:

NOTICE: If internally is present NAND or Flash disk, not matter, everytime is called NAND on RouterBOOT.
On RouterBOOT for flash is intended a fast way to configure the device, not to start from "flash" internal disk inside.

ethernet boot only from "boot" ethernet (usually ether1) [by bootp or netinstall] (etherboot), everytime, no timeout.

flash-boot at every boot search flashfig, everytime, timeout after 5 seconds, if not find flashfig try to boot by internal active partition. After successfully flashfig configuration OR first time successfully login, is changed to try-ethernet-once-then-nand

flash-boot-once-then-nand just this time search flashfig, timeout after 5 seconds, set immediately nand-if-fail-then-ethernet,
if not find flashfig try to boot by internal active partition. If flashfig fail, still nand-if-fail-then-ethernet

nand-if-fail-then-ethernet the default, if for some reason all partition fails (or if in the active partition is set on-fail-boot-by-ethernet, ignoring the other partitions) auto-reboot with try-ethernet-once-then-nand

nand-only boot exclusively from the internal partition marked as active (or next partition marked as failover if the active fail, etc.).

try-ethernet-once-then-nand try to boot from ethernet [bootp or netinstall] (etherboot), timeout after 10 seconds, set immediately nand-if-fail-then-ethernet, if not find bootp or netinstall try to boot by nand.

All timeouts are stopped if for some reason flashfig or bootp or netinstall reply to the device, regardless if is done later any useful configuration.

EDIT: added bold part on flash-boot

Wed May 03, 2023 1:34 pm

Hello, Druvis here... Currently boot-device=flash-boot actually only changes the boot device for a single boot only. I am not sure about the history of these settings here, we will look into it. Perhaps things need to be tidied up.

rextended · Wed May 03, 2023 1:39 pm

Hello, Druvis here... […]

Welcome

Your first post on the forum

Have a nice day

Wed May 03, 2023 2:25 pm

Okay, after a little investigation, the help page has been updated:

flash-boot - Flashfig mode on startup is enabled. This setting will revert to NAND after a successful configuration change OR once any user logs into the board.

https://help.mikrotik.com/docs/display/ ... D-Settings
https://help.mikrotik.com/docs/display/ ... outerBOARD

rextended · Wed May 03, 2023 2:35 pm

Thanks, I also update previous post for reference.

Buckeye · Wed May 03, 2023 8:03 pm

Okay, after a little investigation, the help page has been updated:

Thanks for fixing the docs. Incorrect documentation is worse than no documentation.

Thanks for making the Mikro Tip about FlashFig and all your other Mikro Tips as well.
(Edit: Just notice you posted a new one to address the issue of new devices coming with preconfigured passwords)
Default passwords: WHY?!

Hopefully we may see you around the forums as well, but I realize that forums can be a time sink.

Buckeye · Thu May 04, 2023 2:05 am

it doesn't matter, in the initial configuration script just put it to nand-only, as it should be done.

You have obviously thought this through.

I have never needed to deploy MikroTik routers, but it seems that router boot is pretty flexible in what it allows.

I did a google search for "MiktroTik FlashFig" and found an old article from 2016 Using Flashfig to bulk upgrade Routerboard devices

How much has changed in the last 7 years?

Thu May 04, 2023 4:48 am

I thought it was worth cross-posting my latest RouterOS article here because it includes a method for resetting the default password on one of the new routers using netinstall-cli. It's tested and working here. There are subtleties, but if you have a default configuration you want to apply anyway, you might as well add the single line at the end of the new configuration script file anyway.

Wed May 31, 2023 2:55 pm

2. Password will be on the device itself and also on a similar sticker on the quickguide paper inside the box (in later batches)

Just got multiple new cAP AX, AX3 and 1 RB5009.
In neither of those packages was the sticker on the quickguide paper.
To soon, perhaps ?
I'll make sure to take pictures for my own sanity ...

Fri Jun 02, 2023 1:55 pm

Moving on ...
just prepped one of those AX3 mentioned above with default passwd containing both 0 and O yet no strike through 0 (zero, that is).
Slightly noticeable but only with x3 zoom and the correct lighting.
S/N and MAC addresses DO show the striked zero (which is why I first thought on the password it was the letter O )
After the 3th attempt the light bulb in my head went on.

Funny ... NOT !
Clearly someone who is not used to entering passwords from a label who didn't think about avoiding that combo or making sure to use the CORRECT font everywhere.

Rox169 · Thu Jun 08, 2023 1:52 pm

Hi,

I would like to remove the password from my new AX3. Is this setup correct?

I will set ax3 to the basic settings and export file(backup). Then I will use the flashfig with the exported file?

Is it possible to make the AX3 to set the default config without the password from MT? I mean when you reset the devie it is asking you if you would like to keep the default pre-config?

Thank you

Amm0 · Fri Jun 23, 2023 5:50 am

I would like to remove the password from my new AX3. Is this setup correct?

Well, no.

Once you get into the router, you can change the password to whatever. Or likely better to create a new account with "full" rights in /users (or System>Users in webfig/winbox) and then disable the the default "admin" name as cheap security

The default password only comes back if you reset the router to defaults (using button or /system/reset-configuration) – that will also put back the default password. And, if you want to remove even that, you need to use netinstall, not webfig. See posts from @rextended above on that one...

bpwl · Wed Jul 19, 2023 7:56 pm

Last edited by bpwl on Wed Apr 19, 2023 8:13 pm, edited 2 times in total.

.

Amm0 · Wed Jul 19, 2023 8:01 pm

Perhaps a Netinstall container be quicker – LOL, oh wait, you need to device-[un]lock in person...

5 looks like S too... Only only have a handful of these, but that one got me.

I think it's noted above the distributors have them, so you can ask them for it as alternative to a factorial problem.

EDIT: Maybe 0ALIM 0AYQ3G zero-alfa-lima-india-mike-zero-alfa-yankee-queen-three-golf

Amm0 · Wed Jul 19, 2023 8:16 pm

Maybe telnet is disabled in the default configuration, somehow?

Wed Jul 19, 2023 8:18 pm

The fact it responds with invalid username or password, would indicate it does work.
No ?

Amm0 · Wed Jul 19, 2023 8:25 pm

The fact it responds with invalid username or password, would indicate it does work.
No ?

I was referring to /tool/mac-telnet which I want to say does prompt then try. But I see it's real telnet from photos... More WAG here.

And there are 10 digits AFAIK ... so even U = L I does not make sense.

Curious puzzle, but poor @bpwl

Wed Jul 19, 2023 8:32 pm

Curious puzzle, but poor @bpwl

Yeah, mission accomplished 2000% here. Super secure.
Nobody's able to get in.
Not even the owner. Surely that can not be the intention.

@bpwl: I would return it to distributor or request them the password via email based on MAC address.

Wed Jul 19, 2023 8:33 pm

EDIT: Maybe 0ALIM 0AYQ3G zero-alfa-lima-india-mike-zero-alfa-yankee-queen-three-golf

That 3th character is for me U (Uniform).
Zoom out and you will see. There is no separation between what you think might be L and I.
But if you're thinking that way, it could also be India Julliet. But still then, I think it's Uniform.

bpwl · Wed Jul 19, 2023 9:14 pm

Last edited by bpwl on Wed Apr 19, 2023 8:13 pm, edited 2 times in total.

Wed Jul 19, 2023 9:19 pm

Can your friend access using wifi ?
And then Teamviewer on Pc/Mac via 2nd cable or hotspot ?

Edit: stupid suggestion... you still need admin.

Edit2: don't know where you live but I have one spare on my desk in Antwerp area.
If it's urgent...

Amm0 · Wed Jul 19, 2023 9:33 pm

You cannot imagine how angry I am. This was a problem just waiting to happen.
[...]
Netinstall over VPN, without physical access to the device?
There is no local device that can run Docker Container.

I spend 30 minutes at the wrong time to figure of the S vs 5 – I was hoping it was that...

The netinstall over VPN seem like your best bet in shity sitution – at least while numerous/tedious to do all the config/plumbing, at least it's a series of steps (e.g. who knows a sticker could have gotten swapped so lookup may not help)... it least you be able to remove the password for good & have a recipe for next time...

Amm0 · Wed Jul 19, 2023 9:40 pm

Might want to have the on-site person do the unlock the container feature, assuming you get in. At least with ax3 that be option in future.

bpwl · Wed Jul 19, 2023 10:16 pm

Last edited by bpwl on Wed Apr 19, 2023 8:13 pm, edited 2 times in total.

Wed Jul 19, 2023 10:26 pm

@holvoetn : friend and hAP ax³ is in Brecht.

Brecht as in north of Antwerp ? That's 40km from where my spare is sitting (Kontich). If REALLY needed, you can collect it tomorrow (I'm not there but I can instruct the colleagues to fetch it from my desk).
Just let me know <username> AT gmail DOT com

Or Brecht, Germany ? That's a bit further away

(160km from where I live)

msatter · Wed Jul 19, 2023 10:30 pm

Thinking out of the box here. When the board is not matching the case then you have this problem. Did you check if the replied MAC is still as the one on the box, after a reset?

bpwl · Wed Jul 19, 2023 10:52 pm

Last edited by bpwl on Wed Apr 19, 2023 8:13 pm, edited 2 times in total.

Wed Jul 19, 2023 11:00 pm

Label matches I assume. Reported MAC addresses are in range of the used ether port. QR code on label is also the SN.

Be careful with that assumption.
I have recently taken 11 cAP AX devices in service and those MAC addresses are really close to each other.

bpwl · Wed Jul 19, 2023 11:21 pm

Last edited by bpwl on Wed Apr 19, 2023 8:13 pm, edited 2 times in total.

bpwl · Wed Jul 19, 2023 11:42 pm

Last edited by bpwl on Wed Apr 19, 2023 8:13 pm, edited 2 times in total.

Thu Jul 20, 2023 12:01 am

Reset to factory settings then.

Thu Jul 20, 2023 12:02 am

E01 = .....C2
W01= .....C8
Connected port is .....C4

That would be correct for port 3

Rox169 · Thu Jul 20, 2023 7:35 am

Hi,

how to do netinstall to get rid of default password?
1. I would like to keep the option when I reset the router it will ask me if I want to keep the default/basic configuration but without the default password. How to do this?
2. If the option 1 is not possible I set up the device to a some basic setup and do the netinstall and tick keep default config?

Thank you

Thu Jul 20, 2023 10:27 am

I want to keep the default/basic configuration but without the default password.

With the CLI version, it's the -r flag. That tells netinstall to erase the existing config and reapply the default config. Along with this, you upload a new RSC file with -s to define a new "full" capability user with whatever password you like. You can make this script delete the default one in the same step, but I just add a new one and then manually delete it once I get logged in with my new user.

I've documented my procedure here. I find it considerably simpler than the Windows GUI instructions.

If you must use the not-actually-easier GUI version, I'm not going to be much more help than the docs.

bpwl · Thu Jul 20, 2023 1:14 pm

Last edited by bpwl on Wed Apr 19, 2023 8:13 pm, edited 2 times in total.