MikroTik

Posted: **Wed Oct 26, 2022 4:38 pm**

RouterOS version 7.7beta3 has been released "v7 testing" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 7.7beta3 (2022-Oct-26 11:31):

*) bgp - improved BGP advertisement printing;
*) bonding - properly detect VPLS interface state changes;
*) bridge - added support for static MDB entries;
*) bridge - disallow port-controller while the bridge has MSTP enabled;
*) bridge - fixed "edge=yes" setting for MSTP;
*) bridge - fixed incorrect root port blocking for MSTP;
*) bridge - fixed mst-override port priority for MSTP;
*) bridge - fixed MSTP compatibility with STP;
*) bridge - fixed port priority for STP and RSTP;
*) bridge - fixed RSTP BCP with bridged PPP interfaces;
*) bridge - fixed STP blocking state on port-controller;
*) bridge - improved port-controller system stability;
*) bridge - improved system stability when using MSTP and many VLAN mappings;
*) certificate - improved certificate management, signing and storing processes;
*) container - fixed handling of groups and usernames from Dockerfile;
*) dhcpv6-client - handle receiving of invalid T1 and T2 times;
*) discovery - added "discovered-by" parameter to indicate which protocol discovered the neighbor;
*) discovery - added "mode" parameter for discovery configuration;
*) discovery - fixed neighbor discovery on Mesh interfaces;
*) discovery - report IPv6 LL address if global address does not exist;
*) filesystem - fixed repartition on devices with containers;
*) hotspot - added "install-hotspot-queue" parameter to control dynamic queue creation (CLI only);
*) ike1 - improved expired IPsec-SA processing;
*) interface - improved system stability when handling large packets on CCR2216;
*) ipsec - removed Blowfish and Camellia encryption algorithms for IKE;
*) ipv6 - do not generate LL addresses for VPN interfaces when IPv6 is disabled;
*) ipv6 - do not use invalid/disabled global addresses for IPv6 ND;
*) l2tp - added VRF support for L2TP Ether interfaces;
*) lte - added CA information in 5G mode;
*) lte - fixed new MTU value validation;
*) lte - use RSRP value reported by MBIM signal for MBIM type modems;
*) lte - validate bearer count when activating MBIM modem;
*) macsec - fixed packet duplication on Ethernet interface;
*) macsec - fixed packet transmission using traffic-generator;
*) macsec - fixed packet validation;
*) netwatch - improved "interval" and "packet-interval" coexistence for ICMP type;
*) ntp - log error message when server is unreachable;
*) ospf - fixed simple authentication and checksums for NBMA and PTMP links;
*) ospf - fixed virtual-link address selection for PTP links;
*) ping - fixed ARP ping;
*) port - added serial port support for Telit FB990 modem;
*) port - do not show unusable USB port on hAP ax^2;
*) ppp - changed default lease time of dynamic DHCPv6 server to 1 day;
*) quickset - fixed addition of bridge filter rules in bridged mode;
*) quickset - fixed interface list member table on configuration changes;
*) quickset - update DNS server IP address when changing router's IP address;
*) rb4011 - fixed reporting of current CPU frequency and changed default frequency to "auto";
*) sfp - allow usage of "10G Base-LR" mode for XS+31LC10D module;
*) snmp - added support for "lldpRemLocalPortNum" OID's;
*) supout - added missing IPv6 firewall sections;
*) supout - added MSTI and mst-override monitor for bridge MSTP;
*) switch - avoid packet corruption in some setups for 98DX3257, 98DX3255, 98DX4310, 98DX8525 and 98PX1012 switches;
*) switch - fixed SFP Tx disable when changing auto-negotiation settings for 98DXxxxx and 98PX1012 switches;
*) switch - improved 10Gbps Ethernet interface stability for 98DX8212 switch;
*) system - allow up to 4GB of RAM allocation per process on x86, ARM64 and TILE;
*) system - improved handling of user policies;
*) tr069-client - updated data model to version 2.15;
*) traffic-flow - fixed sending of sampling interval;
*) tunnels - added VRF support for EoIP, IPIP and GRE tunnels;
*) vxlan - added "local-address" parameter support;
*) vxlan - added VRF support;
*) webfig - fixed displaying of VRF routes;
*) webfig - fixed input validation for "VPLS ID" parameter;
*) webfig - fixed setting of "DHCP Option Set" parameter;
*) wifiwave2 - added "datapath" settings to configure data forwarding for an interface (CLI only);
*) wifiwave2 - added disable/enable commands to configuration profile sub-menus (CLI only);
*) wifiwave2 - added interworking/Hotspot 2.0 support (CLI only);
*) wifiwave2 - added more informative log messages on configuration profile changes;
*) wifiwave2 - added option to set per-client vlan-id in access list (only supported on 802.11ax interfaces) (CLI only);
*) wifiwave2 - added "provisioning" menu to automatically assign interface configurations to radios (CLI only);
*) wifiwave2 - do not permit a client device to be connected to more than one interface at a time;
*) wifiwave2 - removed maximum limit for group key update interval and changed the default to 1 day;
*) winbox - added "Active" prefix for current "Circuit ID" and "Cookie Length" fields for L2TP-Ether interfaces;
*) winbox - added "Make Static" button to "IP/DHCP Server/Leases" menu;
*) winbox - fixed minor typo in "Zerotier" menu;
*) winbox - improved handling of large WinBox protocol messages;
*) winbox - properly save "Interfaces/Detect Internet/Detect Internet State" menu in session file;
*) winbox - show "Switch" menu on Chateau 5G ax;
*) winbox - show "System/Health/Settings" only on boards that have configurable values;
*) winbox - show "System/RouterBOARD/Mode Button" on devices that have such feature;
*) winbox - show "USB Power Reset" menu on Chateau 5G ax;
*) wireless - fixed setting of realms interworking parameter if realms-raw is unset;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after some problem has appeared on device

Please keep this forum topic strictly related to this particular RouterOS release.

Posted: **Wed Oct 26, 2022 4:48 pm**

Very thanks!

Posted: **Wed Oct 26, 2022 5:39 pm**

RouterOS version 7.7beta3 has been released "v7 testing" channel!

*) certificate - improved certificate management, signing and storing processes;

SUP-95194 On clean fresh install 7.7beta3 it is reproduced. Please, fix it.
I not want save private key of CA in RouterOS. In 7.6beta8 its worked.

[admin@MikroTik] > /certificate add name="r1-ca" common-name="r1-ca" subject-alt-name="email:r1-ca" key-size=2048 key-usage=key-cert-sign,crl-sign
[admin@MikroTik] > /certificate sign "r1-ca"
  progress: done

[admin@MikroTik] > /certificate add name="r1" common-name="192.168.2.14" subject-alt-name="IP:192.168.2.14" key-size=2048 key-usage=digital-signature,content-commitment,key-encipherment,key-agreement,tls-server
[admin@MikroTik] > /certificate sign "r1" ca="r1-ca"
  progress: done

[admin@MikroTik] > /certificate export-certificate r1-ca file-name=r1-ca export-passphrase=passphrase type=pem
[admin@MikroTik] > /certificate export-certificate r1 file-name=r1 export-passphrase=passphrase type=pkcs12
[admin@MikroTik] > /certificate/remove r1-ca
[admin@MikroTik] > /certificate/import file-name="r1-ca.crt" name="r1-ca" passphrase="passphrase"
     certificates-imported: 1
     private-keys-imported: 0
            files-imported: 1
       decryption-failures: 0
  keys-with-no-certificate: 0

[admin@MikroTik] > /certificate/import file-name="r1.p12" name="r1" passphrase="passphrase"
     certificates-imported: 1
     private-keys-imported: 1
            files-imported: 1
       decryption-failures: 0
  keys-with-no-certificate: 0

[admin@MikroTik] > /caps-man/manager/set ca-certificate=r1-ca certificate=r1 enabled=yes require-peer-certificate=yes
input does not match any value of ca-certificate

Posted: **Wed Oct 26, 2022 5:41 pm**

Your configuration is invalid, I already explained it to you in 7.6rc topic.

Posted: **Wed Oct 26, 2022 5:46 pm**

is this fixing [SUP-81652] about crash of bgp process that saturated 4gb shared memory?
*) system - allow up to 4GB of RAM allocation per process on x86, ARM64 and TILE;

so now the shared memory allow 4GB for each process?
right?

Posted: **Wed Oct 26, 2022 6:21 pm**

Your configuration is invalid, I already explained it to you in 7.6rc topic.

I don't understand why if p12 of CA is used in new ROS - the "ca-certificate" works. But if only the cert of CA is used - it does not work.
What is the case of the ca-certificate key in /caps-man/manager/? Is the "ca-certificate" parameter deprecated (if it is not necessary to specify it in my case)? I'm sorry, it's not entirely logical.

Posted: **Wed Oct 26, 2022 6:44 pm**

P12 is a certificate bundle and consists of the whole chain of trust including private key for the host certificate.
The "ca-certificate" parameter for CAPsMAN is used for new certificate distribution (signing) for newly added CAPs with dynamic certificate generation enabled. To sign new certificates, private key for the CA certificate is required. Thus you can not specify a CA certificate in CAPsMAN config without a private key.
Validation of existing CAP certificates does not require the private key for the CA certificate, nor the CA certificate to be configured under the "ca-certificate" parameter. The validation is performed against the whole Certificate store just like it is in any other system or service.

Posted: **Thu Oct 27, 2022 3:37 pm**

Good Morning
We were testing with the CCR2116 using it for PPPoE, we got 2400 connections, we had some problems....
CPU rising to 100% with 2GB of traffic
PPPoE disconnecting in bulk
Simple Queue not being removed and not allowing pppoe to reconnect because it said it already had a simple queue running.
We had to take out the CCR2116 and put the CCR1036 in place.
In version 7.7 beta, I didn't see anything talking about PPPoE, was something done?

Posted: **Thu Oct 27, 2022 9:56 pm**

fabeni - Which version did you test before? It sounds like an issue solved in 7.6 "ppp - improved service stability when multiple users disconnect simultaneously". If you did still experience a such problem with 7.6 or 7.7, then please send supout to support@mikrotik.com.

Posted: **Thu Oct 27, 2022 11:42 pm**

Strods.
tests performed on 7.5 and 7.6 both had the same problems.
A ticket was opened with the support file in my mikrotik account

Posted: **Fri Oct 28, 2022 9:53 am**

*) filesystem - fixed repartition on devices with containers;

Seems ok!

Now containering starts :-)
1. Adguard home with ssh --> ok!
2. Openspeedtest with ssh --> ok!
3. FreePBX missing till now .... ongoing
Nice

Thanks

Posted: **Fri Oct 28, 2022 10:19 am**

What's new in 7.7beta4 (2022-Oct-27 09:00):

*) conntrack - improved system stability when PPTP helper is used;
*) hotspot - fixed maximum allowed connections limitation;
*) netwatch - fixed reporting of VRF name in logging messages;
*) ospf - fixed MD5 checksum calculation;
*) sfp - added 2.5G SFP module support for RB5009;
*) webfig - properly detect current location for navigation buttons;
*) wifiwave2 - properly report interface on which traffic is received when multiple station interfaces are used concurrently;
*) wifiwave2 - removed maximum limit for group key update interval and changed the default to 1 day;

Posted: **Fri Oct 28, 2022 11:29 am**

is this fixing [SUP-81652] about crash of bgp process that saturated 4gb shared memory?
*) system - allow up to 4GB of RAM allocation per process on x86, ARM64 and TILE;

so now the shared memory allow 4GB for each process?
right?

any answer?

Posted: **Fri Oct 28, 2022 2:04 pm**

Hi,
im just wonderng if we can expect 802.11 k support? This is the latest missing....

Posted: **Fri Oct 28, 2022 2:41 pm**

Hi,
im just wonderng if we can expect 802.11 k support? This is the latest missing....

Support for 802.11k for the wifiwave2 package was introduced in RouterOS 7.5

Posted: **Fri Oct 28, 2022 3:16 pm**

FToms
What about 802.11v🤔

Posted: **Fri Oct 28, 2022 3:35 pm**

802.11v has not yet been implemented.
It is a large ammendment, so suggestions on which features of it users are most interested in would be welcome. If you have such suggestions, please make a dedicated thread or a support ticket.

Posted: **Fri Oct 28, 2022 3:56 pm**

@fabeni

Simple Queue is not being removed and not allowing PPPoE to reconnect because it said it already had a simple queue running.

Is this similar to your problem?

asd.jpg

Posted: **Fri Oct 28, 2022 5:18 pm**

Do you really think you can silence the people asking for BFD by deleting their comments?
The lack of BFD is the main reason blocking an upgrade from v6 to v7 for me and many others.
We NEED it to be worked on. Really worked on. Not only claimed it is a "work in progress".

Posted: **Fri Oct 28, 2022 6:03 pm**

@own3r1138
Exactly, this happened with 2400 concurrent clients and the simple queue could not be removed.

Posted: **Fri Oct 28, 2022 6:08 pm**

@own3r1138
What I find strange is that this kind of PPPoE problem did not exist in versions 6.x
Because it is something used all over the world, it should be given some importance to correct it, I believe they are focused on the routing part that they forgot the PPPoE part

Posted: **Fri Oct 28, 2022 8:34 pm**

802.11v has not yet been implemented.
It is a large ammendment, so suggestions on which features of it users are most interested in would be welcome. If you have such suggestions, please make a dedicated thread or a support ticket.

Posted:

viewtopic.php?t=190436

Based on Apple's points outlined here: https://support.apple.com/en-us/HT202628

Posted: **Fri Oct 28, 2022 8:44 pm**

@fabeni
I have three CHRs currently running V 7.6 with the same configuration. This one is the busiest, which I run into a problem with. Since @strods asked for a supout, I will raise a ticket as soon as the issue occurs again. I urge you to do the same, please.

Posted: **Fri Oct 28, 2022 11:43 pm**

@own3r1138
I already opened a support with the file and sent it by email

Posted: **Sat Oct 29, 2022 4:13 pm**

Encountered issues in CAPsMan
No 5G wireless in the AP
Reverted back to 7.6 ok

Posted: **Sat Oct 29, 2022 4:14 pm**

Also still no support for intelligent i225-V ethernet interface

Looking forward to have this in upcoming beta

Posted: **Sat Oct 29, 2022 7:57 pm**

@fabeni
Simple Queue is not being removed and not allowing PPPoE to reconnect because it said it already had a simple queue running.
Is this similar to your problem?
asd.jpg

we are experiencing the same with pppoe on x86 platform, around 5000 vlan with 5000 ppposerver (one for each client) over them.
some time the simple queue got not removed when the client disconnect. The only way to recover is to reboot it.

regards

Posted: **Sun Oct 30, 2022 3:21 am**

One PPPoE server and VLAN for each client? What is the purpose of such a complicated setup?

Posted: **Sun Oct 30, 2022 3:29 am**

@mduchame

Most likely is for the broadcast storm mitigation, i might be wrong but that's the only logical explanation i can think off.

Posted: **Sun Oct 30, 2022 4:14 am**

There are usually other ways of handling that without resorting to making a VLAN per customer.

Posted: **Sun Oct 30, 2022 5:28 am**

There are usually other ways of handling that without resorting to making a VLAN per customer.

this is the way OF and TIM deliver access customer to isp in Italy

Posted: **Sun Oct 30, 2022 7:45 am**

*) discovery - added "discovered-by" parameter to indicate which protocol discovered the neighbor;

This new feature seems to be listing MNDP for everything, including my Windows desktop (which is sending LLDP but I doubt Microsoft programmed an MNDP client in there). The LLDP and CDP detection seems to be working though.

Posted: **Sun Oct 30, 2022 7:12 pm**

Beta4 successfully installed on a Chateau LTE12.

Posted: **Sun Oct 30, 2022 7:18 pm**

Dito on Sxt lte6

Posted: **Sun Oct 30, 2022 7:36 pm**

*) sfp - added 2.5G SFP module support for RB5009;

Thanks. If AutoNeg is disabled and speed fixed to 2.5GB, it works with an ISP provided PON-ONT in RB5009 SFP+ port.

Posted: **Sun Oct 30, 2022 9:21 pm**

DOM/DDM still not work on my RB760iGS (hex S)

Posted: **Sun Oct 30, 2022 9:48 pm**

And it is still not mentioned to be fixed.

Posted: **Mon Oct 31, 2022 6:25 am**

Anyone encountered the issue with l3-hw that some routes stop being reached? The solution is to stop and start again l3-hw ?

Posted: **Mon Oct 31, 2022 7:41 am**

rpingar - Yes. these changes should allow routing processes to consume more than 2 GB of RAM
Rox169 - Please keep these version topics related to the issues introduced in the particular release. These are not meant for feature requests.
own3r1138, fabeni, rpingar - Yes, this seems to be the same problem as mentioned above. Please send supout to support@mikrotik.com. Unfortunately, it is not as simple as creating a PPPoE server with more than X users and it will crash. Some particular timing or feature set must be used, which is why we need to debug your "bad" setups to resolve these issues. As for simple queues - since 7.5 you can not delete dynamic queues at all. That is why they are dynamic. In order to remove them, they must be disabled on a particular service that adds them.
pe1chl - We are well aware of the requests about BFD and it is still a work in progress. Please remember that these are version release topics in order to find out what was "broken" in a particular release. Not for repeated feature requests.
cklee234 - Please send supout file to support@mikrotik.com. Generate it when CAP has tried to connect to the CAPsMAN but was not able to do so.
cklee234 - Please keep these version topics related to the issues introduced in the particular release.
mducharme - Yes, LLDP support has been there for a while now and RouterOS under IP/Neighbo list can also show other installations, besides RouterOS.
dg1kwa - Yes, the issue with RB760 SFP modules is a known problem and will be solved as soon as possible.
Maggiore81 - Please send supout ifle to support@mikrotik.com. Generate it when these routes are not marked as reachable, although they should be reachable.

Posted: **Mon Oct 31, 2022 7:56 am**

mducharme - Yes, LLDP support has been there for a while now and RouterOS under IP/Neighbo list can also show other installations, besides RouterOS.

Yes, I know this, that isn't what I mean. I mean RouterOS shows for my Windows system "discovered by: MNDP, LLDP". I don't think Microsoft has built an MNDP stack into Windows, so I think this is incorrect. I do know Windows is sending LLDP packets, but it appears every device shows as discovered by MNDP even if it isn't sending MNDP packets.

RouterOS does seem to be able to properly identify which neighbors are sending LLDP and CDP properly and so the "discovered by" is accurate for those two protocols, but to me it does not make much sense to show "discovered by MNDP" for devices that are not sending MNDP in the first place.

Posted: **Mon Oct 31, 2022 8:12 am**

rpingar - Yes. these changes should allow routing processes to consume more than 2 GB of RAM

this is not going to fix the issue on my ticket.
Above a certain routes/peeer we still get unstable (hold time expire) peers, when reestabilsihed it is unable to load more then 7-9k messages from a peer then reset again.
ticket update with supout and logs.
the strange thing is that now the router doesn't crash the routing but more dangerous it reboot itself with the message:
oct/30/2022 10:36:52 system,error,critical router rebooted without proper shutdown, probably power outage

also we still get a lot of this logs:
07:20:00 route,bgp,info Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 555 a } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=2 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=3 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=4 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=5 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=6 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=7 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=8 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=9 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=10 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=11 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=12 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=13 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=14 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=15 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 573 a } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=2 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=3 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=4 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=5 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=6 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=7 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=8 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=9 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=10 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=11 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=12 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=13 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=14 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=15 max=64 sk=Socket{ -1 } }

regards

Posted: **Mon Oct 31, 2022 9:08 am**

And it is still not mentioned to be fixed.

how long allready? With ROS6 all fine and ROS7 is now at V7.6 :(

Posted: **Mon Oct 31, 2022 9:17 am**

in beta4 there is also a problem about rpki log showing in winbox.
attached the winboxlog.

here the cli log:
08:04:36 route,rpki,info Session { validator 83.229.8.211:3323 Sync } state change to Prepare
08:04:36 route,rpki,info Session { validator 83.229.8.211:3323 Prepare } send serial query version: 1 id: 33428 serial: 98
08:04:36 route,rpki,info Group validator cache update start
08:04:36 route,rpki,info Session { validator 83.229.8.211:3323 Prepare } state change to Loading
08:04:36 route,rpki,info Group validator cache update done
08:04:36 route,rpki,info Session { validator 83.229.8.211:3323 Loading } sync update serial: 99
08:04:36 route,rpki,info Session { validator 83.229.8.211:3323 Loading } state change to Sync

seems that the order of logs is inverse

Posted: **Mon Oct 31, 2022 9:54 am**

mducharme - Yes, LLDP support has been there for a while now and RouterOS under IP/Neighbo list can also show other installations, besides RouterOS.
Yes, I know this, that isn't what I mean. I mean RouterOS shows for my Windows system "discovered by: MNDP, LLDP". I don't think Microsoft has built an MNDP stack into Windows, so I think this is incorrect. I do know Windows is sending LLDP packets, but it appears every device shows as discovered by MNDP even if it isn't sending MNDP packets.

RouterOS does seem to be able to properly identify which neighbors are sending LLDP and CDP properly and so the "discovered by" is accurate for those two protocols, but to me it does not make much sense to show "discovered by MNDP" for devices that are not sending MNDP in the first place.

It does not show discovered by MNDP if the device is not actually sending MNDP. Your PC most likely got discovered by MNDP when you open a WinBox.

Posted: **Mon Oct 31, 2022 11:14 am**

rpingar - Yes. these changes should allow routing processes to consume more than 2 GB of RAM
this is not going to fix the issue on my ticket.
Above a certain routes/peeer we still get unstable (hold time expire) peers, when reestabilsihed it is unable to load more then 7-9k messages from a peer then reset again.
ticket update with supout and logs.
the strange thing is that now the router doesn't crash the routing but more dangerous it reboot itself with the message:
oct/30/2022 10:36:52 system,error,critical router rebooted without proper shutdown, probably power outage

also we still get a lot of this logs:
07:20:00 route,bgp,info Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 555 a } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=2 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=3 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=4 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=5 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=6 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=7 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=8 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=9 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=10 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=11 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=12 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=13 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=14 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=15 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 573 a } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=2 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=3 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=4 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=5 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=6 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=7 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=8 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=9 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=10 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=11 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=12 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=13 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=14 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=15 max=64 sk=Socket{ -1 } }

regards

I had this with version 7.5....fixed in 7.6b8, witch version do you use ?

Posted: **Mon Oct 31, 2022 11:29 am**

.......

CCR2216 - 7.7beta4, unfortunately beta8 is not available, with NOT updated bootloader because it needs a powercycle each time i upgrade it.
which platform do you use?

Posted: **Mon Oct 31, 2022 11:48 am**

it is possible to do static name for the bgp-vpls, rather than create dynamic after any bounced?

Posted: **Mon Oct 31, 2022 1:34 pm**

There are usually other ways of handling that without resorting to making a VLAN per customer.
this is the way OF and TIM deliver access customer to isp in Italy

Hi, that's not quite the case .. They send you the traffic on a collection SVLAN where they then encapsulate a Customer VLAN. In your BRAS server you just need to create a single PPPoE Server and bridge the SVLAN + CVLAN. Then you create an L2 rule where you block inbound traffic and only allow PPPoE and PPPoE Discover ...

Posted: **Mon Oct 31, 2022 2:59 pm**

good luck about it.

Posted: **Mon Oct 31, 2022 5:33 pm**

pe1chl - We are well aware of the requests about BFD and it is still a work in progress. Please remember that these are version release topics in order to find out what was "broken" in a particular release. Not for repeated feature requests.

Well, I do not consider this a "feature request", but more a "things that are broken in v7.x".
When a new 7.x beta is released and it again does not achieve feature parity with 6.49, that is something that needs to be worked on with more priority than new features of v7.
Only when v7 achieves full feature parity (for all except features that are officially abandoned) we can leave v6 behind.

Posted: **Mon Oct 31, 2022 7:19 pm**

But your spam is still annoying, like that guy with his socks problem.
It's not something that was working in previous 7.7 or 7.6 release and it broke in this beta release.
Nor is it something that was implemented in the previous release and it has bugs to squash.
So yeah, offtopic.

Posted: **Mon Oct 31, 2022 7:58 pm**

CCR2216 - 7.7beta4, unfortunately beta8 is not available, with NOT updated bootloader because it needs a powercycle each time i upgrade it.
which platform do you use?

@rpingar

2 x CCR2216 beta8 was 7.6 channel...no had anymore new issue since...

Posted: **Mon Oct 31, 2022 9:26 pm**

own3r1138, fabeni, rpingar - Yes, this seems to be the same problem as mentioned above. Please send supout to support@mikrotik.com.

Hello,
I raised a ticket, SUP-96432.

Thank you.

Posted: **Tue Nov 01, 2022 1:27 am**

CCR2216 - 7.7beta4, unfortunately beta8 is not available, with NOT updated bootloader because it needs a powercycle each time i upgrade it.
which platform do you use?
@rpingar

2 x CCR2216 beta8 was 7.6 channel...no had anymore new issue since...

7.6beta8 didn't work for me.
I have, on NAP routers, between 280 and 350 sessions each.

Posted: **Tue Nov 01, 2022 7:29 pm**

Sending a Route Refresh from a v6 router to a v7 router still results in the message: RECV RouteRefresh with invalid subtype: 0
Not new for this release but quite unfortunate as it results in routing instability when route filters are changed on a v6 router and refresh is requested.
Hopefully BGP can receive some love again!

Posted: **Tue Nov 01, 2022 8:06 pm**

Maybe I found an issue with macsec and DHCP client.

When a macsec-interface is connected to a bridge, the DHCP-client on that bridge does not take the offers from the DHCP-server on the "other side". So I hat to add a static address and route.

Posted: **Tue Nov 01, 2022 11:05 pm**

@Struds wrote:
pe1ch - We are well aware of the requests about BFD and it is still a work in progress. Please remember that these are version release topics in order to find out what was "broken" in a particular release. Not for repeated feature requests.

BFD is absolutely not what you call it a ”feature request”!

It's rather a very important piece of the v6 functional set that is still missing in v7.

Posted: **Tue Nov 01, 2022 11:10 pm**

this is the way OF and TIM deliver access customer to isp in Italy
Hi, that's not quite the case .. They send you the traffic on a collection SVLAN where they then encapsulate a Customer VLAN. In your BRAS server you just need to create a single PPPoE Server and bridge the SVLAN + CVLAN. Then you create an L2 rule where you block inbound traffic and only allow PPPoE and PPPoE Discover ...

I might be wrong, but you still need some sort of port isolation otherwise you might be targeted by some rogue pppoe traffic. Maybe you can control (L2) the pppoe discovery direction, I'm not sure about that and I should check. Do you have any insight ?
Our BRASes are Cisco (LAC) where we do L2TP towards a bunch of Mikrotiks (LNS) so we don't have the scenario above.
It would be amazing to have LAC capabilities in ROS .. at some time!

Posted: **Wed Nov 02, 2022 2:39 am**

What's new in 7.7beta4 (2022-Oct-27 09:00):

*) conntrack - improved system stability when PPTP helper is used;
*) hotspot - fixed maximum allowed connections limitation;
*) netwatch - fixed reporting of VRF name in logging messages;
*) ospf - fixed MD5 checksum calculation;
*) sfp - added 2.5G SFP module support for RB5009;
*) webfig - properly detect current location for navigation buttons;
*) wifiwave2 - properly report interface on which traffic is received when multiple station interfaces are used concurrently;
*) wifiwave2 - removed maximum limit for group key update interval and changed the default to 1 day;

please add support:

sfp - added 2.5G SFP module support for RB4011, why not?

Posted: **Wed Nov 02, 2022 7:47 am**

I do not use BFD myself, but since it is a working feature in RouterOS v6 (at least for the most part), I hope MikroTik does not release a "long-term" RouterOS v7 version without it.

I still need a bunch of other bugs fixed before I can move certain routers to v7 myself.

Posted: **Wed Nov 02, 2022 11:36 am**

Well, in general I would hope that MikroTik put more priority in finishing the v6->v7 migration even when that reduces the priority on working on new features in v7.
We now are in the situation where many routers cannot be upgraded from v6 to v7 and that is not good, neither for the customer nor for MikroTik.

Posted: **Wed Nov 02, 2022 4:27 pm**

MT was able to fix the BGP issue on my router using a 7.99 release and soon the fixes will be available in 7.7beta.
thanks to all the MT team

Posted: **Wed Nov 02, 2022 6:57 pm**

Posted: **Wed Nov 02, 2022 7:19 pm**

Okay, updated 2x CRS326-24G-2S+ and 1x CRS328-24P-4S+ from 7.6 to 7.7Beta4 (ROS and FW).
After activating the IPv6 Hw Offloading in the Switch menu all switches start to reboot every few minutes spontaniously (Switch was rebooted without proper shutdown).
After deactivating this feature the problem has gone. All switches are configured with IPv4 and IPv6, but a connection was only possible with Layer 2 (MAC), so the whole IP-Stack was gone. No special configurations, only 2 VLANS, RSTP, that´s all.
All 3 switches are connected via SFP+ (1x Fiber and 2x Copper).
@MT: I´ve reported this problem also with ROS 7.6Beta, a ROS 7.7Alpha49 had similar problems.
I hope this problem can be fixed until to the stable version.

Posted: **Wed Nov 02, 2022 7:58 pm**

MT was able to fix the BGP issue on my router using a 7.99 release and soon the fixes will be available in 7.7beta.
thanks to all the MT team

What was the BGP issue fixed?

Posted: **Wed Nov 02, 2022 8:41 pm**

on a lot of sessions (more then 200) and with a lot of prefixes received (mpr then 2M) the router was not able to handle some session getting them disconnected by holdtimer expration.
regards

Posted: **Wed Nov 02, 2022 10:49 pm**

Well, in general I would hope that MikroTik put more priority in finishing the v6->v7 migration even when that reduces the priority on working on new features in v7.
We now are in the situation where many routers cannot be upgraded from v6 to v7 and that is not good, neither for the customer nor for MikroTik.

We are also in the situation where new hardware to replace the same model in the case of replacement failure is shipping with V7 not V6.

Successfully updated an rb2011

Posted: **Thu Nov 03, 2022 1:20 pm**

MT was able to fix the BGP issue on my router using a 7.99 release and soon the fixes will be available in 7.7beta.
thanks to all the MT team

What was the BGP issue fixed?

described early in this section...

Posted: **Thu Nov 03, 2022 2:07 pm**

Ok thanks, I found the post with the reference.

Posted: **Thu Nov 03, 2022 9:46 pm**

Hello, I want to report that with WifiWave2 /interface wifiwave2 add...configuration.client-isolation=yes is not working anymore

Posted: **Fri Nov 04, 2022 2:51 pm**

*) vxlan - added "local-address" parameter support;
Please add local-address and vrf parameter support also to vtep configuration

Posted: **Fri Nov 04, 2022 9:49 pm**

What's new in 7.7beta4 (2022-Oct-27 09:00):

Still unable establish OSPFv3 session with two ROS v6 routers.

22:00:17 route,ospf,info instance { version: 3 router-id: 10.0.0.252 } created
22:00:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } area { 0.0.0.0 } created
22:00:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } created
22:00:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } state change to Waiting
22:00:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Down } state change to Init
22:00:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Init } state change to TwoWay
22:00:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Down } state change to Init
22:00:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Init } state change to TwoWay
22:00:24 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: TwoWay } state change to Init
22:00:27 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Init } state change to TwoWay
22:00:34 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: TwoWay } state change to Init
22:00:37 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Init } state change to TwoWay
22:00:44 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: TwoWay } state change to Init
22:00:47 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Init } state change to TwoWay
22:00:54 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: TwoWay } state change to Init
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor election
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } state change to DR
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } change DR: me BDR: 10.0.0.1
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: TwoWay } state change to ExStart
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Init } state change to TwoWay
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: TwoWay } state change to ExStart
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: ExStart } negotiation done
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: ExStart } state change to Exchange
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Exchange } exchange lsdb size 1
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: ExStart } negotiation done
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: ExStart } state change to Exchange
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Exchange } exchange lsdb size 1
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Exchange } exchange done
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Exchange } state change to Loading
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Exchange } exchange done
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Exchange } state change to Loading
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Loading } loading done
22:00:57 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Loading } state change to Full
22:01:03 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Loading } loading done
22:01:03 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Loading } state change to Full
22:01:03 route,ospf,warning default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Full } received wrong LS Ack for router 0.0.0.0 10.0.0.253 0x80000eaf expected 0x80000eb0
22:01:04 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Full } state change to Init
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Init } state change to TwoWay
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: TwoWay } state change to ExStart
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: ExStart } negotiation done
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: ExStart } state change to Exchange
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Exchange } exchange lsdb size 18
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Full } sequence mismatch
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Full } state change to ExStart
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Exchange } exchange done
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Exchange } state change to Loading
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: ExStart } negotiation done
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: ExStart } state change to Exchange
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Exchange } exchange lsdb size 16
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Loading } loading done
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Loading } state change to Full
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Exchange } exchange done
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Exchange } state change to Loading
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Loading } loading done
22:01:07 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Loading } state change to Full
22:01:08 route,ospf,warning default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Full } received wrong LS Ack for intra-area-prefix 0.0.0.0 10.0.0.252 0x80000001 expected 0x80000002
22:01:08 route,ospf,warning default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Full } received wrong LS Ack for router 0.0.0.0 10.0.0.252 0x80000001 expected 0x80000002
22:01:14 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Full } state change to Init
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Init } state change to TwoWay
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: TwoWay } state change to ExStart
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: ExStart } negotiation done
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: ExStart } state change to Exchange
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Exchange } exchange lsdb size 18
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Full } sequence mismatch
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Full } state change to ExStart
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Exchange } exchange done
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Exchange } state change to Loading
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: ExStart } negotiation done
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: ExStart } state change to Exchange
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Exchange } exchange lsdb size 16
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Loading } loading done
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Loading } state change to Full
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Exchange } exchange done
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Exchange } state change to Loading
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Loading } loading done
22:01:17 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Loading } state change to Full
22:01:18 route,ospf,warning default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Full } received wrong LS Ack for intra-area-prefix 0.0.0.0 10.0.0.252 0x80000002 expected 0x80000003
22:01:18 route,ospf,warning default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Full } received wrong LS Ack for router 0.0.0.0 10.0.0.252 0x80000002 expected 0x80000003
22:01:24 route,ospf,info default-v3 { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Full } state change to Init
22:01:24 route,ospf,info instance { version: 3 router-id: 10.0.0.252 } shutdown
22:01:24 route,ospf,info instance { version: 3 router-id: 10.0.0.252 } backbone-v3 { 0.0.0.0 } shutdown
22:01:24 route,ospf,info instance { version: 3 router-id: 10.0.0.252 } area { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.1 state: Full } state change to Down
22:01:24 route,ospf,info instance { version: 3 router-id: 10.0.0.252 } area { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } neighbor { router-id: 10.0.0.253 state: Init } state change to Down
22:01:24 route,ospf,info instance { version: 3 router-id: 10.0.0.252 } area { 0.0.0.0 } interface { broadcast fe80::d6ca:6dff:fe0e:dd4b%vlan4091 } destroyed
22:01:24 route,ospf,info instance { version: 3 router-id: 10.0.0.252 } area { 0.0.0.0 } destroyed
22:01:24 route,ospf,info instance { version: 3 router-id: 10.0.0.252 } destroyed

and this cycle again and again...

Posted: **Sat Nov 05, 2022 12:23 am**

Is this over a VPN tunnel?

Posted: **Sat Nov 05, 2022 12:41 am**

We now are in the situation where many routers cannot be upgraded from v6 to v7 and that is not good, neither for the customer nor for MikroTik.

Why would you want to update an in-production router to V7?
V6 is perfectly stable, there is absolutely no reason to do this step.

V7 is still a (more or less) better beta and FAR(!!!) away from any production-level.
My home-networks runs V7, but any network I am working on professionally is V6. The glitches and bug I see with V7... maybe in 2 - 5 years is V7 production ready. In the meantime its a playground for us. Another problem is, MT introduces 5 new feature and breaks 50 things. From this 50 things they fix maybe 20 to 25. And with the next version is begins again. They introduce more glitches as they are able to fix. Another point, look at their new "Wiki". Its a shame to see almost no progress there. I'd never install a product without a good documentation.

To come back, the is no reason to go to V7, Stay with V6 and be happy.

Posted: **Sat Nov 05, 2022 8:41 am**

V6 is perfectly stable, there is absolutely no reason to do this step.

There is, if you need to install a new device. Deploying CCR1xxx seems like a mistake now, it is a product that will be end of life sooner than later, and who knows if MikroTik will bother having RouterOS v8 (when that comes out) support the platform. I'm sure that is still years away, but CCR2xxx is the way to go for future proofing, and you can only run v7 on them.

We are starting to roll out CCR2xxx models with RouterOS v7 at new sites, not because we feel they are completely ready, but because we don't want to roll out CCR1xxx models.

Posted: **Sat Nov 05, 2022 10:34 am**

We now are in the situation where many routers cannot be upgraded from v6 to v7 and that is not good, neither for the customer nor for MikroTik.

Why would you want to update an in-production router to V7?
V6 is perfectly stable, there is absolutely no reason to do this step.

Because all development is happening in v7, and we "need" some of it. E.g. now we have 2 internet connections and an elaborate load balancing/failover configuration on it, but it is only working for IPv4. For IPv6 we can only use one of the providers and no load balancing (failover maybe would be possible but I do not want to invest in that).
With v7 at least there are more capabilities in IPv6 to do that, although they are not bugfree so not sure if we can really deploy that already. But when we have v7 running at least I can submit documented bugreports about it.

Also, in another network, we have many independent users/admins that together form a network. There is no real control about who upgrades and at what time, but when people upgrade to v7 certain things do break. It would be nice to have at least feature parity between v6 and v7 so people can upgrade without running into immediate problems because they lost important features (e.g. BFD).

Posted: **Sun Nov 06, 2022 12:17 pm**

We now are in the situation where many routers cannot be upgraded from v6 to v7 and that is not good, neither for the customer nor for MikroTik.

Why would you want to update an in-production router to V7?
V6 is perfectly stable, there is absolutely no reason to do this step.

V7 is still a (more or less) better beta and FAR(!!!) away from any production-level.
My home-networks runs V7, but any network I am working on professionally is V6. The glitches and bug I see with V7... maybe in 2 - 5 years is V7 production ready

I am running ALL of my devices on ROS 7 (7.6 for these days) in my BIG NETWORK in our BIG company. Which BTW running 24/7/365.

Switches, routers, capmans, VPN. All of it.

No problem whatsoever.

So I really do not agree with you.

If I would need some ospf, bgp and similar...
Yeah, I would rather wait for deploying ROS 7 for later times.

Posted: **Sun Nov 06, 2022 12:54 pm**

I am running ALL of my devices on ROS 7 (7.6 for these days) in my BIG NETWORK in our BIG company. Which BTW running 24/7/365.

Yeah, I would rather wait for deploying ROS 7 for later times.

You are running a BIG NETWORK in a BIG COMPANY without autorouting protocol?
I find that hard to believe... even when the network layout is clean and routes could be static, you usually at least want to have some backup/failover which is easiest to achieve with e.g. BGP+BFD.

Posted: **Sun Nov 06, 2022 2:11 pm**

One big building, several separate subnets on separate wires. Any dynamic routing is really not needed in our scenario.
Failover is done on 2L.

Posted: **Sun Nov 06, 2022 7:14 pm**

One big building, several separate subnets on separate wires. Any dynamic routing is really not needed in our scenario.
Failover is done on 2L.

So it is not a BIG NETWORK.

For actual big and complex networks that require dynamic routing with complex routing policies, v7 is beta at best.
Crucial features are missing (BFD), and others barely work (BGP).
I am sure MikroTik will now quote only the line above and say that BGP works fine, that they have no known bugs and that's what they use for their routing.

And right now we are at a dangerous crossroads, where MikroTik models that support v6 are becoming obsolete (ie: Nvidia EOLed Tilera chipsets) and new MikroTik models only support v7 which is not usable in critical workloads - which is a shame because new models are really cool in terms of specs.

If MikroTik doesn't get their act together and focus in bringing v7 in par with v6 in terms of functionality and usability, it's not going to be long before we have to move to other vendors. Not because we prefer them, but because there will be no other choice. Despite v7's slow development, projects still run and have to be delivered. We cannot wait forever.

Posted: **Sun Nov 06, 2022 9:30 pm**

I’m moving to opnsense as V7 doesn’t tick all my boxes.

Posted: **Mon Nov 07, 2022 12:26 pm**

What's new in 7.7beta6 (2022-Nov-04 15:59):

*) bgp - improved BGP session load distribution across multiple CPU cores;
*) certificate - improved certificate management, signing and storing processes;
*) container - fixed access to "/dev/stderr" from containers;
*) container - made "ram" and "tmp" directories use tmpfs;
*) crs1xx/2xx - fixed "new-customer-pcp" setting for ACL rules;
*) firewall - added "set-priority" option for IPv6 mangle firewall;
*) firewall - made "dynamic" parameter settable for IPv4 address lists;
*) hotspot - fixed minor memory leak after each successful login from WEB;
*) ike2 - added support for ChaChaPoly1305 encryption (CLI only);
*) ike2 - added support for DH Group 31 (EC25519) (CLI only);
*) ipsec - added hardware acceleration support for IPQ-6010;
*) netwatch - improved "interval" and "packet-interval" coexistence for ICMP type;
*) ovpn - fixed "Called-Station-Id" usage in RADIUS requests;
*) ppp - do not inherit routing mark for encapsulated packets;
*) ssh - do not allow SHA1 usage with strong crypto enabled;
*) switch - hide invalid settings for 98DX3255 and 98DX8525 switch chips;
*) swos - improved default SwOS backup file name;
*) vxlan - added VRF support;
*) webfig - ensure login page is displayed after each log out;
*) webfig - improved WEB caching capabilities;
*) wifiwave2 - added "datapath" settings to configure data forwarding for an interface (CLI only);
*) wifiwave2 - added initial CAPsMAN support (only compatible with wifiwave2 interfaces) (CLI only);
*) wifiwave2 - improved system stability when multiple virtual AP are configured;

Posted: **Mon Nov 07, 2022 12:55 pm**

*) wifiwave2 - added initial CAPsMAN support (only compatible with wifiwave2 interfaces) (CLI only);

...finally...can't wait for the Version wth Ui/winbox support
Will this capsman version support a mixed infrastructure (wifiwave2 and non-ww2 APs)?

Posted: **Mon Nov 07, 2022 12:58 pm**

No, WifiWave2 CAPsMAN is only compatible with WifiWave2 interfaces.

Posted: **Mon Nov 07, 2022 1:07 pm**

No, WifiWave2 CAPsMAN is only compatible with WifiWave2 interfaces.

Is it possible to run capsman and capsman-wave2 at the same time?

Posted: **Mon Nov 07, 2022 1:13 pm**

No, WifiWave2 CAPsMAN is only compatible with WifiWave2 interfaces.

What are plans for later?If we want to manage mix of new/old devices? Are we able to run 2 capsman instances, or we gona have to have 2 different Mikrotik devices in order to do it?

Posted: **Mon Nov 07, 2022 2:07 pm**

Is it not possible to run a Wifiwave2 cAP on an existing cAPsMan? I just tried this, but could not specify "interfaces" on the CLI under /interfaces/wifiwave2/cap/. Are the controllers compatible at all?

Posted: **Mon Nov 07, 2022 2:24 pm**

Unfortunately, it's not possible to run both types of CAPsMAN on the same device. For a configuration example, please see: https://help.mikrotik.com/docs/display/ ... ionexample:

Posted: **Mon Nov 07, 2022 2:33 pm**

Thank you very much for the documentation. The question is still open if a wifiwave2 cAP can work on an old cAPsMan.

Does not work for me with the following configuration:

/interface wifiwave2
add configuration.manager=capsman .mode=ap disabled=no
add configuration.manager=capsman .mode=ap disabled=no
/interface wifiwave2 cap
set discovery-interfaces=bridge-home enabled=yes

So are the systems incompatible in both directions cAP->cAPsMAN and cAPsMAN->cAP?

Thank you!
-Boris

Posted: **Mon Nov 07, 2022 2:38 pm**

Yes, WifiWave2 CAPsMAN can only manage WifiWave2 interfaces, and WifiWave2 interfaces can only be managed by WifiWave2 CAPsMAN.

Posted: **Mon Nov 07, 2022 2:42 pm**

Yes, WifiWave2 CAPsMAN can only manage WifiWave2 interfaces, and WifiWave2 interfaces can only be managed by WifiWave2 CAPsMAN.

Will that change in the future to have a flexible upgrade path? I think many of our customers would like to successively replace their cAPs.

Posted: **Mon Nov 07, 2022 2:43 pm**

Unfortunately, it's unlikely that it will change.

Posted: **Mon Nov 07, 2022 2:49 pm**

Unfortunately, it's unlikely that it will change.

Okay, that leaves the simultaneous operation of the new and old cAPsMan each taking care of their cAPs. Do both systems interfere with each other in the same Layer2?

Posted: **Mon Nov 07, 2022 3:12 pm**

@MikroTik
Can you elaborate on these two, Please?
*) ovpn - fixed "Called-Station-Id" usage in RADIUS requests;
*) ppp - do not inherit routing mark for encapsulated packets;

Posted: **Mon Nov 07, 2022 4:12 pm**

Hi,

*) ike2 - added support for DH Group 31 (EC25519) (CLI only);

Does this mean we can expect Brain Pool DH groups 28,29,30?

Posted: **Mon Nov 07, 2022 4:26 pm**

Unfortunately, it's unlikely that it will change.

Will you entertain the idea of a CAPSMANv1 Container, or a RouterOS Container limited to CAPSMANv1 and the relevant functionality?
If not full free RouterOS containers with their license bound to the underlying RouterOS they're running on?

Posted: **Mon Nov 07, 2022 5:45 pm**

What's new in 7.7beta6 (2022-Nov-04 15:59):

*) firewall - made "dynamic" parameter settable for IPv4 address lists;

did not find a corresponding entry/description which made that a little more clear to me
what's the actual change here?

cheers

Posted: **Mon Nov 07, 2022 7:05 pm**

What's new in 7.7beta6 (2022-Nov-04 15:59):

On fresh new on 7.7beta6 i cant choose enc-algorithms=aes-256-gcm in /ip/ipsec/proposal/add - failure: AEAD already provides authentication.
But aes-256-cbc - works (on 7.7beta4 add aes-256-gcm - works, problem with 7.7beta6).
SUP-97212

[admin@MikroTik] > /certificate add name="r1-ca" common-name="r1-ca" subject-alt-name="email:r1-ca" key-size=prime256v1 key-usage=key-cert-sign,crl-sign
[admin@MikroTik] > /certificate sign "r1-ca"
  progress: done

[admin@MikroTik] > /certificate add name="r1" common-name="192.168.2.14" subject-alt-name="IP:192.168.2.14" key-size=prime256v1 key-usage=digital-signature,content-commitment,key-encipherment,key-agreement,tls-se
rver
[admin@MikroTik] > /certificate sign "r1" ca="r1-ca"
  progress: done

[admin@MikroTik] > /certificate add name="r1-r2" common-name="r1-r2" subject-alt-name="email:r1-r2" key-size=prime256v1 key-usage=digital-signature,key-encipherment,data-encipherment,key-agreement,tls-client
[admin@MikroTik] > /certificate sign "r1-r2" ca="r1-ca"
  progress: done

[admin@MikroTik] > /ip/pool/add name=r1-r2 ranges=192.168.1.2
[admin@MikroTik] > /ip/ipsec/mode-config/add address-pool=r1-r2 address-prefix-length=32 name=r1-r2 split-include=0.0.0.0/0 system-dns=no
[admin@MikroTik] > /ip/ipsec/policy/group/add name=group1
[admin@MikroTik] > /ip/ipsec/profile/add dh-group=ecp256 enc-algorithm=aes-256 hash-algorithm=sha256 name=profile1 prf-algorithm=sha256 proposal-check=strict
[admin@MikroTik] > /ip/ipsec/peer/add exchange-mode=ike2 local-address=192.168.2.14 name=peer1 passive=yes profile=profile1
[admin@MikroTik] > /ip/ipsec/proposal/add auth-algorithms=sha256 enc-algorithms=aes-256-cbc,aes-256-gcm lifetime=8h name=proposal1 pfs-group=ecp256
failure: AEAD already provides authentication
[admin@MikroTik] > /ip/ipsec/proposal/add auth-algorithms=sha256 enc-algorithms=aes-256-gcm lifetime=8h name=proposal1 pfs-group=ecp256
failure: AEAD already provides authentication
[admin@MikroTik] > /ip/ipsec/proposal/add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=8h name=proposal1 pfs-group=ecp256

Posted: **Mon Nov 07, 2022 7:11 pm**

@depth0cert - try the proposal with no auth-algorithm. According to Netgate (PfSense) no auth-algorithm is required with AES-GCM for Phase 2. Believe that is why you are getting the error message.

Posted: **Mon Nov 07, 2022 8:05 pm**

@depth0cert - try the proposal with no auth-algorithm. According to Netgate (PfSense) no auth-algorithm is required with AES-GCM for Phase 2. Believe that is why you are getting the error message.

Yes, with auth-algorithms="" and enc-algorithms=aes-256-gcm on 7.7beta6 responder and 7.7beta6 initiator IKEv2 state is established. Thank you.

But what can i do with Apple devices (https://developer.apple.com/business/do ... erence.pdf) - i must choose The IKESecurityAssociationParameters and ChildSecurityAssociationParameters dictionaries may contain the following keys:
IntegrityAlgorithm String Optional. One of:
• SHA1-96
• SHA1-160
• SHA2-256 (Default)
• SHA2-384
• SHA2-512

Posted: **Mon Nov 07, 2022 8:26 pm**

But what can i do with Apple devices

Unfortunately, you'll have to dumb down your configuration to support the apple devices. So you'd have to use AES-CBC with SHA256. That or your have a P1/P2 for your site to site connection and then a separate P1/P2 for your remote clients. If that doesn't work for you, then GCM is out and CBC it is. The joys of Apple telling you how you will configure things.

Posted: **Mon Nov 07, 2022 9:26 pm**

I was able to check Apple as initiator (AES-256-GCM/SHA2-256) and 7.7beta6 as a responder (auth-algorithms="" enc-algorithms=aes-256-gcm). Everything works, thanks for the help!

Posted: **Mon Nov 07, 2022 11:03 pm**

Unfortunately, it's unlikely that it will change.

...this makes me feel sad :-(
For me, that means no new WiFi-Ax products from MT on the Xmas shopping list

Posted: **Mon Nov 07, 2022 11:14 pm**

Yes, WifiWave2 CAPsMAN can only manage WifiWave2 interfaces, and WifiWave2 interfaces can only be managed by WifiWave2 CAPsMAN.

From Wiki page (updated this evening):

Requirements:

Any RouterOS device, that supports the WifiWave2 package, can be a controlled wireless access point (CAP) as long as it has at least a Level 4 RouterOS license.
WifiWave2 CAPsMAN server can be installed on any RouterOS device that supports the WifiWave2 package, even if the device itself does not have a wireless interface
Unlimited CAPs (access points) supported by CAPsMAN

Do I understand correctly that only device able to use the wifiwave2 package are the devices able to be used as ww2-capsman ?
That leaves out A LOT of devices then ...

Posted: **Mon Nov 07, 2022 11:37 pm**

That leaves out A LOT of devices then ...

Are you wanting to use a mipsbe device for wifiwave2-capsman or something?

Posted: **Tue Nov 08, 2022 4:05 am**

No, WifiWave2 CAPsMAN is only compatible with WifiWave2 interfaces.

Does that mean only those who have wifiwave2 interface can act as the CAPsMAN ? like CHR/x86 architecture RouterOS, they cannot act as the CAPsMAN, correct ?

i have several hap ax2, and I tried today with x86 and CCR1009 as CAPsMAN but failed.

Posted: **Tue Nov 08, 2022 4:14 am**

Does that mean only those who have wifiwave2 interface can act as the CAPsMAN ? like CHR/x86 architecture RouterOS, they cannot act as the CAPsMAN, correct ?

Any device that has the wifiwave2 package available for that architecture can be used as the CAPsMAN, you just have to install the wifiwave2 package on it. It doesn't matter if it has wireless interfaces itself or not, as they said in an earlier post. Currently, this means that any arm or arm64 device can be the wifiwave2 CAPsMAN provided that it has enough memory and flash size, so something like an RB5009 or CCR2xxx model could easily be used as a wifiwave2 CAPsMAN. However, if the arm or arm64 device you want to use as a wifiwave2 CAPsMAN has wireless interfaces that are not supported by wifiwave2, you probably do not want to select it as the wifiwave2 CAPsMAN, otherwise the wireless interfaces built into it will no longer work. Therefore, you are better off selecting a device that either has no wireless interfaces or one that only has wifiwave2-compatible interfaces as your wifiwave2 CAPsMAN.

CHR/x86 cannot currently act as a wifiwave2 CAPsMAN only because there is no wifiwave2 package compiled for x86. I imagine this is just a temporary situation and that we will get a wifiwave2 package for the x86 architecture at some point to allow setting up a CHR as a wifiwave2 CAPsMAN.

Posted: **Tue Nov 08, 2022 4:29 am**

Looking forward to it ! Thanks for the quick reply !

Posted: **Tue Nov 08, 2022 8:43 am**

One PPPoE server and VLAN for each client? What is the purpose of such a complicated setup?

This kind of application is connected to OLT under ROS to prevent users from roaming. This problem is not found in version 6. Please pay attention to it and improve it in version 7

Posted: **Tue Nov 08, 2022 11:12 am**

CHR/x86 cannot currently act as a wifiwave2 CAPsMAN only because there is no wifiwave2 package compiled for x86.

It again shows that the architecture used for CAPsMAN is not reasonable. There should be no need at all to have support for a local wireless interface on the controller.
Hopefully the separate project "to investigate a new controller" will lead to a more reasonable corporate WiFi management solution, where you can host the controller wherever you like (e.g. on a VM, maybe even externally hosted at some cloud provider) instead of being limited to some MikroTik device where storage is always problematic.

Posted: **Tue Nov 08, 2022 11:42 am**

It again shows that the architecture used for CAPsMAN is not reasonable. There should be no need at all to have support for a local wireless interface on the controller.

CAPsMAN does not architecturally require support for local wireless interfaces.
Bundling CAPsMAN with drivers for supporting local wireless interfaces is a software distribution decision. One which may well be reviewed.

Posted: **Tue Nov 08, 2022 12:46 pm**

Hi,
I have installations of CapsMAN currently running on MIPS (HEX, HEXs, HEXpoe). In some of those networks, the only ARM devices are the CAPs themselves.
It would be a problem to replace the CAPacs by the next generation CAP ax devices with the new Capsman not capable of running on the existing HEXxx.

Of course not an unsolvable one, just a nuissance.

BR
W

Posted: **Tue Nov 08, 2022 1:05 pm**

On beta 4 I get FCS from a 2004 connected to a 1016 with an SFP+ DAC after some days of uptime.

Ill upgrade tonight to latest beta and see if it goes away.

Posted: **Tue Nov 08, 2022 1:06 pm**

Unfortunately, it's not possible to run both types of CAPsMAN on the same device. For a configuration example, please see: https://help.mikrotik.com/docs/display/ ... ionexample:

@Guntis Can I ask you to extend the example to how local offloading of different SSIDs to different VLANs on the CAP works? CAPSMAN forwarding has been abolished, if I read this correctly.
Also, the question is still open whether a simultaneous installation of Wifiwave2-Capsman and Capsman in the same VLAN may interfere with each other or coexist.

Posted: **Tue Nov 08, 2022 1:58 pm**

Are you wanting to use a mipsbe device for wifiwave2-capsman or something?

Hi,
I have installations of CapsMAN currently running on MIPS (HEX, HEXs, HEXpoe). In some of those networks, the only ARM devices are the CAPs themselves.
It would be a problem to replace the CAPacs by the next generation CAP ax devices with the new Capsman not capable of running on the existing HEXxx.

Of course not an unsolvable one, just a nuissance.

And this is where I was going to ... Hex (or alike) are perfectly capable of being capsman controllers.
Why discard them from ww2-capsman ?
What with combined installations having non-arm caps and arm-caps ? You need 2 (ideally 4 for backup) controllers then ? That's just crazy.

You need to take into account the upgrade path.

Posted: **Tue Nov 08, 2022 2:23 pm**

They could yet release wifiwave2 packages for other architectures, like mmips or tile, to allow them to act as a wifiwave2 CAPsMAN. I can't see MikroTik deciding to restrict wifiwave2 CAPsMAN to only arm/arm64 architectures.

Posted: **Tue Nov 08, 2022 2:48 pm**

All the mips devices have limited processing power, does not make any sense there. But would be nice to have the package for TILE in future...

Posted: **Tue Nov 08, 2022 2:53 pm**

I think it doesn't make any sense to have a wifiwave2 CAPsMAN on mipsbe, but the ability to have them on mmips (hEX devices) might be useful.

Posted: **Tue Nov 08, 2022 3:19 pm**

Hi,
In my world, mostly a HEXpoe (MIPSBE) powers a few CAPs and it is also running the Capsman. It might not make much sense for hundreds of APs, but for small home/small business installations, it does. Of course those setups use local forwarding and HEXpoe is just used as a switch to forward to some other router (which is mostly not an MT).
The HEXpoe idles most of the time.
So yes, for me MIPSBE is an important architecture, as well as MMIPS.
This is a very power efficient setup, which is also important for some places.

BR
W

Posted: **Tue Nov 08, 2022 3:55 pm**

All the mips devices have limited processing power, does not make any sense there. But would be nice to have the package for TILE in future...

Well, and i'd like to see "wifi" package dropped from the CRS3xx build... there are better uses for the extremelly limited flash storage.

Posted: **Tue Nov 08, 2022 5:11 pm**

Well, and i'd like to see "wifi" package dropped from the CRS3xx build... there are better uses for the extremelly limited flash storage.

I think it wasn't a good idea to merge everything into a single package, especially in case of alternative packages like wireless/wifiwave2.
But also applications like samba, proxy, etc could have been kept separate.
I understand the need to merge system, ppp, security, ipv6, dhcp, advanced-tools and maybe routing into one package. But that should not have included wifi drivers and capsman.

Posted: **Tue Nov 08, 2022 6:30 pm**

Unfortunately, it's unlikely that it will change.

What is preventing you from releasing a stripped down "wifiwave2-light" package for cAP ac + hAP ac² which contains only the drivers for their wifi chipset and fit the small storage? This would allow mixed deployments with old and new devices.

Posted: **Tue Nov 08, 2022 6:45 pm**

so this is all about capsman now.

Posted: **Tue Nov 08, 2022 6:50 pm**

One big building, several separate subnets on separate wires. Any dynamic routing is really not needed in our scenario.
Failover is done on 2L.
So it is not a BIG NETWORK.

For actual big and complex networks that require dynamic routing with complex routing policies, v7 is beta at best.
Crucial features are missing (BFD), and others barely work (BGP).
I am sure MikroTik will now quote only the line above and say that BGP works fine, that they have no known bugs and that's what they use for their routing.

And right now we are at a dangerous crossroads, where MikroTik models that support v6 are becoming obsolete (ie: Nvidia EOLed Tilera chipsets) and new MikroTik models only support v7 which is not usable in critical workloads - which is a shame because new models are really cool in terms of specs.

If MikroTik doesn't get their act together and focus in bringing v7 in par with v6 in terms of functionality and usability, it's not going to be long before we have to move to other vendors. Not because we prefer them, but because there will be no other choice. Despite v7's slow development, projects still run and have to be delivered. We cannot wait forever.

You can use alternative opensource like vyos to get better BGP advance service, i don't know when BGP in mikrotik will be ready and fixed.
i wonder if "vyos" can run in mikrotik hardware, metarouter or container.

thx

Posted: **Tue Nov 08, 2022 7:05 pm**

You can use alternative opensource like vyos to get better BGP advance service, i don't know when BGP in mikrotik will be ready and fixed.
i wonder if "vyos" can run in mikrotik hardware, metarouter or container.

The big problem is the investment in knowledge and configurations for RouterOS.
That would all have to be re-learned when using different software.
There is a reason why we, a couple of years ago, switched from using plain Linux boxes as routers with all custom config/scripting, towards using MikroTik.
It would be a shame to have to abandon that, just because MikroTik cannot get a new project "finished" and has abandoned the old.
(I would be perfectly happy with a RouterOS v7 where you can select between a "routing-legacy" and "routing-new" package and run the v6 autorouting modules. they worked fine. we are not doing internet routing, only local networks)

Posted: **Tue Nov 08, 2022 7:12 pm**

On beta 4 I get FCS from a 2004 connected to a 1016 with an SFP+ DAC after some days of uptime.

Ill upgrade tonight to latest beta and see if it goes away.

I have had three GbE ports from a CCR2116 plugged into a CCR1036 as a backup path for months now, where the 2116 was running 7.x and the 1036 was on 6.49. I recently upgraded the 1036 to 7.6 and it's complaining of FCS errors from one of the three ports connected to the 2116 every hour or so.

On yours, which device is complaining about the FCS errors?

Posted: **Tue Nov 08, 2022 8:01 pm**

so this is all about capsman now.

It happens to be the big new feature for this 7.7beta6 version.

Posted: **Tue Nov 08, 2022 8:46 pm**

A feature that is even bigger for me than that is the set-priority being added to IPv6 mangle - we can finally have QoS fully working on IPv6.

Posted: **Tue Nov 08, 2022 8:55 pm**

so this is all about capsman now.
It happens to be the big new feature for this 7.7beta6 version.

would love to see existing features to be completed/stable and on par with previous rOS release (yes. v6)!
got 3 2116s at work which are scheduled for implementation as a cisco replacement and i am really worried to see a lot of hickups on those with that update path
and there are more in the pipeline
3x 1072
3x 2004
about 10x hEX(-S)

yes the hEX, 2004 and 1072s can be run on rOS6. no real point in that (2004 is RAM capped at 1792MB* in rOS6; 1072 and hEX would then be "version mismatched" with the central routers)
2116 is v7 only anyway
(and spare me "hEX is not recommended v7 ..." - i know mips boards are not recommendet but yet have some in good service for quite some time now)

EDIT: *) https://i.mt.lv/cdn/product_files/CCR20 ... 210911.pdf

Posted: **Tue Nov 08, 2022 11:52 pm**

Hex works just fine with ROS7.
Been running it since first beta.

Posted: **Tue Nov 08, 2022 11:55 pm**

Hex works just fine with ROS7.
Been running it since first beta.

same.
got 2 hEX S running v7 which build a VXLAN through wireguard ... ~160-200mbit through there just fine

Posted: **Wed Nov 09, 2022 6:09 am**

You can use alternative opensource like vyos to get better BGP advance service, i don't know when BGP in mikrotik will be ready and fixed.
i wonder if "vyos" can run in mikrotik hardware, metarouter or container.
The big problem is the investment in knowledge and configurations for RouterOS.
That would all have to be re-learned when using different software.
There is a reason why we, a couple of years ago, switched from using plain Linux boxes as routers with all custom config/scripting, towards using MikroTik.
It would be a shame to have to abandon that, just because MikroTik cannot get a new project "finished" and has abandoned the old.
(I would be perfectly happy with a RouterOS v7 where you can select between a "routing-legacy" and "routing-new" package and run the v6 autorouting modules. they worked fine. we are not doing internet routing, only local networks)

Even in "routing-legacy" there is also a lot bugs on it (full routes bugs, BGP vpn4 best routes calculation etc).
so many years mikrotik customers operate mikrotik devices with bugs until today.

thx

Posted: **Wed Nov 09, 2022 6:21 am**

I would be perfectly happy with a RouterOS v7 where you can select between a "routing-legacy" and "routing-new" package and run the v6 autorouting modules. they worked fine.

I don't think this is even possible. The v6 routing protocols were all written with route caching in mind, and removing route caching I believe would require a rewrite of them, which is almost as much work as creating the v7 routing protocols.

Posted: **Wed Nov 09, 2022 8:33 am**

Unfortunately, it's unlikely that it will change.
What is preventing you from releasing a stripped down "wifiwave2-light" package for cAP ac + hAP ac² which contains only the drivers for their wifi chipset and fit the small storage? This would allow mixed deployments with old and new devices.

The drivers are the biggest thing

Posted: **Wed Nov 09, 2022 10:55 am**

...if capsman in a mixed wiFi+ww2 will not be made possible, I can only urge you to enable ww2 on the smaller devices somehow.
...maybe introduce a staged boot for capsman, where drivers can be fetched remotely, once a cap gets connected or something else.
It is a shame letting these devices go to e-waste (not that availability - and money - for an infrastructure refresh is a given, these days).
Hell, I'd even pay a nominal license fee, i.e. managed via MT cloud- like for CHR - for my old cAP/wAP-ac in order to extend their lifetime with ww2 drivers.

Posted: **Wed Nov 09, 2022 10:57 am**

We are working on alternative solutions, but it is hard to say how long it will take.

Posted: **Wed Nov 09, 2022 10:59 am**

The drivers are the biggest thing

I think the guess is that the wifiwave2 package is so big because it contains drivers for several different chips, and maybe a wifiwave2-ipq4019 package could be compiled that is only for the hAP ac2 and would be small enough to fit in there.
However, considering that a 7.7beta install on the hAP ac2 only leaves about 1.5MB of free space on the flash, I don't think that is going to work, especially not when the main package is not split (i.e. the legacy wireless removed from that, amongst other big chunks that are not required in a home AP).

Posted: **Wed Nov 09, 2022 11:01 am**

...at least there is hope, then. Thanks Normis, much appreciated!

Posted: **Wed Nov 09, 2022 11:02 am**

Yes, we are contemplating the possibility of per-product packages. But that is only in discussion stage.

Posted: **Wed Nov 09, 2022 11:07 am**

I would be perfectly happy with a RouterOS v7 where you can select between a "routing-legacy" and "routing-new" package and run the v6 autorouting modules. they worked fine.
I don't think this is even possible. The v6 routing protocols were all written with route caching in mind, and removing route caching I believe would require a rewrite of them, which is almost as much work as creating the v7 routing protocols.

On the "plain Linux" systems where I run BGP daemons like quagga or bird (both are in use), I never encountered any problem with moving towards a kernel version without route caching. I think this is happening on a lower level. The routing daemons create their own route database, do their selection algorithms, and then load the resulting FIB in the system routing table. The system itself then caches that into the route cache, on older kernels. The only thing that visibly changed at that point is that originally you needed to do a "ip route flush table cache" (or equivalent system call) whenever you changed something else than a route insert/delete (e.g. a policy routing change), and now that command is a no-op. However, it is still accepted.

In v7 there is more visibility of the different tables (in /ip/route and /routing/route) but I don't think it would require "a rewrite", especially not of the higher levels of the BGP and BFD implementation.

Posted: **Wed Nov 09, 2022 11:07 am**

Yes, we are contemplating the possibility of per-product packages. But that is only in discussion stage.

Please don't, just add one more big mess...
One of the strengths of RouterOS is "the one package" for each architecture...

Posted: **Wed Nov 09, 2022 11:09 am**

But then there are issues like above. Too many drivers and tools that no longer fit on all models.

Posted: **Wed Nov 09, 2022 11:14 am**

.

In the past it was solved with separate packages ...
Don't care about the routing, ppp, hotspot and mpls on this access-point?
I don't put them there ...

or at least provide a separate package but just for the "drivers"

Posted: **Wed Nov 09, 2022 11:17 am**

But then there are issues like above. Too many drivers and tools that no longer fit on all models.

if it is possible, you could determine the packages which are elegible for install an a given hardware via e.g. netinstall or winbox.

what i mean hereby is, that, if a npk file is installed, netinstall/winbox could (if that is possible) determine which certain driver inside the npk is fit for the destined hardware and only that driver is installed ("de-bloat" so to say)

Posted: **Wed Nov 09, 2022 11:18 am**

rextended: the drivers package includes drivers for all wireless models :) this takes up a LOT of space.
special package per MODEL is the only way to solve it

Posted: **Wed Nov 09, 2022 11:19 am**

The firmware files are indeed big, but besides that there are a few kernel modules in there that are also huge, and those alone won't fit in the space left on a hAP ac2 for example.

04/11/2022  04:39 pm             9,156 asf.ko
04/11/2022  04:39 pm             4,580 mem_manager.ko
04/11/2022  04:39 pm           222,056 monitor.ko
04/11/2022  04:39 pm         1,733,420 qca_ol.ko
04/11/2022  04:39 pm           137,472 qca_spectral.ko
04/11/2022  04:39 pm           150,716 qdf.ko
04/11/2022  04:39 pm         3,961,076 umac.ko
04/11/2022  04:39 pm           621,712 wifi_2_0.ko
04/11/2022  04:39 pm           918,700 wifi_3_0.ko

Running wifiwave2 drivers with so little RAM (128MB) could be problematic too.
So don't get your hopes up that you'll ever see hAP ac2 or something with similar specs with wifiwave2 drivers running RouterOS.

Posted: **Wed Nov 09, 2022 11:19 am**

@normis

sorry, but then at first you meant separate wireless packages for drivers? not separate system package for each model??
I did not understand???

Posted: **Wed Nov 09, 2022 11:21 am**

.
In the past it was solved with separate packages ...
Don't care about the routing, ppp, hotspot and mpls on this access-point?
I don't put them there ...

or at least provide a separate package but just for the "drivers"

liked the separated packages management like in rOS v6 more. on a simple AP i always deinstalled packages such as mpls,routing,ppp....

i would appreciate such option turning back again

Posted: **Wed Nov 09, 2022 11:23 am**

[…]
the drivers package […] for […] wireless
special package per MODEL is the only way to solve it
[…]

Now I understand!
I had misunderstood before...
So it seems fair to me!

P.S.: It's time to drop SMPIS like old mipsLE...

Posted: **Wed Nov 09, 2022 11:27 am**

rextended: the drivers package includes drivers for all wireless models :) this takes up a LOT of space.
special package per MODEL is the only way to solve it

Another way would be to have the drivers all in the wifiwave2 distribution package, but then have some automatic procedure during install that checks which drivers are required on that model and only installs those in the flash, and discards the others.
At least then the user would not be faced with selecting the proper package for each model.

Still I think that joining some low-level stuff like security, ppp, dhcp, ipv6 etc into the main package was a good idea, because there were more and more inter-dependencies, but it was bad to merge essentially everything into one package. Stuff that is an application should be easy to make into a separate package.
(especially when the package management is made only slightly better: extend the package list to all available packages (on the update server) and allow the user to install them in the same way as they are removed and upgraded, so not by having to download a .zip and upload a file but just clicking an "install" button on a package that is listed as "not installed" in that list)

Posted: **Wed Nov 09, 2022 11:33 am**

Another way is to remove all unused drivers from RouterBOARD products,
such as additional USB devices or miniPCIe and all the other frills,
so that only people using non-mikrotik products have to be bothered to install drivers.

Posted: **Wed Nov 09, 2022 12:32 pm**

Back to the topic of the new release...

*) firewall - added "set-priority" option for IPv6 mangle firewall;

It appears the action=set-priority new-priority=from-dscp-high-3-bits in the ipv6 mangle rules does not work correctly. Priority is nearly always 0.
But with new-priority=from-dscp it seems to get a priority between 0 and 7, unlike with IPv4.
Maybe got some shifting and/or masking wrong?
It would be handy to have a "log" action or option that logs more attributes of the packet, so this could be adequately debugged.
(the current "log" option logs neither DSCP nor Priority)

Posted: **Wed Nov 09, 2022 2:33 pm**

Audience owner here, does the new CapMAN implementation allow my 2 Audiences to still mesh together, or is it going to horribly break things and best be left alone?

Posted: **Wed Nov 09, 2022 5:45 pm**

Will CAPsMAN ww2 support central forwarding eventually or has that gone away for good? I currently have a Cisco CAPWAP setup and really like having all the forwarding done centrally as I can maintain better control over traffic and security rather than done at the AP. I don't really want to expose each VLAN required to all APs.

Posted: **Wed Nov 09, 2022 5:53 pm**

One PPPoE server and VLAN for each client? What is the purpose of such a complicated setup?
This kind of application is connected to OLT under ROS to prevent users from roaming. This problem is not found in version 6. Please pay attention to it and improve it in version 7

with more then 2200 pppoeclient our x86 v7.6 (stable) concentrator is experiencing slowness:
- Winbox is very very late updating the interface counters;
- sometime the pppoe dynamic interface goes not in RUN state and remains on top of interfaces' list (frequently);
- sometime the dynamic simple-queue created by the pppoe are not deleted when the pppoe cleint disconnects (rarely)

tried to open a ticket by email but today seems your mta refuses my smtp.

regards

Posted: **Thu Nov 10, 2022 2:22 am**

I have issues with CAPsMan since v7.7 beta 4 that force me to back to v7.6.
After installed the beta 4 and 6, my 5G wifi parts stopped working. 2.4G wifi remained ok.
I saw reloading of CAPsMan from time to time.

Not sure if this happened in x86 only but reverting beta to v7.6 resumes normal

Posted: **Thu Nov 10, 2022 3:11 pm**

There is still PPP and Queue problem in the 7.7beta6 version.

Posted: **Thu Nov 10, 2022 7:17 pm**

There is still PPP and Queue problem in the 7.7beta6 version.

please report opening the ticket by web, because MT has mta server issue, and adding supout.
they need to look into it.

Posted: **Thu Nov 10, 2022 7:49 pm**

@own3r1138
Also post support ticket here.

Posted: **Thu Nov 10, 2022 11:49 pm**

A feature that is even bigger for me than that is the set-priority being added to IPv6 mangle - we can finally have QoS fully working on IPv6.

Did you try it? It does not work for me (set priority from DSCP)...

Posted: **Fri Nov 11, 2022 2:57 am**

Did you try it? It does not work for me (set priority from DSCP)...

No, I have not tried it yet, unfortunately, these are a crazy few weeks for me.

Posted: **Fri Nov 11, 2022 6:28 am**

I have issues with CAPsMan since v7.7 beta 4 that force me to back to v7.6.
After installed the beta 4 and 6, my 5G wifi parts stopped working. 2.4G wifi remained ok.
I saw reloading of CAPsMan from time to time.

Not sure if this happened in x86 only but reverting beta to v7.6 resumes normal

I am having issues with Capsman and 2.4Ghz on 7.7beta6. Some devices will connect briefly then disconnect. If I roll back to 7.6 it works perfectly.

Posted: **Fri Nov 11, 2022 8:39 am**

Could it be related to different versions in the CAPsMan and AP? AP is using V7.6

Posted: **Sat Nov 12, 2022 3:41 pm**

There is still PPP and Queue problem in the 7.7beta6 version.

SUP-96432 was raised on 29/Oct/22. I also have added the V7.7b6 supout file.

Posted: **Sun Nov 13, 2022 6:38 pm**

I have SUP-97395 opened for the same issue.
regards

Posted: **Mon Nov 14, 2022 7:43 pm**

On yours, which device is complaining about the FCS errors?

The 1016 connected to a 2004 was the one complaining.

Posted: **Tue Nov 15, 2022 10:23 am**

Hi!

I'm trying to replicate the CAPsMAN example you have in documentation for a brand new hAP-ax2. However, I'm unable to get the wireless interfaces up and running. As I'm trying to run CAPsMAN and CAP under the same device, the only modification I did from your example was to set caps-man-addresses=127.0.0.1 when I enabled the wireless interfaces as CAP.
Apparently the interfaces are joining CAPsMAN (in logs I can see messages for selected CAPsMAN MikroTik@127.0.0.1 and connected to MikroTik@127.0.0.1, and under WifiWave2 menu I can see both interfaces with message saying "managed by CAPsMAN"), however SSID is not broadcasted and seems not to be running.

Is this already supported (running CAP / CAPsMAN on the same device)? I'm running latest testing version, 7.7beta6

Thanks!

screenshot_capsman_setup.png

Posted: **Tue Nov 15, 2022 11:15 am**

It's not supported that the local interface will be controlled by CAPsMAN. But given how configuration profiles work - CAPsMAN uses the same exact "configuration", "datapath", "security" etc., you can just set the same configuration profile on the local interface, as the one you would pass to remote CAPs.

Posted: **Tue Nov 15, 2022 11:40 am**

It's not supported that the local interface will be controlled by CAPsMAN.

WHAT??

Posted: **Tue Nov 15, 2022 12:46 pm**

It's not supported that the local interface will be controlled by CAPsMAN

urlo_gatto.png

Posted: **Tue Nov 15, 2022 12:58 pm**

/interface/wifiwave2/set wifi1 configuration=x
versus
/interface/wifiwave2/cap set enabled=yes
/interface/wifiwave2/ set wifi1 configuration.manager=capsman-or-local

The second scenario only works for remote CAPs, but while the same configuration is passed, end result is exactly the same. There is no separate wireless interface menu, like with the previous CAPsMAN, everything is under /interface/wifiwave2/

Posted: **Tue Nov 15, 2022 1:02 pm**

Ok, sorry...

One question please: "usual" (if not better) roaming, is supported between local and remote devices on this way?

Posted: **Tue Nov 15, 2022 1:07 pm**

That wasn't mentioned as being implemented yet ;D

Posted: **Tue Nov 15, 2022 7:40 pm**

It's not supported that the local interface will be controlled by CAPsMAN. But given how configuration profiles work - CAPsMAN uses the same exact "configuration", "datapath", "security" etc., you can just set the same configuration profile on the local interface, as the one you would pass to remote CAPs.

I tried to setup that way (make sense what you said, as most of config is similar) and it seems to be working. However, I found a small issue when using "datapath" option for a configuration (non CAPsMAN). I tried to setup two different datapath with the same bridge (where vlan filtering is up and running), using the following config:

interface wifiwave2 datapath
add bridge=bridge client-isolation=no name=home vlan-id=10
add bridge=bridge client-isolation=yes name=guest vlan-id=11

But then these ports are added into the bridge, they are not setting up PVID = this tag. Is there any other change in datapath, appart of not having the flag "vlan-mode=use-tag" anymore? Am I doing something wrong?

Thanks!

Posted: **Fri Nov 18, 2022 10:57 am**

I just had a ethernet driver hangup on my RB4011. The ethernet ports 6-10 went down simultanously with a message:
interface,info ether6 link down
The devices connected to those ports lost their communication, however I saw that the router still received data from the device (e.g. DHCP request), but sending data from the router no longer worked.
The ether10 port has PoE enabled with "auto on", it remained powering the device (LHG) but communication was lost.
This was after about 8.5 days of uptime. I have never seen this before.
I tried disable/enable on one port but there was no change. A reboot fixed it. Have others encountered this problem?

Posted: **Fri Nov 18, 2022 4:30 pm**

is it a way to use wifiwave2 with wds ?

Posted: **Fri Nov 18, 2022 4:54 pm**

I just had a ethernet driver hangup on my RB4011. The ethernet ports 6-10 went down simultanously with a message:
interface,info ether6 link down
The devices connected to those ports lost their communication, however I saw that the router still received data from the device (e.g. DHCP request), but sending data from the router no longer worked.
The ether10 port has PoE enabled with "auto on", it remained powering the device (LHG) but communication was lost.
This was after about 8.5 days of uptime. I have never seen this before.
I tried disable/enable on one port but there was no change. A reboot fixed it. Have others encountered this problem?

never seen such a behaviour
SUPOUT in a ticket to mikrotik support maybe?

Posted: **Fri Nov 18, 2022 5:33 pm**

is it a way to use wifiwave2 with wds ?

I don't remember seeing announcement that the 4-address mode was implemented yet. Until that's done, neither WDS nor bridge modes will work.

Posted: **Fri Nov 18, 2022 7:08 pm**

never seen such a behaviour
SUPOUT in a ticket to mikrotik support maybe?

When it happens again I will make a supout file, this time I needed to reboot to fix it and did not think about making a supout.
(also this router config is quite complicated so always very large supout... I would hope someone sees the same thing on a default-config device)

Posted: **Sat Nov 19, 2022 10:52 am**

rpingar - Yes. these changes should allow routing processes to consume more than 2 GB of RAM
this is not going to fix the issue on my ticket.
Above a certain routes/peeer we still get unstable (hold time expire) peers, when reestabilsihed it is unable to load more then 7-9k messages from a peer then reset again.
ticket update with supout and logs.
the strange thing is that now the router doesn't crash the routing but more dangerous it reboot itself with the message:
oct/30/2022 10:36:52 system,error,critical router rebooted without proper shutdown, probably power outage

also we still get a lot of this logs:
07:20:00 route,bgp,info Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 555 a } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=2 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=3 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=4 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=5 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=6 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=7 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=8 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=9 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=10 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=11 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=12 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=13 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=14 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=15 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 573 a } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=2 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=3 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=4 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=5 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=6 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=7 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=8 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=9 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=10 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=11 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=12 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=13 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=14 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=15 max=64 sk=Socket{ -1 } }

regards

I have the same issues on CCR2116 edge router Routeros v7.5

Was told the problem was fixed in 7.6, so i upgraded to 7.6 stable when it was released, but no success, still get exactly the same error message as you rpingar.

route,bgp,info Write to bgp failed (9) { #buf=15 max=64 sk=Socket{ -1 } }

Posted: **Sat Nov 19, 2022 3:26 pm**

is it a way to use wifiwave2 with wds ?

I don't remember seeing announcement that the 4-address mode was implemented yet. Until that's done, neither WDS nor bridge modes will work.

That's exclude all new devices like ax2....

Posted: **Mon Nov 21, 2022 9:55 am**

this is not going to fix the issue on my ticket.
Above a certain routes/peeer we still get unstable (hold time expire) peers, when reestabilsihed it is unable to load more then 7-9k messages from a peer then reset again.
ticket update with supout and logs.
the strange thing is that now the router doesn't crash the routing but more dangerous it reboot itself with the message:
oct/30/2022 10:36:52 system,error,critical router rebooted without proper shutdown, probably power outage

also we still get a lot of this logs:
07:20:00 route,bgp,info Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 555 a } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=2 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=3 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=4 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=5 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=6 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=7 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=8 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=9 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=10 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=11 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=12 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=13 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=14 max=64 sk=Socket{ -1 } }
07:20:00 route,bgp,info Write to bgp failed (9) { #buf=15 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 573 a } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=2 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=3 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=4 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=5 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=6 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=7 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=8 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=9 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=10 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=11 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=12 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=13 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=14 max=64 sk=Socket{ -1 } }
07:20:38 route,bgp,info Write to bgp failed (9) { #buf=15 max=64 sk=Socket{ -1 } }

regards
I have the same issues on CCR2116 edge router Routeros v7.5

Was told the problem was fixed in 7.6, so i upgraded to 7.6 stable when it was released, but no success, still get exactly the same error message as you rpingar.

route,bgp,info Write to bgp failed (9) { #buf=15 max=64 sk=Socket{ -1 } }

7.7beta6 definitely fix it.
Now remain to fix a very low speed in update to peers (in some cases) and a little memory leak in rpki when a full route provider flap the bgp session (not confirmed).

regards

Posted: **Mon Nov 21, 2022 10:27 pm**

The problem of global variables that disappear still persists, someone from mikrotik who can say if they are taking action on the matter, test on hAP AC3?

viewtopic.php?p=944654#p944663

Posted: **Tue Nov 22, 2022 5:54 pm**

Anyone else have an issue with v6 PD on this version?

Mine (at night, I suspect it has thing to do with DHCPv6 renewals) will occasionally not get a PD anymore for some amount of time (up to 12 hours) even post reboot. I talked with my ISP and they couldnt find anything, I then downgraded and it seemed fine.

Posted: **Tue Nov 22, 2022 6:28 pm**

There could be an issue, when I check my IPv6 PD status I see there is no expire time (the field is empty).
However in my case the addresses remain valid. So I did not notice it until now. Maybe it depends on the actual expiry time in use by the ISP.

Posted: **Wed Nov 23, 2022 12:01 pm**

Premise: I've just updated my RB3011 from 6.49.7 to v.7.7beta6 on a 2nd partition just to test what I'll need to fix (some small adjustments to route scopes /target scopes and route tables/VRF and I'm almost done)

I've just noticed that the DNS redirect on my home router is not working (v 7.7beta6).

/ip firewall nat add action=redirect chain=dstnat dst-port=53 in-interface-list=LANs protocol=udp to-ports=53

It works if I forward the dns query externally:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=53 in-interface-list=LANs protocol=udp to-addresses=208.67.222.123 to-ports=53

If I make the dns query directly to the router IP, it works (Allow remote requests is obviously active and it's working).

Is the "redirect" action different in Ros7 in some way? Am I missing something ?
Any help or confirmation would be appreciated, thanx.

Posted: **Wed Nov 23, 2022 12:40 pm**

Since for me work as expected on 7.6, and you didn't specify if it works on 7.6 or not,
open a separate topic, as it may be your fault on the configuration, before spamming this whole topic with useless posts.

Posted: **Wed Nov 23, 2022 1:40 pm**

I've just noticed that the DNS redirect on my home router is not working (v 7.7beta6).
Code: Select all
/ip firewall nat add action=redirect chain=dstnat dst-port=53 in-interface-list=LANs protocol=udp to-ports=53

Conceptually: missing properties in NAT rules mean that those fields don't get changed. Since your NAT rule does not define to-addresses, the dst-address remains unchanged hence the rule doesn't do anything. So conceptually you have to set to-addresses to router's own IP address (if that's the destination you want to redirect DNS queries). The only mystery to me is why the same NAT command worked for you so far (if it actually worked?).

Posted: **Wed Nov 23, 2022 2:30 pm**

mkx) The same command works perfectly in Ros6 (you probably missed that the action is different, action=redirect already means "to the router itself" and you cannot specify an address).

rextended) I'm quite sure I already used that rule in previous Ros7.x so I thought it was version dependent. This is why I posted here.
Also, you said "work as expected on 7.6", so it kind of confirms that indeed it's version dependent.
tip: don't be too aggressive with moderation, it's worst than spam :-)

Posted: **Wed Nov 23, 2022 4:09 pm**

The documentation says "redirect - replaces the destination port of an IP packet with one specified by to-ports parameter and destination address to one of the router's local addresses". It apparently selects a random address, not necessarily the address of the interface the packet is arriving on. Maybe this behavior has changed.
It could be that your input firewall drops the packet because it does not consider the address acceptable for the interface, or e.g. because you have decided to drop DNS traffic towards "the external address" (instead of: incoming on the external interface).

Posted: **Wed Nov 23, 2022 7:23 pm**

[cut] ..It could be that your input firewall drops the packet ..[cut]

It's allowed, to be sure I added a specific rule to allow (on top, and the rule was hit and the log reported correctly the query) -> no answer from the local DNS server.
Tomorrow I'll try to downgrade to 7.6 to see if something changes. I'll update if it's relevant.
Thank you all for your help.

UPDATE: I think I've found the problem, not it works. It seems that now, if the packet get marked before the 'redirect', the DNS server ignore the request. Before it wasn't the case; I'll dig deeper but the actual workaround works (in mangle/pre-routing avoid/bypass any packet marking for the specific traffic that will hit a "redirect" in NAT table).

Posted: **Wed Nov 23, 2022 9:09 pm**

... if the packet get marked before the 'redirect', the DNS server ignore the request.

Not exactly, it's just that routing marks now have maximum priority, so your packets are going to internet instead of to router, see 1) in viewtopic.php?p=956630#p956630

Posted: **Wed Nov 23, 2022 9:39 pm**

Not exactly, it's just that routing marks now have maximum priority, so your packets are going to internet instead of to router, see 1) in viewtopic.php?p=956630#p956630

You're absolutely correct, that's it!!
I was still debugging and following the logic. So now, my marking rules were not specific enough, I need to add a specific bypass for external destinations that will be redirected becoming local destinations afterwards.

P.S. Sorry rextended, after all ..it was spam :-) Have a nice evening you all, thanks

Posted: **Thu Nov 24, 2022 2:25 pm**

What's new in 7.7beta8 (2022-Nov-23 09:19):

*) branding - fixed identity setting from branding package;
*) bridge - fixed host moving with fast-path;
*) bridge - removed "age" monitoring property from the host table;
*) container - fixed tar extracting;
*) dns - do not query upstream DNS servers for matched regex records;
*) dns - fixed changing of "forward-to" parameter for FWD entries;
*) dns - fixed handling of CNAME entry pointing to another FWD entry;
*) hotspot - added "install-hotspot-queue" parameter to control dynamic queue creation (CLI only);
*) ike1 - fixed XAuth responder trying to recreate phase 1;
*) ike2 - improved certificate payload parsing;
*) ipsec - added support for AVX optimized SHA acceleration;
*) ipsec - improved "H" (hw-aead) flag presence for accelerated SA's;
*) ipsec - improved configuration of IPsec proposal auth-algorithms;
*) ipsec - improved IKE payload processing;
*) l3hw - improved system stability when disabling or enabling L3HW offloading;
*) lte - fixed error handling on opening AT control channel;
*) lte - show band number in "ca-band" in NSA mode on Chateau 5G;
*) mpls - added VPLS LDP information in remote/local-mappings;
*) netinstall - added "-i <interface>" parameter for Netinstall (CLI Linux);
*) netinstall - improved automatic netbooting interface selection;
*) netwatch - added support for "https-get" type (CLI only);
*) ovpn - added "route-nopull" option for client side;
*) ovpn - added support for IPv6 tunnelling;
*) package - fixed missing menus when both "lora" and "wifiwave2" packages are installed;
*) ppp - fixed displaying of "info" command for PPP client;
*) ppp - improved authentication method negotiation;
*) sfp - added 2.5G SFP module support for RB5009;
*) ssh - added support for Ed25519 key exchange;
*) ssh - fixed handling of non standard size RSA keys;
*) switch - fixed egress mirror for 98DX4310 and 98DX8525 switches;
*) switch - fixed Ethernet monitor when disabling auto-negotiation for 10G interfaces for 98DX8212 switch (introduce in v7.7beta3);
*) switch - improved 10G, 25G and 40G interface stability for 98DX8208, 98DX8212, 98DX8332, 98DX3257, 98DX4310, 98DX8525, 98DX3255, 98DX8525, 98PX1012 switches;
*) switch - improved 25G interface stability for 98PX1012, 98DX4310 and 98DX8525 switches (introduced in v7.6);
*) swos - fixed "allow-from-ports" setting;
*) vpls - expose VPLS related debug logs to "vpls" logging topic;
*) w60g - improved system stability for Cube Pro devices;
*) webfig - fixed displaying of VRF routes;
*) webfig - properly show limited number of available options;
*) wifiwave2 - added "ft-preserve-vlanid" parameter to control whether to change VLAN ID after FT;
*) wifiwave2 - added initial CAPsMAN support (only compatible with wifiwave2 interfaces) (CLI only);
*) wifiwave2 - fixed "radio-mac" provisioning matcher;
*) wifiwave2 - fixed 4-way handshake with TKIP;
*) wifiwave2 - improved general system stability;

Posted: **Thu Nov 24, 2022 3:06 pm**

@emils: Could you please comment if scenario mentioned in SUP-27777 (CAPsMAN layer 3 provisioning rules don't work "out of the box" for new devices in CAPs mode) could be cared of with wifiwave2-CAPsMAN?

Posted: **Thu Nov 24, 2022 3:21 pm**

does beta 8 fix the ppp+queue related issue in this thread?

Posted: **Thu Nov 24, 2022 4:58 pm**

Hi, just noticed that on 7.7beta8 my DNS conditional forwarding config via REGEX stopped working. Please advice!

Posted: **Thu Nov 24, 2022 5:36 pm**

ssh - added support for Ed25519 key exchange;

While I am okay with RSA, I've been waiting for this for a long time to streamline part of my work. Thank you for adding support to ed25519 format.

Posted: **Thu Nov 24, 2022 5:41 pm**

Hi, just noticed that on 7.7beta8 my DNS conditional forwarding config via REGEX stopped working. Please advice!

Facing same regression.

add forward-to=10.39.1.51 regexp=".*\\.int\\.mydomain\\.com\$" type=FWD

Above rule non functional on beta8.

Downgraded to 7.7beta6, dns condtional forwarding operates again.

Posted: **Thu Nov 24, 2022 7:32 pm**

Try with this:

(^|\\.)int\\.mydomain\\.com\$

MikroTik

v7.7beta [testing] is released!

v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!

Re: v7.7beta [testing] is released!