One thing i used to love about MT devices, was how they had Mac-Telnet enabled on all interfaces, by default from the factory.

this made it very easy for a remote admin, with just a single Mikrotik on a network, to allow customers to have new MTs shipped directly to the customer and provide them with very simple instructions (just plug in power, and plug in to our network and the admin can do the rest (ie the real configuration, via mac-telnet).

As of about a year or 18 months ago, the default config that MT ships is one that has the router ready-to-go out the box as a more traditional "home/consumer router" with a WAN port, and the rest config'd as LAN ports. I totally understand why this is, and the market/consumer MT is going after.

However, i have many installs where we are using MT based POE power sources (ie hEX POE's) and it would be so nice if new, fresh out the box MTs at least had Mac-Telnet enabled on the WAN port. The scenario often is, a customer buys a MT Wifi (such as a hAP Lite or hAP AC) and then we need to remotely configure it. I would love to be able to tell the customer, just plug in ETH-1 into the wall jack, and we can do the rest (ETH-1 as we are also providing POE and thats the only POE-IN port on many MTs). However, the default config,

Short of manually resetting the config to default, and then shipping the MT to the customer, does any know of any work around or tricks that im missing to remotly access a Fresh out the box Mikrotik, from *another* mikroitk that is on the same Layer-2 network? (ie like you could do in the goodl ol' days, before the more recent default config that has Mac-Telnet off on port eth1)?

or maybe Mikrotik can consider RE-Enabling Mac-Telnet on ETH-1 for all new devices that ship (if security is the concern, maybe have a script that disables it 60s after a reboot, only if the default config is in use, this would give us enough time to Mac-Telnet in and do a quick "/sys reset-config no-defaults=yes" )

thanks!
EDIT #2: through discussions below, i think perhaps a better solution / compromise to this issue/request has presented itself:

maybe add a setting where if the physical reset button on the router is held for 15 or 20 seconds during power up, than the RB resets to /sys reset-config no-defaults=yes (ie longer than the standard 5s which resets to def. config) - this is something we as admins can easily communicate to the end user- (ie to end-user: order XYZ rb, when it arrives plug it in to our wall jack (it will power up), now hold physical button for 20s till lights flash/blink , then we (admin) will do the rest for you)
^^ (i actually think this might be the best solution / compromise for all , even if just enabled on lower end, AP type RBs)



EDIT: i usually end up hoping that i have another MT in wifi range of a newly added (fresh out box) MT so that i can connect to its default-config open WIFI and then run a quick "/sys reset-config no-defaults=yes" , so that i can do my actual initial config over ETH via mac-telnet

If you don't like the factory default config, you can supply your own from within 'netinstall', and whatever you gaveit will become the new default for the device from then on.

If you just want to make a couple minor changes to the factory default, export the factory default to an .rsc, and make whatever changes you want. Or start from scratch.

If you don't like the factory default config, you can supply your own from within 'netinstall', and whatever you gaveit will become the new default for the device from then on.

If you just want to make a couple minor changes to the factory default, export the factory default to an .rsc, and make whatever changes you want. Or start from scratch.

Tks for your reply,

But Of course I know this, I even allude to it in my post. But again that requires us to stock RBs (x various types) or order them in adavnce and then reship them to customers. What I'm looking for is the ability of the end-user or the customer to order any RB device they want, directly to their location, and then we would be able to remote configure it.

This is the most convenient and economical method for both the provider and the end-user.
( provider doesn't have to stock and preconfigure, or pre-order several devices * different models. // end user doesn't have to wait extra days or have to pay provider for device (or end user can do a quick easy amazon order, and upon arrival plug in one eth cable and be done ).

I don't have to describe how happy and satisfied "not tech end user customers" are when their wifi/router/internet configuration is as simple as order this, then plug-in one wire to the wall (mt passive poe provided) and we will do the rest remotely.

It's also important to note; this used to be the case/status quo for all of mikrotiks history, up until about a year or 2 ago with the change in Mac-server default configuration/fw block)

Without exaggeration, this (L2 config on by default) was a feature that caught my eye and brought me into mikrotik eight or more years ago

There are ways to do it by default and maintain security.

Don't you think that the need to keep not so proficient users safe from possible security breaches outweighs your need for commodity on device deployment?
On the other hand, the need to do a preliminary bench pre-configuration before deployment to the customer (a simple reset without default config via a "LAN" port would do) could actually help to verify the proper functioning of the device before deployment. You could see this step as quality assurance from your side.
Unless you deploy hundreds of devices a day each day, in which case you probably could agree on a customized factory configuration with MT for mutual benefit...

Don't you think that the need to keep not so proficient users safe from possible security breaches outweighs your need for commodity on device deployment?

Thanks for your comments and info on this topic,

Yes, I do totally agree with this point above, which i why i have no issue with any of the other default configuration nor the default FW rules (they are important). Im only trying to address something that used to be enabled by default on all routerboards (for nearly 7 years) - At the same time, ive said there are ways to allow this (L2 mac-telnet access, on the ETH same port as POE-IN) and still maintain strong factory default network security,

For example, a factory default config with a FW rule which only allows 1 x L2-mac-telnet new connection per 24h (or even since reboot) - (or something similar to this maybe in the /tool Mac-Server settings) - thus as soon as the customer powers up the device, we the admin can get in, while at the same time abuse or brute-forcing of the mac-server can be blocked/avoided (additionally, very few, if any large ISPs and/or consumer ISPs even pass L2 traffic to their customer/end user CPE , thus the ISP CPE also avoids abuse of Mac-Server for simple Plug-and-Play non tech users).

Or a better fix, maybe adding setting where if the physical reset button on the router is held for 15 or 20 seconds during power up, then the RB resets to /sys reset-config no-defaults=yes (ie longer than the standard 5s press which resets to def. config) - this is something we as admins can easily communicate to the end user- (ie order XYZ rb, when it arrives plug it in to wall jack (it will power up), now hold physical button for 20s till lights flash/blink)
^^ (i actually think this might be the best solution / compromise for all , even if only applied/enabled on lower end, AP type RBs)

Another possible solution- Mikrotik could change the physical eth port used as the default config "gateway / internet port" to a different ETH port, (ie one not used SOLELY for POE-IN)

On the other hand, the need to do a preliminary bench pre-configuration before deployment to the customer (a simple reset without default config via a "LAN" port would do) could actually help to verify the proper functioning of the device before deployment. You could see this step as quality assurance from your side.
Unless you deploy hundreds of devices a day each day, in which case you probably could agree on a customized factory configuration with MT for mutual benefit...

I personally feel this point is a bit of a stretch / non issue (after 100s to 1000s of RBs configured, rarely are there defects, but, true, they do happen). This also goes a bit further to my point. If there happens to be a hardware issue (which with def. L2 access to a new device, a good admin could test/diagnose the issue remotely just as well as at their office) than its on the end-user to initiate a return/replace with whom they purchased the RB (often amazon which is easy/fast for returns). With the admin having to do this (rare) return process (in the "bench pre-configuration before deployment") there are extra costs to the admin, as well as a delay to deployment which the end-user will often associate with a delay due to the admin.

Or a better fix, maybe adding setting where if the physical reset button on the router is held for 15 or 20 seconds during power up, then the RB resets to /sys reset-config no-defaults=yes (ie longer than the standard 5s press which resets to def. config) - this is something we as admins can easily communicate to the end user- (ie order XYZ rb, when it arrives plug it in to wall jack (it will power up), now hold physical button for 20s till lights flash/blink)

Now this I think would be the best solution to this issue. Maybe you should add it to the poll.

boy, do we still run into this issue constantly! im talking 5-10 times a month, or more! we have mikrotik everywhere, and this default-config "update/change" a few yrs ago, really is a problem. its the difference between having customers, or non-tech (less $ / hr) installers, do installs VS needing to send out a IT related tech to jobs or cusomters. (or having to painfully walk non tech people through the reset no-defaults=yes process).

There are so many times we are forced to order MT devices directly to a location or to a customer, and we very often use POE (either passive or af/at), and the fact that you have to use eth1 to power up the mt device (no problem), but that eth1 is blocking all traffic, makes initial configuration impossible (wo accessing the device then resetting it, so we can then access via layer2 mac-telnet or other).

I fully understand why eth1 has to be fire-walled by default, but this is still an issue, and one that needs a physical solution (best compromise so far, seems to be some type of special reset button length, like 10s or 15s that resets to no defaults).

just wanted to bump this, and say its still an issue for us. worse is when the devices get installed, and have to then be re-accessed for reset.

Ive been using MT since 2001 and we have over 1k of them deployed, so i am aware of all the elements/options here. (we need a default button hold length to reset to defaults , please!)
tks

(also good idea on adding this option to the poll, its has been done)

You can already hold reset button for ~10 seconds until user LED stops blinking. This will load CAP config, where interfaces are bridged and MAC access is allowed.

You can already hold reset button for ~10 seconds until user LED stops blinking. This will load CAP config, where interfaces are bridged and MAC access is allowed.

This is GREAT!!! and does address my issue/request!

I tried testing this on an extra hap AC Lite (works!), via directions below, and i think the directions should be re-written / improved.

according to: https://help.mikrotik.com/docs/display/UM/hAP+ac+lite

The reset button has three functions:
+ Hold this button during boot time until LED light starts flashing, release the button to reset RouterOS configuration (total 5 seconds).
+ Keep holding for 5 more seconds, LED turns solid, release now to turn on CAP mode. The device will now look for a CAPsMAN server (total 10 seconds).

"Hold this button during boot time until" should be changed:
in my experiences (not just this instance here), this part is ambiguous / confusing / source of problems:
This should be changed to:
1- Start holding down the reset button
2- THEN apply power to the routerboard,

3- watch the USR LED to match the function you are looking to achieve (for led=flashing OR led=solid OR (led=on,flashing THEN off)
(#3 is poorly worded, but is just an example)

Another improvement could be to have this 5s or 10s reset hold be valid even if the mikrotik is fully booted (similar to most other non mikrotik network/wirless hardware). I dont see a downside to allowing this even when rOS is fully booted (ie remove the requirement to hold reset button (with one hand) , then apply power (with a 2nd hand)
its not as if the button is easily pressed by accident.
Reguardless, im very happy that there is a solution to this! (i would like to see it improved though)
thanks!