OK thanks… what do you think, will they get it right at some point…7.2x?
In the food industry, it probably wouldn’t work to simply bring a raw piece of meat onto the market with the intention of “frying it a little later, maybe”
Strange mic(k)rocosm
-faxxe
That’s not how the standard works, which is years-old, by the way. (Google for Channel Switch Announcement, 802.11h.)
The link-local address of WireGuard interfaces lost randomly
Below is the update log regarding the routing in this release:
*) route - added ability to redistribute isis routes;
*) route - fixed incorrectly handled route distinguisher and route targets (introduced in v7.15);
*) route - fixed memory leak (introduced in v7.15);
*) route - fixed some missing route parameters when printing (introduced in v7.15);
*) route - improved route attribute handling (may increase memory usage);
*) route - improved stability when getting entries from large routing tables;
*) route - place static route in the correct VRF when vrf-interface parameter is used;
*) route - rename route type from is-is to isis;
The routing-mark in IPv6 routing still does not work unless the following code is added in /routing/rule:
The code is as follows:
/routing rule
add action=lookup disabled=no routing-mark=main table=main
The reason for not wanting to add the code below is that it has been found that having or not having code in /routing/rule (which should bypass the /routing/rule functionality) makes a difference.
Tests have shown that enabling /routing/rule results in a performance drop of at least 5%-10% and also increases response latency.
Please check SUP-151768 for confirmed details of the issue.
Oh, did not know that there is a separate standard. Thanks for the information. Googled it, should be defined in IEEE 802.11-2012.
But when it really is this, I would want Mikrotik to include this reference in their changelog as well. So we all can lookup/google for more info.
What’s new in 7.16rc2 (2024-Aug-13 10:05):
*) 6to4 - improved system stability when initializing 6to4 interface (introduced in v7.16rc1);
*) bridge - added L2 MDB support for IGMP snooping (additional fixes);
*) console - improved large import file handling, error detection and stability (additional fixes);
*) dhcp - improved DHCP IPv4 and IPv6 client/relay/server underlying interface state change handling (additional fixes);
*) ovpn - improved system stability (additional fixes);
*) route - improved routing table update performance;
*) x86/chr - fixed invalid HDD size (introduced in v7.16beta7);
I bet here is nothing for igmp issue found on SUP-152693?
Support told me that this happened because the VM memory was still at 256MB (which was the result of deploying the VM with the 7.15.1 .ova file and then upgrading it to 7.16beta1).
So, whenever you have a CHR that was originally installed on an older version, FIRST upgrade the memory to 1GB before you attempt upgrade to this version.
(increased memory requirement is documented but belongs in the “Before an upgrade” section, where only storage space is mentioned and not RAM allocation)
It seems that SUP-161182 has not been fixed.
out of interest: support tickets are private only. why do so many people just drop a support ticket number while moaning: “meh, not fixed. boo boo”. We don’t know what’s reported and written in these tickets. what is the intention or goal?
The goal is to boo-boo. AFAIK the most optimistic feedback provided by support is “the issue was reproduced, it’ll be fixed but we can’t give any ETA”. Except when the fix was already done and has passed whatever internal check points, in which case they’ll say it’ll be included in next beta/RC.
After 7.16.X show
Aug/13/2024 16:46:36
memory
dhcp
error
pppoe-out1 took over pppoe-out1 handling (IPv6)
What does the following feature exactly mean?
*) wifi - added “slave-name-format”;
Will this solve the issue with CAPsMAN and qcom-ac devices when configuring vlans manually?
Currently on 7.15 they get named inconsistent after repro visioning the CAP’s and brake the vlan filtering configuration on the bridge when having slaves-static enabled.
(See http://forum.mikrotik.com/t/slaves-static-problem-with-capsman-vlan-and-qcom-ac/177862/1)
And are there any plans for vlan datapath support for qcom-ac?
hi guys is there anywhere i can download 7.16rc1? as i try rc2 and it has a bug i dont like wont to reveert backl to rc1 but i didnt download it i just upgraded from cloud
You can download basically any RouterOS version from our upgrade server. Just change the version number in URL.
https://upgrade.mikrotik.com/routeros/7.16rc1/routeros-7.16rc1-arm64.npk
7.16rc2 fixed the issue with the 6to4 tunnel crashing the Mikrotik when you disable / re-enable the tunnel. Thank you MT!
thanks so much appreciate it cheers
Some people seem to think this forum is a support system. No it’s not, people reading this are regular users. They have no use for your support ticket numbers.
robtor “wifi - added “slave-name-format”;” just adds more control on how virtual interfaces can be named.
Regarding the forum post you linked, a lot of issues can be caused by re-provision, there seems to be a misconception that configuration needs to be “pushed” via help of provisioning the interfaces. That is not the case, provision must be done only initially, and is done automatically upon CAP joining if there are matching provisioning rules that are enabled.
If you adjust any configuration profile that is linked to provisioned interface, all changes will be “pushed” as soon as you apply changes to the profile. With no need to re-create already existing interface.
Provisioning itself is not for sending configuration, it is for essentially creating a new interface. In most cases, there is no reason to perform manual provisioning once you already have CAP interfaces running.
Now, if create-enabled together with slave-static is used and interface names change after reboot or upgrade, please let us know via support@mikrotik.com along with details of what was upgraded/rebooted. In our tests, names should not change, and references to CAP interfaces should work, and not be lost, both on CAPsMAN and CAP side, even if virtual CAP interface is renamed on CAP.
I have experienced cases where the configuration changes where not pushed “automatically” and it needed to call “provision” again. I can’t remember the concrete cases though.