204 is the production batch
r4, yes is the revision number
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).
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.
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
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.
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.
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
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.
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
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…
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)
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
it doesn’t matter, in the initial configuration script just put it to nand-only, as it should be done.
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
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
rextended is right. Druvis uses correct setting, nothing will be stuck in forever flashfig mode.
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.
Welcome Your first post on the forum 
Have a nice day 
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/ROS/RouterBOARD#RouterBOARD-Settings
https://help.mikrotik.com/docs/display/ROS/Flashfig#Flashfig-RouterBOARD