There are also many, not millions, other manufacturers of network devices, replies with an attitude like like this are IMHO a good way to push Mikrotik users to look into those alternatives.
Cannot say if it is a Mikrotik exclusive or a more general Latvian thing, but showing a minimum of respect for your users would be appreciated.
Otherwise make a new, catchy motto and logo for the company, possibly this one:
I absolutely love the attitude from MikroTik to their users. Their support is totally incomparable to companies (I dealt with) like Grandstream and Ubiquiti. Even on a user forum some staff members do respond!
Their strength is what, I think, you are running into. There are so many options and possibilities, not all users are compatible with MikroTik.
For me it works OK in beta5, I use only /export show-sensitive file= and it has exported OK every time.
(I always do an export immediately before and after each upgrade, and diff the two. I noticed the new items in routing rules, and this way I also noticed other bugs before. but this time it was OK)
I just done some tests in CHR and on RB750Gr3 and here are the observations:
Coming from 7.21.1, if routing rules are already present, then after the upgrade to 7.22beta6, they are placed at the correct position and /export or /routing rule export show the content of the table correctly.
Coming from 7.21 but with no routing rules, upgraded to 7.22beta1 -> 7.22beta3 -> 7.22.beta6, then add some routing rules, -> /export or /routing rule export don't have the routing rules at all, only /routing rule export verbose shows the content.
7.22beta6 (and 7.22beta5 too, because that was what I did multiple times yesterday) -> perform Reset Configuration -> then add some routing rules, -> /export or /routing rule export don't have the routing rules at all, only /routing rule export verbose shows the content.
Ok that explains it, I had the routing rules long before that (even in 6.x) and only noticed the strange new rules with *HEX identifiers. Not so good because normally I check for *HEX and consider it a problem.
I made custom PPP profiles for my usage, and left the default ones as-is.
Normally when *HEX values appear in my config it is because I deleted something and some other item got orphaned. So when they are there, I go look in the UI to see what it is and delete it.
In this case I knew it wasn’t something I deleted and I saw the changelog. However, I still looked in the winbox screen and what I saw there wasn’t good, and I noted that in the release topic.
Still cannot figure out how to reference an non-default network from YAML. I know you can use lan-bridge set by /app/setup, by a
networks:
default:
name: lan
external: true
or to exclude any networks section to use internal bridge (and dst-nat). Similar with pvid, which seems only available via /app/set, not YAML. Perhaps not implemented yet.
But... is there some YAML syntax for setting one of the networks in /app/network from the YAML (along with pvid)?
Even if another network is set "manually" via some /app/set myapp network=bridge2 (since unknown if possible to do in YAML)... This will cause the VETH automatically created for the /app to use dhcp=yes. So it assumes the connected network has DHCP. But in some cases you may want the VETH to use a static IP, and there does not seem to be to set the static IP for VETH. And there is no way to say "use existing VETH" that may be configured with dhcp=no, so you cannot just override it manually in VETH since it will get overriden when updated.
This comes up from me trying to an use an existing netinstall container I built and "package" it as a /appand eventually use it to test the new "mode script". But ran into the above two issues when trying to create a /app for it. The way the my netinstall container works is that it expects a seperate isolated bridge with just VETH and physical port to use, and imporantly a static IP on VETH since the netinstall-cli needs IP in range to use.
But same issue will come up if any /app wanted to be a DHCP server for a network (and likely other cases). Since it seems if you use some "bridging mode", the VETH for the DHCP server does need to be a static IP. And there certainly othre cases where /app may need static addressing.
Export is expected to be used to export and import configs, right?
If you are importing configs, is presumably that implicit configs already exists on router where it is been imported, right?
Why would you import implicit configs that already exists?
It is comparable to “display current-configuration include-default” in Huawei.
Should not be used to configure something, unless importing configs from another version. And only if the system have some special parsing-transforming between versions available as a feature.
From here, looks like you are using export where it should be using print.
Placing Mangle within the concept of ROUTING rules takes the flowspec further from reality.
Furthermore, being first in the implicit priority overloads the hardware offload concept, which has already been exhibiting unstable behavior in recent versions.
ROUTING rules should be focused on routing.
Mangle is focused on firewall, which by definition should come AFTER routing.
The thing is that from 7.22 those 5 "implicit" rules can be moved around by the users (the mangle rule can be moved below the vrf rule for example), as well as having other rules inserted in between them. This is the information that have to be included in the export and applied when importing. The import must be able to move the implicit rules to the positions specified in the export.
The default action=mangle routing rule with the id *FFFFFFF9 is where the packets with the routing-mark set are handled. It's not where the firewall mangle rules are executed!
Mangling in the firewall has happened way before that, at box #4 and box #19 of this flowchart. While the routing rule *FFFFFFF9 is part of the routing decision at #11 and #21 (routing rules are also consulted at #16, but at this point the packet has no routing mark yet, so *FFFFFFF9 will not apply there).
If the packet has no routing mark, then routing rule *FFFFFFF9 is skipped.
If it has routing mark (set previously by mangle action=mark-routing in the firewall prerouting or output chain), but no matching routing table, then it also proceeds to the next routing rule in the table.
If the routing mark has matching routing table, then the routing table is consulted:
If no route with matching the destination exists, it also proceeds to the next routing rule, because the action here is only lookup and not lookup-only-in-table.
If a matching route exists in the routing table matching the routing mark, then that route will be used, and the processing of the routing rules stops here.
You should understand that this is not a new decision. This is what always was happening in RouterOS 7. The implicit routing rules and their order is the reason why having mangle mark-routing rules in the firewall that match allows other routing table to be used, instead of the routes in the main table (because fallback routing rule *FFFFFFFD is below *FFFFFFF9). RouterOS 7.22 only makes those implicit default routing rules visible and allows you to reorder them / to place other rules in between them.
In previous versions without those default rules visible, Entries that you added in /routing rule are inserted between the default rule *FFFFFFFC and *FFFFFFFD.
There’s such amount of new features and fixes in new versions, so the support seems to be overwhelmed with tickets from people testing stuff here and there. It is nice to see the enormous amount of work done by the team, but to continue it’s probably worth to bring the support staff in line with what’s happening
I really appreciate this development trail 7.22 (actually Beta 6). I am using it in home environment on hAP ac^2 and it is really the best from 7.xx serie. It looks like the memory leak I have faced in all previous 7.xx versions in last 5 years is finally gone. I am little bit suspicious, the 7.22 is based on completely new kernel different from previous 7.xx branch. Even latency seems perceptible better.
What is only the visible issue for me now, is the new WPA2 PSK SHA2 switch. I am using home WiFi devices consisting of Apple products, Intel, Realtek and Mediatek. When authentication is the combination of WPA2 and WPA3 PSK, everything is fine. But in case of WPA2 PSK SHA2 is switched on (in addition to standard WPA2 and WPA3), Apple devices disassociate from network after while and never come back. What is more “nasty”, switching off WPA2 PSK SHA2 don’t help (probably some timeouts) and there is necessary to completely reset WiFi interfaces and set up again.
WPA2 PSK SHA2 is not documented properly - I have not find any detailed documentation, what it really do. TKIP is gone for years and AES is standard for WPA2, and I am curious, what nuances in the SHA2 switch is implemented.
But generally I am fine with this version in home production environment.
Ok but when you do not know what it is and what it is for, why have you enabled it? It is not like (especially with WiFi) every new checkmark has always to be ticked for even better function…
