Read our latest newsletter and learn more about:

- the most anticipated spring devices: cAP ax and the outdoor RB5009;
- upcoming Train the Trainer classes
- new regulations on default passwords
- your MikroTik setup submissions
- latest MikroTips videos
- wAP LTE kit & Aerones wind turbine care systems, and more!

https://mt.lv/news112

thanks

Hummm ... in specs for cAP ax (and comparison to cAP ac), shouldn't the row be titled "Tx Power (2.4 / 5 Ghz dBm)" rather than "Tx Gain" ? And it's capital "B" in (deci)Bell(miliwatts) ...

Looking forward to trying out the cAP ax.

no ipv6 fast-track? really?!

On default passwords:
I understand where it comes from (European legislation) but I do not get why the printing on the labels need to be so small.
Also I am not sure all the info which is on there now, needs to be there.
On some labels there is quite a bit of white space left which could have been made to use.
(I've already seen AC3, AX3, AX2, AX Lite)

Hi Holvoe, Newsletter 113 --> New Mikrotik magnifiying glass, POE not required, now you can read password tags with ease. ;-))

Clearly since Normis already wears magnifying glasses its understandable he doesnt get our pain!!! My apologies for aging forwards his avatar photo jajajajajajaja

Read our latest newsletter and learn more about:

- the most anticipated spring devices: cAP ax and the outdoor RB5009;
- upcoming Train the Trainer classes
- new regulations on default passwords
- your MikroTik setup submissions
- latest MikroTips videos
- wAP LTE kit & Aerones wind turbine care systems, and more!
- zerotrust cloudflare tunnel options package for all devices! <<<

https://mt.lv/news112

112_majaslapai.png

Am I dreaming ;-)))))

I would like some more details of this new default password feature. Is this procedurally generated, e.g. from serial number or MAC address? Or is this a serial <-> secure password table that each distributor gets? Please explain how a distributor is able to help you with a forgotten password and the security guarantees of such default passwords.

Doesn't matter how passwords are generated. For ISP routers it is the biggest BS ever. Imagine that you have to configure 20+ new routers for clients or technician connects new router to the network or resets configuration of existing router and admin has to configure it via MAC telnet form the neighbor device. Thank you EU or actually FU EU.

Doesn't matter how passwords are generated. For ISP routers it is the biggest BS ever. Imagine that you have to configure 20+ new routers for clients or technician connects new router to the network or resets configuration of existing router and admin has to configure it via MAC telnet form the neighbor device. Thank you EU or actually FU EU.

I'm going to have a similar issue. I have an automated script to provision new routers and this is going to cause some trouble.

The default password is not a problem, netinstall exist, and also on close future is available on the other local router.
Also the admin, if is really one admin, already can do remote netinstall when technician connects new router to the network.
And also, if is a true admin, already the device on configuration reset have the wanted default password, not the sticker one.
So, all these password issues are NOT there.
If you do, you probably don't know all the tools available to those who work with RouterOS devices, while the home user doesn't care.

Doesn't matter how passwords are generated.

It matters a lot. If the algorithm used is easily predicted, it would be worse to have the default password than none - since people wouldn't change, as it is "secure".

Now, I'm not saying that this is the case - but I AM saying that really matters how a password is generated.

On a lighter note, I think Mikrotik is setting the new minimal storage to 128MB. Finally we will be able to use partitioning on everything!

Looking forward to trying out the cAP ax.

me too but until it will fully implemented with capsman, I simply cannot

The only thing missing might be capsman forwarding, the rest should be there, no ?

Hummm ... in specs for cAP ax (and comparison to cAP ac), shouldn't the row be titled "Tx Power (2.4 / 5 Ghz dBm)" rather than "Tx Gain" ? And it's capital "B" in (deci)Bell(miliwatts) ...

Hummm ...
If you're going to correct, at least get it right:
GHz not Ghz
Bel not Bell

@sid5632

milliWatts or milli-Watts not milliwatts

Also you, the same:
only milliwatt is right.
For example, megawatt is also not spelled MegaWatt or Megawatt.
(obviously if it is the first word of the sentence is "Megawatt")

Last edited by sid5632 on 04 Apr 2023, 13:03, edited 1 time in total.

You prefer to fix your post?...
:lol: :lol: :lol:

Ok.. so... CCR2004 without USB port is a shame but quite understandable... guess there are not quite enough USB ports laying around...

... But what if you'd just upgrade CCR2004 instead of nerfing it - add M.2 or SATA port instead?

@rb9999
Making a RouterBOARD is not like going to the supermarket and shopping,
everything has to be engineered,
and adding components never prepared before, or not supported by the hardware in use,
means doing everything from scratch.
It's not enough to click on a flag...

When i buy a MikroTik product, usb and sd are the last thing i think about...
If I need disk space, x86, CHR or something like the 1100AHx2 Dude Edition...

Ok.. so... CCR2004 without USB port is a shame but quite understandable... guess there are not quite enough USB ports laying around...

... But what if you'd just upgrade CCR2004 instead of nerfing it - add M.2 or SATA port instead?

In this case they would already have PCBs ready to go - feature-set is set in stone by PCB layout. Also USB chips that they can utilize were set in stone as PCB layout only designed for particular size and pinout of the chip. If that particular type of chip is nowhere to be found, you ether scrap production or produce without USB.

And then: What do you do with the thousands of mainboards already produced, do you throw them away???...

On a lighter note, I think Mikrotik is setting the new minimal storage to 128MB. Finally we will be able to use partitioning on everything!

Maybe ... or maybe not. Audience has 128MB of storage, with intalled ROS 7.8 and wifiwave2 it has 79.7MB free ... upgrade needs to download around 27MB worth of packages. Which means 64MB partition is too small (I tried it somewhere around 7.3, it ran fine but couldn't upgrade). With "RAM disk available evrywhere" the problem might be solvable, but IIRC default download location is still on "storage root" which on these devices is flash/nand storage.

Doesn't matter how passwords are generated.

It matters a lot. If the algorithm used is easily predicted, it would be worse to have the default password than none - since people wouldn't change, as it is "secure".

Well, I think it be good to know if/where the generated password is persisted e.g. if provided to distributors/resellers and/or Mikrotik stores a copy etc... – if there in some database, even a strong algo wouldn't matter.

But in terms of workflow, if an end-user opens webfig/winbox, the default/generated password is still flagged as expired, so a password change is STILL suggested like before. While someone could click cancel, the same is true for no password. In other words, the "change password dialog" remains on first login.

Waiting for audience refresh please! Hope there is one in works.

Maybe ... or maybe not. Audience has 128MB of storage, with intalled ROS 7.8 and wifiwave2 it has 79.7MB free ... upgrade needs to download around 27MB worth of packages. Which means 64MB partition is too small (I tried it somewhere around 7.3, it ran fine but couldn't upgrade).

Isn't the upgrade downloaded to memory? Of course, You can manually download it and write on the flash. But when the user clicks the "upgrade" button it's downloaded to RAM, isn't it?

But in terms of workflow, if an end-user opens webfig/winbox, the default/generated password is still flagged as expired, so a password change is STILL suggested like before. While someone could click cancel, the same is true for no password. In other words, the "change password dialog" remains on first login.

So, it's the best of both worlds: the device isn't shipped blank, ready to be taken, AND it asks the user to use a new password. Looks quite good to me.

Isn't the upgrade downloaded to memory? Of course, You can manually download it and write on the flash. But when the user clicks the "upgrade" button it's downloaded to RAM, isn't it?

Only on 16 MB FLASH devices with more than 32 MB RAM (i.e. hEX Lite and iirc hEX as well, but not hAP Lite which has 32 MB RAM). All NAND devices download upgrades to root storage which is NAND.
You will notice which ones do when you have it, those devices have a flash/ directory which is permanent storage, whereas the root is a ramdisk that gets erased on reboots (updates are downloaded onto the ramdisk but somehow RouterOS knows how to perform upgrades from there.

Maybe ... or maybe not. Audience has 128MB of storage, with intalled ROS 7.8 and wifiwave2 it has 79.7MB free ... upgrade needs to download around 27MB worth of packages. Which means 64MB partition is too small (I tried it somewhere around 7.3, it ran fine but couldn't upgrade).

Isn't the upgrade downloaded to memory? Of course, You can manually download it and write on the flash. But when the user clicks the "upgrade" button it's downloaded to RAM, isn't it?

Dunno about most recent versions, but back when I tried, Audience didn't have RAM disk, so upgrade files were downloaded to flash storage. Which is roughly the same as manually storing them there. If running ROS consumes something like 48MB and upgrade npks are 27MB, this totals at 75MB which is (much) more than 64MB (partition size if 128MB flash is divided to two partitions).
When upgrade starts, those npks are unpacked to flash disk (part not accessible by users) replacing previously installed files so total flash consumption doesn't change much. And location of npks (flash versus RAM) doesn't matter.

As I wrote, I don't know if it's possible to place upgrade files anywhere else than in root of user-accessible file space. It doesn't seem like that, I couldn't figure out how to set location of upgrade files under /system/package/update.

RAM disk helps on devices with tiny flash and decent RAM (e.g. hAP ac2) where RAM disk is actually root of user-accessible file space and flash is mounted under /flash ...

BTW, I thing that unpacking of upgrade files is done before rebooting, reboot is simply an act to load newly installed ROS. Most probably shutdown/reboot procedure checks for npk files and if any are found, it tries to install them. But I don't know how exactly is the log about successfull or failed upgrade preserved over boot. I suspect it's written to flash storage and read back into logs after ROS boots.

Will the USB port still function if we solder one to the board ourselves?

This new password system is a major problem for us (in the US) and may drive us from using MikroTik products for our end-user home users as now we can no longer quickly provision them out of the box. This needs to be corrected/fixed ASAP. This is not a feature, this is a disaster. If this continues we will move elsewhere for end-users products.

This new password system is a major problem for us (in the US) and may drive us from using MikroTik products for our end-user home users as now we can no longer quickly provision them out of the box. This needs to be corrected/fixed ASAP. This is not a feature, this is a disaster. If this continues we will move elsewhere for end-users products.

Complain to the California goverment: https://specopssoft.com/blog/california ... sword-law/. You can expect this type of change from all vendors.

Oh come on, the worldwide "USB port-shortage" hits us :/

Mikrotik, oh Mikrotik,
Your CCR2004-16G-2S+ now ships without the USB port trick.
USB ports are scarce as they can be,
But that doesn't stop you, still a king in the industry.

The world may be without enough USB ports,
But your router is still top-notch of sorts.
Without the port, it does even more,
And its performance is smoother than before.

So let's celebrate, no USB port is just fine,
Mikrotik has shown us there's another way to shine.
For router enthusiasts, it's not a bad thing,
For the CCR2004-16G-2S+ remains the king of the networking ring!

Poem by ChatGPT :)

This new password system is a major problem for us (in the US) and may drive us from using MikroTik products for our end-user home users as now we can no longer quickly provision them out of the box. This needs to be corrected/fixed ASAP. This is not a feature, this is a disaster. If this continues we will move elsewhere for end-users products.

Complain to the California goverment: https://specopssoft.com/blog/california ... sword-law/. You can expect this type of change from all vendors.

Well California isn't exact the poster child for how to do things any more than the EU.

Only on 16 MB FLASH devices with more than 32 MB RAM (i.e. hEX Lite and iirc hEX as well, but not hAP Lite which has 32 MB RAM). All NAND devices download upgrades to root storage which is NAND.
You will notice which ones do when you have it, those devices have a flash/ directory which is permanent storage, whereas the root is a ramdisk that gets erased on reboots (updates are downloaded onto the ramdisk but somehow RouterOS knows how to perform upgrades from there.

I have some RB1100AHx2, but they are on 6.x series. They are partitioned, but there is nothing there but the OS. Upgrade was never a problem.

I always though that it was downloaded to RAM. Not much sense in using flash, since it works with the ones with 16MB storage. Well, this is easy for Mikrotik to change: just do it this way on everything with 64 (128??) MB of RAM or more.

BTW, I thing that unpacking of upgrade files is done before rebooting, reboot is simply an act to load newly installed ROS. Most probably shutdown/reboot procedure checks for npk files and if any are found, it tries to install them. But I don't know how exactly is the log about successfull or failed upgrade preserved over boot. I suspect it's written to flash storage and read back into logs after ROS boots.

The whole upgrade is done before rebooting. The reboot is just to load the new system. This is why I thought it would be stored on RAM. Why write to flash, if it will be read and open, just to write over?

The devices (device?) with 32MB of RAM couldn't do it - but even the ones with 64MB of RAM and 16MB of flash did it.

Will the USB port still function if we solder one to the board ourselves?

I don't think they have problems sourcing the small metal USB cage. It probably is the USB controller chip that can´t be found.

Will the USB port still function if we solder one to the board ourselves?

I don't think they have problems sourcing the small metal USB cage. It probably is the USB controller chip that can´t be found.

I guess print journalism is dead. But Jānis's MTU YouTube video explains the situation with AX2 and USB...
https://youtu.be/vAF7NII9Qcg?t=4878
TL;DW[atch]: AX chips are hot, USB adds 5W making it too hot

Also someone tried unsuccessfully to use the pads in AX2 to get USB from it: viewtopic.php?t=194488&hilit=ax2

Well California isn't exact the poster child for how to do things any more than the EU.

Woah...let's not blame California here – we're flexible:

The device contains a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time. -Cal.Civ.C §1798.91.04(b)

which has been law for a while and covered by prompt to change at first login. So I'm blaming Europeans ;)

Also UK has something similar, and basically everywhere the governments are working on ways to improve security:

https://techcrunch.com/2018/10/05/calif ... ccounter=1
https://www.bbc.com/news/technology-59400762
https://www.lexology.com/library/detail ... 09983ab184

You all may be smart and responsible professionals, but A LOT of home wireless AP never get configured and remain without passwords, leaving them open to malware from LAN side.

UK is a bad example.
They had to accept that legislation when they were still in EU :lol:

@everyone
Please stop being hypocrites.
Better security helps everyone.
Those who complain probably don't know how to organize or do their job.

As long as the RouterBOARDs arrive from the distributors without the protected-routerboot active,
THOSE WHO WORK WITH IT can use NetInstall without problems to first do the software update to a consistent version,
and then set a default password that allows provisioning as before...
But if you're doing NetInstall it can already be fed Branding and/or Configuration Script in one pass.

SPOILER: And then it will soon be possible to use RouterOS 7.10 to use NetInstall directly on RouterOS (and with Container it can already be done)

@normis perhaps a quick documentation page on how to do mass deployment of blank devices after this change comes in, would be helpful.

It is right that there is documentation, but in the meantime I just wrote it to you...

We will make a few videos about it

If Viktors is dressed up in a costume and looks like a USB key, I will watch it!!

If Viktors is dressed up in a costume and looks like a USB key, I will watch it!!

You have Zero Trust on videos :lol: :lol: :lol:

It is right that there is documentation, but in the meantime I just wrote it to you...

OK... so iit seems you can use Flashfig.... is it possible MikroTik could somehow take this one step further and allow Flashfig to work over a network with some kind of DHCP option? That would allow for zero touch install of devices across the network.

The outdoor 5009 has no information on input wattage per ethernet port. Is it only 25w input as well? Or full 130w input is possible?

My intention is to replace some Powerbox Pro's that have 60ghz radios hanging off then, as the powerbox is also setup as a router and it struggles. I don't want to run new DC cables, I just want to use the existing 60w power supplies using eth1 as input, same as a powerbox

If it can't, can the mikrotik Poe splitters be used in reverse? And then I connect the DC side to it

If it can't, can the mikrotik Poe splitters be used in reverse? And then I connect the DC side to it

According to docs, POE out on RB5009-power only works if source is 2-pin (maybe DC jack too). POE-in is for router only.

But yes, you could take an injector, cut the DC plug off, and feed the wires into the green two-wire connector. I've done that for other projects.

You might want to use something like a Tycon POE-INJ-1000-WT to split the power from the CAT5/6 (it supports 4-pair POE) and then use 18AWG wire from the injector to the RB5009's two-wire plug to avoid voltage drop and more easily support the higher current draw. It might fit inside the outdoor 5009's cable section (it fits inside NetPower 16).

Also UK has something similar, and basically everywhere the governments are working on ways to improve security:

https://techcrunch.com/2018/10/05/calif ... ccounter=1
https://www.bbc.com/news/technology-59400762
https://www.lexology.com/library/detail ... 09983ab184

You all may be smart and responsible professionals, but A LOT of home wireless AP never get configured and remain without passwords, leaving them open to malware from LAN side.

Normis, Like several others here, we do automated deployment of devices, the process is we plug in 20 routers at a time into our bench PoE switch on ether1, then we load up our in-house deployment tool, and plug in a 2nd cable into ether 2-4 (this is for hAP routers btw), the deployment tool tries every 15 seconds to connect to 192.168.88.1 with admin and a blank password, once connected it then checks the OS version, upgrading or downgrading as necessary from the factory software to have it running v6.49.7, then when that's complete it automatically loads the branding package dpk with the rest of our deployment config and reboots. After it's gone through all 20 routers, it then monitors and alerts the technician when they all are completed. After that they are boxed and labeled.

This onboarding process also automatically records the device serial number, MAC address, and installation date for later reference. We typically program and ship a case of 20 routers in a little over 30 minutes from start to finish if someone is quick about getting them unboxed and labeled / re-boxed. We don't even pull the routers fully out of the plastic bag to try to avoid getting fingerprints on the soft touch black plastic cases.

Commercial users like myself require an automatable process to onboard and program routers, Your biggest customers do NOT have time to read the stickers on the routers to log into them, we've invested a huge amount in MikroTik, and based on what our distributor tells me I'm one of the largest purchasers of various hAP models of router in North America. It would be tragic to throw it away because we can no longer onboard new devices.

The netinstall procedure would be fine if it was possible to initiate it without having to press any buttons on the device itself. Only then it could be automated.
Think of something like having user "netinstall" with fixed password "Run_it_now!" that can only login once after reboot, only using MAC-telnet and only if no other user have logged into device, during say first 5 minutes after reboot into default configuration. Authenticating as "netinstall" would instantly trigger reboot into netinstall mode and nothing else.
All these restrictions would limit any possible misuse, similar to mode-switch, requiring only local MAC access + time window after reboot + fresh default config only. Triggering it on configured device would be equal to having hardware access to it (unless you invent scenarios like hacking remote UPS or powerstrip control... but in that case you have other problems to worry about first).

The netinstall procedure would be fine if it was possible to initiate it without having to press any buttons on the device itself. Only then it could be automated.
Think of something like having user "netinstall" with fixed password "Run_it_now!" that can only login once after reboot, only using MAC-telnet and only if no other user have logged into device, during say first 5 minutes after reboot into default configuration. Authenticating as "netinstall" would instantly trigger reboot into netinstall mode and nothing else.
All these restrictions would limit any possible misuse, similar to mode-switch, requiring only local MAC access + time window after reboot + fresh default config only. Triggering it on configured device would be equal to having hardware access to it (unless you invent scenarios like hacking remote UPS or powerstrip control... but in that case you have other problems to worry about first).

IF there was a way to trigger it without logging in, that might be an option, however that would still be far slower process then we are using right now.

Our deployment tool (which uses the API to connect, is web based, and is being ran from a web browser of a smart TV mounted on the wall) does not need to go through the slow reformatting process every time, nor does it even load a new OS version if the device shipped from the factory with the correct OS version (which is about 50% of the time).

We don't have IT trained people programming these routers, they are only trained on plugging in a cat 5 cable, waiting for a beep, wait ~20 seconds watching the screen for instruction that it's time to move the cable to the next router, and then box and label the routers. I'm not against making changes to the process, but they must be ones that are automatable, they cannot rely on someone having to read the small label or anything like that

Edit to add, in theory this was what the flashfig tool was supposed to do, but I've never once see it actually work.

The idea of using the new RB5009 as a PPPoE termination is interresting. So t clarify, you use it as a termination and for example plug it to a 10G switch like the CRS13 ?

The idea of using the new RB5009 as a PPPoE termination is interresting. So t clarify, you use it as a termination and for example plug it to a 10G switch like the CRS13 ?

I would presume they are referring to the same type of deployments we started doing ~15 years ago with APs up on the tower running NStream and CPEs at each subscriber, at the bottom of the tower we had PoE injectors to power the APs connected to a switch and a x86 ROS deployment with 4 ethernet interfaces running as the PPPoE server and site router. Translate that same model 15 years forward and you would not need hardly any of that base equipment, you could use the new 5009 as the PoE switch and the PPPoE router in one, eliminating the need for the big weatherproof enclosure and simplifying power management, and overall costs at the same time. How you optimally configure the APs and CPEs I'm probably out of touch on, as I haven't done any WISP deployments in some time now, I'm only dealing with wired installations these days.

The idea of using the new RB5009 as a PPPoE termination is interresting. So t clarify, you use it as a termination and for example plug it to a 10G switch like the CRS13 ?

I would presume they are referring to the same type of deployments we started doing ~15 years ago with APs up on the tower running NStream and CPEs at each subscriber, at the bottom of the tower we had PoE injectors to power the APs connected to a switch and a x86 ROS deployment with 4 ethernet interfaces running as the PPPoE server and site router. Translate that same model 15 years forward and you would not need hardly any of that base equipment, you could use the new 5009 as the PoE switch and the PPPoE router in one, eliminating the need for the big weatherproof enclosure and simplifying power management, and overall costs at the same time. How you optimally configure the APs and CPEs I'm probably out of touch on, as I haven't done any WISP deployments in some time now, I'm only dealing with wired installations these days.

oh, that makes sense. That's very inspiring...

- new regulations on default passwords

An idea :-)

Why not using the MAC for the default password together with a simple brute force protection?
The MAC is printed on all devices, easy to implement and much more secure than the default password (not secure at all, but much better).

- new regulations on default passwords

An idea :-)

Why not using the MAC for the default password together with a simple brute force protection?
The MAC is printed on all devices, easy to implement and much more secure than the default password (not secure at all, but much better).

this is what is (was?) doing QNAP.

Hi,

Why is this announcement only in the announcements forum, and not in the announcements section of all forums?
Is it broken?

Why should it be?

It's not broken, not all articles in announcement part of forum are visible in other parts. They are visible in parts where they make any sense. E.g. announcements about SwitchOS are only visible in SWOS part of forum.

IMO newsletters are not important enough to make them visible everywhere.

I guess I rarely look at the announcements forum and had just assumed it would show up at the top of the other forums,
it doesn't really matter.

You can also opt to subscribe to the newsletter. Then you get a mail.

- new regulations on default passwords

An idea :-)

Why not using the MAC for the default password together with a simple brute force protection?
The MAC is printed on all devices, easy to implement and much more secure than the default password (not secure at all, but much better).

I believe I suggested more or less the same thing earlier in this thread (or might have been the dedicated password thread). They are unique, and they can only be discovered with physical or layer2 access to the device so should be undecipherable over the internet if someone left it unchanged. It's a great balance of compromise, and sadly that's also why I highly doubt it will be implemented this way.

Using the MAC address as password is a bad idea.

1) One can find out the maker of the router, just looking at the MAC Address (they are tight controlled, and every business receives a block of them to use).
2) Knowing this, it would be easy to create a worm/virus/exploit to infect the user's computer - and through them, the router.

A) No, no one would have to know your routerś brand: just infect a bunch of people and hope for the "best".
B) No, it wouldn't need to broadcast something on the network: it's the router. Sure it's MAC address would be on the arp cache.

For the same reason, it wouldn't work MAC + salt, since the user would need to know the salt, in order to type the password. And then we would be back to step 1.

Using the MAC address as password is a bad idea.

1) One can find out the maker of the router, just looking at the MAC Address (they are tight controlled, and every business receives a block of them to use).
2) Knowing this, it would be easy to create a worm/virus/exploit to infect the user's computer - and through them, the router.

A) No, no one would have to know your routerś brand: just infect a bunch of people and hope for the "best".
B) No, it wouldn't need to broadcast something on the network: it's the router. Sure it's MAC address would be on the arp cache.

For the same reason, it wouldn't work MAC + salt, since the user would need to know the salt, in order to type the password. And then we would be back to step 1.

1 & 2) We're only talking about default passwords when the devices are shipped, and no one is arguing against mandating them to be changed on 1st login, this is just about how they ship & do their first boot. In order to find out the MAC address of a device remotely you have to be connected to the same layer 2 network segment as that device, MAC addresses are not transmitted over the internet, therefore any informed compromise can only come from inside your network. Across the internet or even just on a different routed subnet the only hack would be brute force. Yes an already infected computer on the LAN could compromise a router moments after connecting it, but if you require the password to be changed at 1st login then you are only risking that a device can also be compromised by an already infected computer already connected to the same network the new device is, and only in the initial minutes after installing the new router before it's logged into and the password changed. I'll also remind you this is something that is already more than possible given the historically blank admin password and was never given much concern (opposed to the risk of attaching that router to the internet where it would likely be compromised in a short amount of time).

A) The 1st 6 characters of a MAC address are a vendor identifier, but companies like MikroTik have tons of different vendor MAC prefixes (currently 16 according to wireshark) which when combined with the 6 device specific characters essentially gives you a 7 digit unique password, or 16 sets of 6 character unique passwords (edit to add, since it's hex that works out to 16,777,216 possible combinations, and in theory each "password" could be reused 16 times as vendor IDs are incremented), depending on how you want to look at it. While I agree that 6 characters of a somewhat limited character set (it's hex) may not be the strongest password in the world to survive a brute forced password attack, it is more than strong enough to act as a default password that must be changed at first login, especially since that value would not be detectable or calculatable over the internet (aka not something random scanners would be able to detect)

B) I don't understand what point you're trying to make, but see 1&2 again.

B) I don't understand what point you're trying to make, but see 1&2 again.

The infected desktop wouldn't need to keep broadcasting something, in order to find out the Mikrotik router. As it's a router the MAC address would surely already be on the client's arp table.

Your point about just a few minutes window is reasonable, but doesn't mitigate much. Several studies point that an unpatched/unprotected machine can be compromised on a matter of minutes, if exposed to an hostile network. And we are talking about tens of thousands of routers here: if even just one in 500 falls for this, it would be still a sizeable botnet. Not to mention that, even forcing a password change, people would find a way to don't do it. We already saw something like this, on some posts on this very forum.

All the MAC digits are known, since they are on the arp table. As You said, Mikrotik has 16 blocks. That's the only part needed, in order to identify something as "made by Mikrotik". The rest is history - we can get the whole thing through the arp table, and don't have to mess with probabilities.