Neither will I anymore, but new customers not experienced with MT devices and ROS (as I was when purchased my device) will not know about this trap.
That one I think its due to the pipeline: these devices started being designed some time ago. Then there is testing, certification, chain of supply, expected price, and on and on and on.
I agree that 16 MiB of flash is completely unfit for purpose - but in my opinion it’s where these last devices come from. We are at 2025 and RoS 7 - 128 MiB should be the bare minimum. Up until recently I was leaning towards 64 as minimum, but changed my mind: 128 it is.
at least 32MB would be “kind”
oh and on that occasion… static route BFD check would be nice … http://forum.mikrotik.com/t/v7-and-bfd-any-eta/158848/1
???
hAP ax2, clearly the successor of hAP ac2, has 128MB flash.
Of course it is more expensive and what is puzzling is that hAP ac2 is still sold and probably produced.
That is what I am saying: it may be still produced with this 16MB chips. No matter how many successors exist.
Option to push ISP subnet + custom ipv6 address into Cloud DDNS.
Access webfig through reverse proxy (relative paths for resources).
On Nginx there is a possibility to handle that by using rewrite or sub_filter rules. Probably other proxies have similar. But I agree, web resources should be loaded by relative path to avoid unnecessary complexity for such setups.
Another +1
Webfig can be run through a reverse proxy. On relative paths, webfig uses “AJAX-like” updates OUTSIDE of /webfig HTTP request path, i.e. just “/jsproxy” - which may be the root of the complaint. While that should be manageable in any reverse proxy, it takes a few rules (/webfig/, /webfig, /jsproxy, /assets/, /mikrotik_logo.png [new V7 webfig]) typically .
So whether the update URL should be under /webfig, i.e. “/webfig/jsproxy” may be a fair point. And, as usual, if docs included WHAT specifically should be proxied, or better docs on what URLs exposed by RouterOS more generically - that certainly be helpful rather than guessing.
Actually it appears I have misunderstood the "Input accept NLRI" filtering. MikroTik told me the entries in the address list have to be an exact match, so a 0.0.0.0/0 entry only matches the default route.
That makes the entire filter useless for me (I would have wanted to put something like 44.128.0.0/10 into the address list to allow all subnets existing in the 44.128.0.0/10 space) so I did not waste further time on this feature.
But you may want to test how it really works.
Display the access list comment in the log if the MAC address has been added to the access list. I’ve also often thought the access list should have a “Name” column so you can label entries.
Proposal to add terminal mode and auto-completion to MikroTik coding windows to improve user experience and facilitate development
This is a great feature and will remove rubbish schedulers. I know This can be avoided by writing a command line in last, but this will be better.
Big Feature: add else-if statement in RouterOS language
:if (<condition>) do={
<command>
} else-if (<condition>) do={
<command>
} else={
<command>
};
Pls guys, I want it :d
My wish:
*) pppoe-client - allow selecting to which routing tables add default route;
Exactly like it´s already possible in DHCPv(4&6)-Client:
Thanks
Mikrotik only supports ED25519 keys as ssh key, but not in /cetificate. I need to import an ED25519 key and a corresponding certificate to use as an openvpn client cert. Please consider supporting ED25519 keys and ED25519 siged certificates in /certificate. Thanks.
Please add more variables to the naming format used in CAPsMAN provisioning for the master and slave interfaces i.e. /interface/wifi/provisioning/add name-format= slave-name-format=
Examples to consider adding are the SSID, Configuration name, country code (2 character), Band, Channel, PHY ID, the local interface name used on the CAP
Thanks!
I believe all interface types should be under /interface. For example LoRa, Bluetooth etc... Make the menu and config structure more consistent in RouterOS.
MC