It is many years ago that I first suggested that (together with dropping the combined package in v6)… I am very happy that it has finally been implemented.
(and a bit dismayed that some people see it as a bug)
It was (again) bad decision by MT to split wifiwave2 package into “AC” and “newer” packages … instead of splitting it into “16MB AC” and “all of them”. It was perfectly possible to install the pre-7.13 wifiwave2 package in Audience (even in parallel / on top of legacy wireless) and radios worked fine (and on hAP ac3 IIRC), so the need for split was only for 16MB flash devices.
Sometimes I get impression that MT decisions are “over thought” and “too conceptual” instead of being “engineering” decisions. Yes, “engineering” decisions are sometimes too partial, but they generally work very well … while “academic” (conceptual, …) decisions might look great but often lack practical usability.
100% CORRECT 100% …
Thanks!
I correct the description, it is misleading…
To add default fasttrak when updating from ANY v7 previous version, just paste this into the terminal
(barring arbitrary changes to the default configuration already made).
New devices netinstalled with beta4 and later, or restored with default configuration on beta4 and later, are already ready.
{
/ipv6 fire filter
remove [find where comment="defconf: fasttrack6"]
add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack6"
:local idone [find where comment="defconf: fasttrack6"]
:local idtwo [find where comment="defconf: accept established,related,untracked" and chain=forward]
:put $idone
:put $idtwo
move $idone destination=$idtwo
}
For full default firewall rules:
http://forum.mikrotik.com/t/buying-rb1100ahx4-dude-edition-questions-about-firewall/148996/25
I find this criticism unfair toward Mikrotik. It is neither “overthought” nor “over-conceptualized,” nor should it be viewed negatively in any way. If anything, the approach was not thought through thoroughly enough. Likewise, a “16MB AC” package plus “the rest” would also be a short-sighted solution (number of supported chipsets growing). Having 128MB of flash storage does not mean that space should be used wastefully. Why should I install 30MB of unnecessary wifi drivers when I only need the driver for a single chipset on my device? At some point, the “rest” package will become so large that users with 64MB partitions will run into storage issues.
*) dhcpv4-client - allow selecting to which routing tables add default route (additional fixes);
Please, please, the same for PPPoE and DHCPv6 Client!!!
That would be great for DUAL-ISP setups and regular changing IP´s / Prefixes as here in Germany 
I’m still looking for a “Check Gateway” option in /ip/dhcp-client as that’s ALSO needed for “DUAL-ISP” setups too. While script can solve… setting the basic check-gateway=ping should be an option in DHCP client, since using a script add fragility for something important like DHCP (i.e. one error in a DHCP script, or version breaks something in scripts, etc… then no WAN route). And, FWIW, even detect-internet wouldn’t save a bad script, since you do have a DHCP client already…so it’s rules ain’t not help here
If package installer was intelligent, then it could always cherry-pick only drivers required for a particular device. In which case there would be no need for multiple wifi-qcom driver packs. But if considering bloat: 30MB on 128MB flash device is as as severe as 4MB bloat on 16MB flash device. And currently almost that amount of flash space is wasted due to inclusion of drivers not needed on many of those devices. No, we’re not wasting 4MB, we’re wasting around 2MB … and we’re long way from wasting 30MB on 128MB flash devices. Additionally: if package files were not squashfs files but rather archives to be (intelligently) unpacked to an otherwise plain filesystem, then there would be no “multiple squashfs overhead”.
BTW, I can’t call current situation on Audience other than huge bloat: despites only having installed routeros and wifi-qcom-ac, more than 39MB of flash is used … while the very same package files can use only 16MB when installed on hAP ac2 (just barely, but nevertheless).
I expect @normis to intervene again to steer us at discussion about release-specific issues and I can understand that attitude. But OTOH MT really should be prepared to take some amount of negative comments about their own decissions which were a fail in a hindsight. 16MB flash decission was a huge flop. Avoiding making installer more intelligent is IMO a flop as well. If MT feels that we should be discussing in a separate topic, they are more than welcome to open it and then actively participate in it … and then for sure nobody will discuss that in this topic.
That’s… unfortunate. Is this being reintroduced elsewhere, or is it a “nobody uses it” thing? Where it was useful it was very useful…
That said;
Thank you - my muscle memory missed this!
What’s new in 7.18beta6 (2025-Feb-12 11:20):
*) bridge - improved stability when using MLAG with MSTP (introduced in v7.17);
*) cloud - added file-share feature (additional fixes);
*) file - improved handling of filesystems with many files (additional fixes);
*) ipsec - added hardware acceleration support for hEX refresh (additional fixes);
*) l3hw - added initial HW offloading for VXLAN on compatible switches (additional fixes);
*) lte - added at-chat support for EC21EU;
*) lte - added confirmation-code parameter for eSIM provisioning;
*) lte - added initial eSIM management support (additional fixes);
*) lte - fixed R11eL-EC200A-EU modem RAT mode selection (introduced in v7.18beta2);
*) ovpn - disable hardware accelerator for GCM on Alpine CPUs (introduced in v7.17);
*) routerboot - disable packet switching during etherboot for hEX refresh (“/system routerboard upgrade” required);
*) winbox - fixed usb power-reset bus selection for RB924iR-2nD-BT5&BG77 (introduced in v7.18beta2);
*) winbox - show LTE “CA Band” field only when CA info is available;
Well, the problem is that when you open a topic in another category you will usually not get replies from MikroTik employees, at least in the release topics that is much more probable.
When they want us to discuss hot issues outside the release topics, they should reply to them.
And of course you can submit a support ticket. Two weeks ago I submitted a support ticket about the issue in some (admittedly old model) devices where the backup booter has to be upgraded, and that can only be done in exactly RouterOS v7.6 not any later version.
But of course by now it is unpractical to downgrade all the way to v7.6. device-mode would not allow it, wireless package would cause trouble, etc. So I explained the situation and asked them to update the backup booter upgrade package to a recent RouterOS version.
Reply after two weeks: Please send us the supout.rif file from your device made right after it encounters the problem.
So that is not productive either.
Reported as SUP-179200, and said to be fixed in 7.18beta6.
I am testing…
I have received the same reply when I’ve asked to update the docs. Seems, that they don’t always read the question.
Maybe they have a script that adds this standard reply to every ticket that has been open for some time and does not have a supout.rif attached??
No, they replied next day. But they definitely have some text templates to reduce the time for writing similar replies.
Most support departments do.
I was checking out the following feature:
*) dhcpv4-client - allow selecting to which routing tables add default route;
It’s really nice that you have added this. A really nice addition to make multi-WAN setups simpler!
However I found a few issues and also I would like to make a suggestion.
About the testing setup: I used a hAp ax2 device with beta6, and another Mikrotik device as the server. I connected the two using an eoip tunnel for testing purposes. I placed the interface I ran the client on into a VRF that I created for this purpose named"tst". I used Winbox 3.41 to configure the test device.
Here is what I noticed:
BUG 1: When adding a new dhcp client via Winbox, the default value for default-route-tables is “main”. This is definitely incorrect. It should either be empty (default-route-tables unset) or “default”. In fact, routes were incorrectly installed in the “main” table. This same problem in Webfig. CLI is correct; here default-route-tables=default is specified by default.
BUG 2: When “default” is specified for default-route-tables (through CLI), Winbox always displays “main”. Webfig displays “default” correctly. However both Winbox and Webfig always save “main” instead of “default”.
I specifically wanted to check out option 121, classless route. The default “yes” and “special classless” options work nicely as described in the documentation. However:
maybe BUG 3: Routes specified as via 0.0.0.0 are silently ignored by the Mikrotik client (not even a debug diagnostic is printed), however RFC 3442 specifies this as the correct action:
Local Subnet Routes
In some cases more than one IP subnet may be configured on a link.
In such cases, a host whose IP address is in one IP subnet in the
link could communicate directly with a host whose IP address is in a
different IP subnet on the same link. In cases where a client is
being assigned an IP address on an IP subnet on such a link, for each
IP subnet in the link other than the IP subnet on which the client
has been assigned the DHCP server MAY be configured to specify a
router IP address of 0.0.0.0.
I say that this is “maybe a bug”, is because I have never actually seen this option used. Nonetheless, Linux fully supports such a route, Mikrotik also does so, I don’t see why this should not work. (The only case I know about when this is used is by CPE devices that have local configuration web interfaces, etc.) I think that even if Mikrotik decides to ignore this part of the standard, that should be documented, and at least a debug level diagnostic emitted to the effect.
Now for what I actually came here to say.
SUGGESTION: While the add-default-route modes are really nice, I would really appreciate a mode “add only default” that would work like “yes”, but would only ever add a default route.
The rationale for this is a bit involved. It has been well known for ever that one possible attack on VPNs is injecting more accurate (longer) prefixes into the routing table via option 121. E.g. if someone has a site-to-site wg tunnel that directs everything 192.168.100.0/24 to other site, someone who can intercept the internet connection of this router can inject e.g. 192.168.100.0/25 and 192.168.100.128/25 routes into the routing table, thereby pulling all traffic out of the tunnel, or inject e.g. a 192.168.100.23/32 route to simulate e.g. an unencrypted SMTP server or syslog server on the other side, the communication to which would be assumed to be encrypted.
Although this type of attack was widely publicized for VPNs, the same can be performed for routed subnets, e.g. having a server- and a user-facing subnet, one of the server’s (again let’s say an unencrypted SMTP server’s) traffic can be fully exfiltrated - as long as we can provide emulation of the service externally.
Although this can easily be prevented in many ways (sorry, rextended, but as they say there is more than one way to skin a cat), e.g. using firewall rules, routing rules and tables (as wg-quick does it by default), or choosing not to auto add routes by the dhcp client but providing your own lease script.
However I gather from reading this forum that many beginners choose to use setups similar to this, and it would be a really really nice thing to be able to point to a simple drop-down option for preventing this sort of attack, and also incorporate it into tutorials easily.
To my knowledge no other vendor has such an option - but (contrary to what we read about botnets etc.) Mikrotik devices’ security is generally well regarded in the circles that I move around in. And being the first to include this feature would be really nice.
I use option121 in production networks extensivelly
a mask/prefix filter in the style of BGP filters would be interesting
No improvement for bgp that has been reported.
Hemmm