v7.1rc5 [development] is released!

emils · Tue Oct 26, 2021 4:23 pm

RouterOS version 7.1rc5 has been released in public "development" channel!

What's new in 7.1rc5 (2021-Oct-25 20:15):

!) container - package is getting updated and will be made available in future, if interested in container feature please use 7.1rc4;
*) arm64 - fixed "total-sector-writes" resetting on each startup;
*) bgp - fixed IBGP nexthop selection;
*) bgp - fixed binding to IPv6 "link-local" address;
*) bgp - fixed missing default "local-pref" on selection;
*) bgp - fixed stability when appending extended communities;
*) bgp - improved stability and other minor fixes;
*) bonding - added warning when using 802.3ad mode without MII link monitoring;
*) bridge - added HW offload support for vlan-filtering on MT7621 switch chip (hEX, hEX S, RBM33G, RBM11G, LtAP);
*) bridge - fixed incorrect "hw=no" setting after reboot in rare cases;
*) bridge - improved MLAG stability;
*) capsman - do not include "access-list" passphrases in the output of export command by default;
*) certificate - added ability to choose the digest algorithm when generating a certificate;
*) chr - fixed FastPath support for VMXNET3 drivers;
*) dhcpv4 - fixed backslash prefix for packet logging;
*) dhcpv6-client - show correct DUID in print;
*) dhcpv6-server - fixed "address-pool" default value;
*) dhcpv6-server - fixed DUID generation with timestamp;
*) dns - fixed memory leak caused by large DNS replies;
*) gps - fixed built-in GPS functionality for LtAP;
*) health - fixed health value reporting on RB5009;
*) ipsec - enabled hardware acceleration support for ARM and ARM64 devices;
*) ipsec - fixed hardware acceleration support for CHR;
*) l3hw - fixed MTU on receive;
*) l3hw - fixed source MAC address usage for routed packets;
*) leds - adjust "system-led" color based on cellular connection technology on Chateau devices;
*) leds - fixed LED configuration on RB4011;
*) ltap - improved PCIe card support;
*) lte - added "at-chat" support in MBIM mode for Simcom modems in USB composition mode 9003;
*) lte - improved APN re-connection on non LTE networks;
*) lte - improved modem signal monitoring on Chateau 5G;
*) lte - moved notifications about incorrect responses from modem to 'lte' topic;
*) lte - properly show antenna selection on Chateau devices;
*) lte - request modem to restart registration process if timeout detected;
*) ospf - accept LA prefixes from intra-area router's LSA to the routing table;
*) mpls - added ICMP handler (send ICMP ttl exceed on MPLS ttl expiry);
*) ospf - allow to set IPv6 networks for "interface-template";
*) ospf - disable areas with no interface configuration;
*) ospf - do not allow to set "ptp-unnumbered" on IPv6 interfaces;
*) ospf - do not set empty filter chains when upgrading from v6;
*) ospf - improved stability and other minor fixes;
*) ospf - show interface's hello, re-transmit and dead intervals;
*) package - uninstall "container" package when downgrading to v6;
*) pppoe - fixed DHCPv6 PD;
*) quickset - added 5G signal quality information;
*) quickset - made "Password..." button work in Basic AP mode;
*) route - improved stability and other minor fixes;
*) route-filters - fixed "<=" and ">=";
*) route-filters - fixed "ext-community" problems;
*) route-filters - fixed "num range" matchers;
*) route-filters - fixed "route origin" matcher;
*) route-filters - improved completion;
*) route-filters - improved stability and other minor fixes;
*) rpki - added "rpki-query" command;
*) rpki - other minor fixes;
*) snmp - fixed IPsec-SA stats counter reporting;
*) snmp - fixed bulk get/walk with large neighbor version strings;
*) ssl - added support for additional GCM_SHA384 ciphers;
*) ssl - fixed x509 chain validation;
*) switch - fixed bogus statistics after RTL8367 switch reset;
*) system - improved DHCP and HotSpot service stability when shutting down;
*) system - improved system stability when downgrading to v6 with external disks attached;
*) tr069-client - improved compatibility for 5G;
*) traffic-flow - added systematic count-based packet sampling support;
*) user-manager - fixed "rate-limit-priority" parameter;
*) user-manager - fixed PEAP server authentication for Windows clients;
*) vrf - allow to assign interfaces directly along with interface lists;
*) vxlan - added default L2MTU value for improved connectivity in bridged setups;
*) vxlan - improved speed on MIPSBE devices;
*) wifiwave2 - fixed configuration profile renaming;
*) wifiwave2 - moved RADIUS accounting parameters to a separate configuration profile;
*) winbox - added "netmap" action to IPv6 NAT rules;
*) winbox - added IPv6 support for "Network" parameter under "Routing/OSFP/Interface Templates" menu;
*) winbox - added missing IPv6 mangle actions - "mark-routing", "sniff-tzsp", "sniff-pc", "snpt" and "dnpt";
*) winbox - added option to upgrade LTE firmware;
*) winbox - changed extension channel symbol to lower case for WifiWave2;
*) winbox - do not allow to set "memory-lines" parameter out of bounds under "System/Logging/Action" menu;
*) winbox - fixed "routing-mark" and "routing-table" selection in IPv4 and IPv6 firewall and route rules;
*) winbox - fixed private SSH key import;
*) winbox - made "0" the default value for GPS "init-channel" parameter;
*) winbox - made SSID field collapsible for WifiWave2;
*) winbox - moved "RPKI" tab from "Routing/BGP" to "Routing/RPKI" menu;
*) winbox - moved "Tables" tab from "IP/Route" to "Routing" menu;
*) winbox - moved all interface stats columns to the right;
*) winbox - properly load all backups stored in Cloud;
*) winbox - properly show "value" parameter for FWD type entries;
*) winbox - renamed "Backlight" to "OK" under "LCD/Backlight" menu;
*) winbox - renamed "Dst. Address" to "Route Dst." under "IP/Firewall/Mangle" menu;
*) winbox - replaced "routing-table" with VRF in traceroute;
*) winbox - show "External Antenna" parameter on all Chateau devices;
*) winbox - updated WifiWave2 interface fields and tabs;
*) wireguard - do not consider WireGuard interface as ethernet;
*) wireguard - improved system stability when sending WireGuard packets over EoIP;
*) wireless - adjusted antenna gain on Chateau devices;
*) wireless - improved system stability when changing L2MTU for wireless interfaces;
*) wireless - improved system stability when limiting link throughput via "ap-tx-limit" and "client-tx-limit" parameters;
*) wireless - improved system stability when using nv2 protocol on ipq4019 interfaces;

All released RouterOS v7 changelogs are available here:
https://mikrotik.com/download/changelog ... lease-tree

wispmikrotik · Tue Oct 26, 2021 4:28 pm

Perfect! thank you very much mikrotik!

Paternot · Tue Oct 26, 2021 4:41 pm

"bridge - added HW offload support for vlan-filtering on MT7621 switch chip (hEX, hEX S, RBM33G, RBM11G, LtAP);"

Excellent!

aliclubb · Tue Oct 26, 2021 4:44 pm

"bridge - added HW offload support for vlan-filtering on MT7621 switch chip (hEX, hEX S, RBM33G, RBM11G, LtAP);"

Excellent!

This = +1

bpwl · Tue Oct 26, 2021 4:47 pm

Yes!!! "*) user-manager - fixed PEAP server authentication for Windows clients;"
Thanks MT !

EDIT: ... but still don't get in with Windows 10 client.... viewtopic.php?p=887578#p887578

aliclubb · Tue Oct 26, 2021 4:49 pm

I don't suppose there is a rough ETA for the updated container package?

winap · Tue Oct 26, 2021 5:02 pm

Thank you MikroTik

pe1chl · Tue Oct 26, 2021 5:03 pm

Aha a nice changelog!
IPv6 netmap - that looks good!

added missing IPv6 mangle actions - "mark-routing", "sniff-tzsp", "sniff-pc", "snpt" and "dnpt";

How about "set priority"?

Any info on BFD (with BGP)? In which rc version will it be implemented?

anav · Tue Oct 26, 2021 5:06 pm

Wow, some nice features,
bridge - added HW offload support for vlan-filtering on MT7621 switch chip (hEX, hEX S, RBM33G, RBM11G, LtAP);
When will I get that for my CCR1009 (just kidding).

dns - fixed memory leak caused by large DNS replies;
I wonder how this bug showed up, random stuff that no one could pin down???

) ipsec - enabled hardware acceleration support for ARM and ARM64 device
Sweet.

*) wireguard - do not consider WireGuard interface as ethernet;
I dont understand?? I have RC4 wireguard and my wireguard interface DOES NOT SHOW UP under the Ethernet Tab (under Interface list).
It does show up as an entry under the general tab of INTERFACE as does an SSTP connection etc...................

*) wireguard - improved system stability when sending WireGuard packets over EoIP
What use case is there to use wireguard within an EoIP tunnel ??

hecatae · Tue Oct 26, 2021 5:13 pm

Chateau 5G updated without issue, thank you for the improvements.

hAP Lite updated as well.

bpbineesh · Tue Oct 26, 2021 5:17 pm

updated hapac3 without any issue

ffries · Tue Oct 26, 2021 5:32 pm

Working as expected, except for IPSEC client which is broken.

I noticed an IPSEC issue during upgrade on the CCR2004-1G-12S+2XS, and I hope that this is the right place to post:

IPSEC authentication is broken. I used diff tool to compare /export and it appears that this line was missing on RC5:

/ip ipsec identity
add auth-method=eap certificate="XXXXXXXXXXXXXXX CA" eap-methods=eap-mschapv2 generate-policy=port-strict mode-config=\
"XXXXXXXXXXXX mode config" peer="XXXXXXXXXXXXXX" policy-template-group=XXXXXXXXXX username=XXXXXXXXXXXXX

I could paste it from RC4 and everything was fine.

Update: The password was stripped also (which is a normal feature). Maybe this is why the /ip ipsec identity was not upgraded.
Just be aware that IPSEC will not be working after rc5 upgrade ...

winap · Tue Oct 26, 2021 5:37 pm

IPSEC authentication is broken

Did you have any issue with SW 7.0.5? Like speed, IPSec..?
I only want to know, what is better version for normal use..7.0.5 or 7.rc5?
Thank you

drasir · Tue Oct 26, 2021 5:37 pm

Ahh, why ist Container not included? Now i have to wait for RC6.. Damn!

MT giveth and MT taketh away...

deadkat · Tue Oct 26, 2021 6:17 pm

Never got an update to https://help.mikrotik.com/docs/display/ ... col+Status for RC4. Can we get one for RC5?

edit: I guess I was impatient....The page just got updated

GreySer · Tue Oct 26, 2021 7:07 pm

Ahh, why ist Container not included? Now i have to wait for RC6.. Damn!

MT giveth and MT taketh away...

+1 (

pe1chl · Tue Oct 26, 2021 7:32 pm

Tried to upgrade my hAP ac2 from 6.49 (separate packages: advanced-tools,dhcp,security,system,wireless) to 7.1rc5.
Uploaded routeros-7.1rc5-arm.npk to device via winbox, it shows up in the files section.
Rebooted device, first two log entries are:
system,info installed system-7.1rc5
system,error not enough space for upgrade
after that, the device is still running 6.49
/system resource print shows:
free-hdd-space: 2680.0KiB
total-hdd-space: 15.3MiB

rpingar · Tue Oct 26, 2021 7:35 pm

the bug about Intel 10G ports and bonding reported on ticket 61316 is not yet fixed in RC5:
we discovered two issue about bonding and 7.1rc4 on x86 and intel cards:
- first issue: After the reboot the phisical ports remain down
To have them working again you have to disable the bonding. As soon as you disable the bonding MT starts to report the ports UP and then eneable the bonding you have it working.
I am able to reproduce the issue also on a working bonding, where I disable one bonding interface, then reenable it, the port renabled doesn't go up in Running mode, the only way to have to port working again is to disable the bonding and reenable it.

- second issue seems related to "link monitoring=none", when there is the bonding in this config and I chanhe the remote side, for exemple changing the hash from l3/l4 to l2 the bonding stops to forward the traffic.
my workaround for this is to use linkmonitoring =mii on both side of the bonding (v6 is at the remote side).

infabo · Tue Oct 26, 2021 8:07 pm

*) leds - adjust "system-led" color based on cellular connection technology on Chateau devices;

Does this need some extra configuration? Is there a color->technology mapping?

*) wireless - adjusted antenna gain on Chateau devices;

How do I notice? It was antenna-gain=3 for 2.4ghz and antenna-gain=6 for 5ghz before. I see no change?

rushlife · Tue Oct 26, 2021 8:24 pm

installed on my rb5009, so far so good

mducharme · Tue Oct 26, 2021 8:32 pm

*) wireguard - do not consider WireGuard interface as ethernet;
I dont understand?? I have RC4 wireguard and my wireguard interface DOES NOT SHOW UP under the Ethernet Tab (under Interface list).
It does show up as an entry under the general tab of INTERFACE as does an SSTP connection etc...................

In rc4 and before the Wireguard interface was selectable as a bridge port - you could add it as a port on bridge, but it would not work since it is a layer 3 tunnel. Some forum users were trying to add the wireguard interface to the bridge and complaining that it was not working. Other layer 3 tunnel types (ex. GRE) do not show up in the list of possible bridge ports. I imagine this fix prevents Wireguard from being shown as a possible bridge port.

Tue Oct 26, 2021 9:00 pm

Upgraded 2 mAP Lites, 1 mAP and 1 Hex (all from 7.1rc4), no issues whatsoever.
1 SXT LTE still to do but someone 930km further South switched off the power for that device

In rc4 and before the Wireguard interface was selectable as a bridge port - you could add it as a port on bridge, but it would not work since it is a layer 3 tunnel. Some forum users were trying to add the wireguard interface to the bridge and complaining that it was not working. Other layer 3 tunnel types (ex. GRE) do not show up in the list of possible bridge ports. I imagine this fix prevents Wireguard from being shown as a possible bridge port.

Makes perfect sense.

ZupoLlask · Tue Oct 26, 2021 9:12 pm

LtAP mini (with R11e-LTE) never comes up ("not running" status) with v7.1rc5, even after configuration reset.

Sit75 · Tue Oct 26, 2021 9:20 pm

IPv6 over VDSL2 PPPoE with VLAN 848 (MTU > 1500) doesn´t work, unfortunately - hAP ac^2. No any active IPv6 connection. It is working fine on 6.49, but not on 7.1 RC5. I will have to rise a new ticket.

mducharme · Tue Oct 26, 2021 9:31 pm

Upgrade from 7.1rc4 resulted in losing all bridge ports on switch chip 2 only (ports 6-10), I had to re-add the ports.

ZupoLlask · Tue Oct 26, 2021 9:34 pm

Upgraded 2 mAP Lites, 1 mAP and 1 Hex (all from 7.1rc4), no issues whatsoever.
1 SXT LTE still to do but someone 930km further South switched off the power for that device

In rc4 and before the Wireguard interface was selectable as a bridge port - you could add it as a port on bridge, but it would not work since it is a layer 3 tunnel. Some forum users were trying to add the wireguard interface to the bridge and complaining that it was not working. Other layer 3 tunnel types (ex. GRE) do not show up in the list of possible bridge ports. I imagine this fix prevents Wireguard from being shown as a possible bridge port.
Makes perfect sense.

Are you sure you want to upgrade a device so far away from you?

Tue Oct 26, 2021 9:40 pm

Are you sure you want to upgrade a device so far away from you?

Normally I would not but this time risk is low.
I'll be on site 2 weeks from now and apart from some tenants next week who never had it before, nobody uses that internet access for now.
So next week power will be on again and then it's "play-time"

mhugo · Tue Oct 26, 2021 9:55 pm

Upgrading 2004s has given me lots of wierd issues over several beta and RCs. Just now 2 with rc5.

Seems like something is going on the L2 level - Romon is almost unreachable and everything is flapping.

After a few reboots they suddenly behave great.

Has anyone experienced something similar?

/Mikael

mducharme · Tue Oct 26, 2021 10:35 pm

I lost a whole bunch of random config and capsman was completely busted. I restored the .backup file I made in rc4 just before upgrade and everything is back again and fine now. I would recommend taking a backup just before upgrade just in case.

Znevna · Tue Oct 26, 2021 11:03 pm

*) bridge - added HW offload support for vlan-filtering on MT7621 switch chip (hEX, hEX S, RBM33G, RBM11G, LtAP);

I thought this required some driver change and wanted to test if the port/cpu lane was also fixed ( viewtopic.php?f=3&p=848197#p851031 )
And it seems it did, I only did a quick test between 1 (wan) and (2,3,4,5) bridged, seems better:

RB750Gr3 port tests.png

Thanks!
LE: voltage reading is still wrong on RB750Gr3:

/system/health/print 
Columns: NAME, VALUE, TYPE
#  NAME     VALUE  TYPE
0  voltage  0.5    V

OlofL · Wed Oct 27, 2021 12:38 am

Finally a good update! Lots of work in core protocols and core functionality and not much of the new fancy pancy toys

Wed Oct 27, 2021 12:42 am

*) chr - fixed FastPath support for VMXNET3 drivers;

CHR has FastPath ???

When did this happen!

Mikrotik, which drivers does this support ?

XaTTa6bl4 · Wed Oct 27, 2021 1:06 am

*) bridge - added HW offload support for vlan-filtering on MT7621 switch chip (hEX, hEX S, RBM33G, RBM11G, LtAP);

Does this mean that the information from wiki and below is incorrect?

mducharme · Wed Oct 27, 2021 1:18 am

I've confirmed that VPLS still crashes the device like it did in rc4.

mjbnz · Wed Oct 27, 2021 1:47 am

*) gps - fixed built-in GPS functionality for LtAP;

Confirmed that GPS data is now working from serial1, 115200 baud. Thank you!

Fesiitis · Wed Oct 27, 2021 2:07 am

Upgraded from v7.1rc4 to rc5 on RB5009, rebooted and I can't connect to VPN based on IKEv2 with RSA authentication anymore. Windows 10 gives an error "The error code returned on failure is 13816". Haven't tried with macOS. If that fails too, looks like I will have to visit a client in office anytime soon.

stathisch · Wed Oct 27, 2021 2:25 am

Is BGP over VRFs working properly now? Has someone tested it?

Referring to: viewtopic.php?t=179247

CTassisF · Wed Oct 27, 2021 4:36 am

*) dhcpv6-server - fixed "address-pool" default value;

I will finally be able to restore my full export.rsc without having to split it in two parts because of the historically missing address-pool default value.

vecernik87 · Wed Oct 27, 2021 6:46 am

*) bridge - added HW offload support for vlan-filtering on MT7621 switch chip (hEX, hEX S, RBM33G, RBM11G, LtAP);
Does this mean that the information from wiki and below is incorrect?

The info is indeed incorrect. You can confirm it easily by looking at specs
However, it is understandable - you are not going to say "yes, it has VLAN" when it is not supported by OS. That would be extremely confusing for everyone.

There was some theory about why Mikrotik did not support VLAN on this chip: viewtopic.php?p=740164#p740164

cklee234 · Wed Oct 27, 2021 6:59 am

I could not find container package from the release in mipsbe , x86/chr version

vecernik87 · Wed Oct 27, 2021 7:56 am

I could not find container package from the release in mipsbe , x86/chr version

That is expected. See the first line of the changelog:

!) container - package is getting updated and will be made available in future, if interested in container feature please use 7.1rc4;

Znevna · Wed Oct 27, 2021 8:25 am

IPv6 over VDSL2 PPPoE with VLAN 848 (MTU > 1500) doesn´t work, unfortunately - hAP ac^2. No any active IPv6 connection. It is working fine on 6.49, but not on 7.1 RC5. I will have to rise a new ticket.

Check yer routes. viewtopic.php?t=177800#p874200
Also hAP ac2 here, MTU > 1500 works fine. Not using VLAN though.

/interface/print
Flags: X, R - RUNNING; S - SLAVE
Columns: NAME, TYPE, ACTUAL-MTU
 #    NAME          TYPE       ACTUAL-MTU
 0 R  ether1        ether            1520
 8 R  pppoe-wan     pppoe-out        1500

colin · Wed Oct 27, 2021 8:49 am

Code: Select all
*) chr - fixed FastPath support for VMXNET3 drivers; 
CHR has FastPath ???

When did this happen!

Mikrotik, which drivers does this support ?

same question here.

elbob2002 · Wed Oct 27, 2021 9:13 am

Upgraded the following with no issues:

Chateau LTE12
RB3011
Hex 750Gr3
CRS-125-24G-1S
CRS-125-24G-1S-2HnD
CHR

No major issues on any of the devices. Modem Firmware on the Chateau through winbox worked perfectly.

Small issues - 750Gr3 still shows voltage incorrect.

ZupoLlask · Wed Oct 27, 2021 9:42 am

LtAP mini (with R11e-LTE) never comes up ("not running" status) with v7.1rc5, even after configuration reset.

Upgrading the modem's firmware, before upgrading LtAP mini firmware, did the trick for me.

After a downgrade back to v6.49 to be able to upgrade the firmware of R11e-LTE (from MikroTik_CP_2.160.000_v001) to MikroTik_CP_2.160.000_v018, the new upgrade to v7.1rc5 was smooth.

skylark · Wed Oct 27, 2021 10:52 am

Code: Select all
*) chr - fixed FastPath support for VMXNET3 drivers; 
CHR has FastPath ???

When did this happen!

Mikrotik, which drivers does this support ?

Its noted in the manual!

colin · Wed Oct 27, 2021 11:07 am

Code: Select all
*) chr - fixed FastPath support for VMXNET3 drivers; 
CHR has FastPath ???

When did this happen!

Mikrotik, which drivers does this support ?
Its noted in the manual!

nice.

erkexzcx · Wed Oct 27, 2021 11:19 am

OMG this beta release fixed SUP-44801 (Chateau 12 loses configuration on each reboot) issue!!!!!!!!!!!!!!

Glad I did not return this device to the seller for warranty reasons:)))

almeiras · Wed Oct 27, 2021 11:24 am

Ahh, why ist Container not included? Now i have to wait for RC6.. Damn!

MT giveth and MT taketh away...

So right... we'll have to wait. Let's hope they implement it back along with interactive terminal in RC6.

ZupoLlask · Wed Oct 27, 2021 11:31 am

OMG this beta release fixed SUP-44801 (Chateau 12 loses configuration on each reboot) issue!!!!!!!!!!!!!!

Glad I did not return this device to the seller for warranty reasons:)))

When did you have that issue? Only with firmwares v7.1*, I suppose...

erkexzcx · Wed Oct 27, 2021 11:44 am

I was unable to upgrade LTE firmware on my Chateau 12 v7.1rc5 CLI (rebooted and like nothing happened). https://wiki.mikrotik.com/wiki/Manual:I ... re_upgrade

However, it succeeded when using WinBox GUI, clicking on interfaces -> lte1 -> upgrade firmware. So in other words, all good.

erkexzcx · Wed Oct 27, 2021 11:48 am

OMG this beta release fixed SUP-44801 (Chateau 12 loses configuration on each reboot) issue!!!!!!!!!!!!!!

Glad I did not return this device to the seller for warranty reasons:)))
When did you have that issue? Only with firmwares v7.1*, I suppose...

I've had this since "18/Mar/21 3:12 PM" using beta 7.* and that's the time when I raised this ticket. I don't recall what ROS 7 version I used at that time. The storage issue seem to be appeared after sudden power loss and since then I was unable to use this device...

Time to time I've tried several ROS 7 betas and even 7.1 versions and I think I skipped previous version, but with this version this device seem to work just fine.

infabo · Wed Oct 27, 2021 12:19 pm

I was unable to upgrade LTE firmware on my Chateau 12 v7.1rc5 CLI (rebooted and like nothing happened). https://wiki.mikrotik.com/wiki/Manual:I ... re_upgrade

However, it succeeded when using WinBox GUI, clicking on interfaces -> lte1 -> upgrade firmware. So in other words, all good.

LTE firmware is updated directly when you hit it. You can follow the progress while updating. It needs no reboot.

ZupoLlask · Wed Oct 27, 2021 12:25 pm

When did you have that issue? Only with firmwares v7.1*, I suppose...
I've had this since "18/Mar/21 3:12 PM" using beta 7.* and that's the time when I raised this ticket. I don't recall what ROS 7 version I used at that time. The storage issue seem to be appeared after sudden power loss and since then I was unable to use this device...

Time to time I've tried several ROS 7 betas and even 7.1 versions and I think I skipped previous version, but with this version this device seem to work just fine.

Thank you!

StubArea51 · Wed Oct 27, 2021 2:02 pm

Code: Select all
*) chr - fixed FastPath support for VMXNET3 drivers; 
CHR has FastPath ???

When did this happen!

Mikrotik, which drivers does this support ?
Its noted in the manual!

This is awesome! Thank you!

nescafe2002 · Wed Oct 27, 2021 2:15 pm

I will finally be able to restore my full export.rsc without having to split it in two parts because of the historically missing address-pool default value.

Hah, thank you for this. I think I'm responsible for this change log entry.

It actually took two attempts to convince support: nov 2020 they didn't see any problem.
Sep 2021 tried again, provided a full repro (expected result vs. actual result) and they fixed it.

So, after all, if you take the time to contact support, make sure you provide a full repro and clear description of what you'd expect vs. what you get.

Wed Oct 27, 2021 2:39 pm

Code: Select all
*) chr - fixed FastPath support for VMXNET3 drivers; 
CHR has FastPath ???

When did this happen!

Mikrotik, which drivers does this support ?
Its noted in the manual!

Feature Request: Please add FastPath to igb, ixgbe, i40e and mlx5 drivers including the "virtual function" drivers.

CTassisF · Wed Oct 27, 2021 3:20 pm

So, after all, if you take the time to contact support, make sure you provide a full repro and clear description of what you'd expect vs. what you get.

I really thought it was the intended behavior, even though it did not make sense. That is why I didn't ever report this issue to them.

I'm glad they took the time to fix this now (thanks to your report)

CTassisF · Wed Oct 27, 2021 3:27 pm

v7.1rc5 broke /interface/wifiwave2/channel usage in wifiwave2 interfaces:

[cesar@MikroTik] > /interface/wifiwave2/channel/add name=foobar band=2ghz-n 

[cesar@MikroTik] > /interface/wifiwave2/channel/export 
# oct/27/2021 09:22:16 by RouterOS 7.1rc5
#
# model = RBD53iG-5HacD2HnD
/interface wifiwave2 channel
add band=2ghz-n name=foobar

[cesar@MikroTik] > /interface/wifiwave2/add name=wifi_foobar master-interface=wifi1 channel=foobar
input does not match any value of channel

This was working in v7.1rc4.

Usage in /interface/wifiwave2/configuration is still working fine:

[cesar@MikroTik] > /interface/wifiwave2/configuration/add name=foobar_config channel=foobar 

[cesar@MikroTik] > /interface/wifiwave2/configuration/export 
# oct/27/2021 09:25:26 by RouterOS 7.1rc5
#
# model = RBD53iG-5HacD2HnD
/interface wifiwave2 configuration
add channel=foobar name=foobar_config

Sit75 · Wed Oct 27, 2021 4:15 pm

IPv6 over VDSL2 PPPoE with VLAN 848 (MTU > 1500) doesn´t work, unfortunately - hAP ac^2. No any active IPv6 connection. It is working fine on 6.49, but not on 7.1 RC5. I will have to rise a new ticket.
Check yer routes. viewtopic.php?t=177800#p874200
Also hAP ac2 here, MTU > 1500 works fine. Not using VLAN though.
Code: Select all
/interface/print
Flags: X, R - RUNNING; S - SLAVE
Columns: NAME, TYPE, ACTUAL-MTU
 #    NAME          TYPE       ACTUAL-MTU
 0 R  ether1        ether            1520
 8 R  pppoe-wan     pppoe-out        1500

You were right. Problem has been solved with unchecking "Add default route" box in IPv6 DHCP Client section. Thank you.

rogerhung · Wed Oct 27, 2021 5:52 pm

I have upgraded rc4 to rc5 on ccr2004-16g-2s and everything looks normal.
But when the l2tp client wants to connect, all the LED lights on the machine seem to be off, I don’t know if it is, restart it?
And client failed to connect. When donwgrade to rc4, it returns to normal.

kaixinwang · Wed Oct 27, 2021 6:51 pm

Thank you MikroTik

Grant · Wed Oct 27, 2021 7:19 pm

Hi
I have a slow internet speed through wi-fi if fasttrack is disable on 7.1x
if fasttrack is enable i have 90/90
if fasttrack is disable i have 30/90

Through LAN i always have 90/90

this was not on version 6.4х

Device: hAP ac²

Wed Oct 27, 2021 8:14 pm

Re: v7.1rc5 [development] is released!

FYI:
October 27'th 2021 ( ROS version update notice ):
Today , I upgraded/replaced the public access Mikrotik CHR btest server today to Mikrotik's newest/latest ROS 7.1rc5 ( Development ) ROS version from the known/working ROS version stable 6.49

So far , this ROS 7.1rc5 ( Development ) ROS version appears to be running OK. If it has any problems , I will post my finding.

IPv4: 23.162.144.120
IPv6: 2605:6340:0:1b::4

btest username: btest
btest password: btest

Note; To use this Mikrotik public access btest server , you agree to the following terms and conditions:
#1 - You will not use or create any automatic btest scripts on a timed schedule to automatically perform btest(s) to this btest server.
#2 - You will not run extended btest(s) to this btest server which last longer than 30 seconds.
#3 - The use of this btest server is only permitted to perform brief 30-second btest(s).
#4 - You will never use this btest server to create a degrading bandwidth sustained load on your up-stream Internet provider.
#5 - You agree that I ( the owner/operator ) of this btest server may post your remote btest IP address(s) you used to test to my btest server.
#6 - All btest(s) you perform to this btest server will always be performed using a hands-on procedure without the use of any automated scripts.
#7 - You will never attempt a "dude" connection to this btest server.
#8 - You may perform up to 4 ( four ) btest(s) in a 24-hour period
#9 - You will pause a minimum of 5-minutes between btest(s)
#10 - Failure to follow the above listed requirements may result in actions on my part to permanently ban/block your IP addresses from my networks and this btest server.
#11 - I ask ( not required ) , that you post in this Mikrotik forum what country/city your are located in and your btest throughput results.
#12 - You understand these terms and conditions and you understand the purpose of this btest server is to assist all Mikrotik admins in determining the status/throughput capabilities of the networks they manage.
**** This btest server has the capabilities to perform brief btest(s) up to 4-Gig throughput

North Idaho Tom Jones

sutrus · Wed Oct 27, 2021 9:03 pm

Hello,
Can someone please confirm the problem on wifi 5Ghz under heavy load ( e.g. copying a larger file, iperf)
There is no disconnection from wifi, it just stops forwarding data.
Same problem on RC4 and RC5, firmware updated.

Mikrotik RB962UiGS-5HacT2HnT
Laptop Lenovo T580 Intel Wireless-AC 8265

Thank you

ivicask · Wed Oct 27, 2021 9:13 pm

Hello,
Can someone please confirm the problem on wifi 5Ghz under heavy load ( e.g. copying a larger file, iperf)
There is no disconnection from wifi, it just stops forwarding data.
Same problem on RC4 and RC5, firmware updated.

Mikrotik RB962UiGS-5HacT2HnT
Laptop Lenovo T580 Intel Wireless-AC 8265

Thank you

Check event viewer, do you see "LSO trigger" or lan module unload errors?Because i get them lately on 50+ various laptops and desktop boards on various Intel models and only with Mikrotik wifi...
Already reported to mikrotik this and they asked me for logs when it happens but havent got any more replies after that...
Also its not even related to v7, i get that on v6..

sutrus · Wed Oct 27, 2021 11:45 pm

OK thanks for the tip, but there is no LSO problem in the log.
I tested different settings and I think I found the problem.
After disabling WMM on 5Ghz wifi everything OK for now (I will still check)
On 2,4Ghz everything working fine with WMM on.

Edit: turning off WMM only improves the situation but does not solve the problem.

w0lt · Thu Oct 28, 2021 3:31 am

Can someone explain to me how PIM-SM works in ROS 7.1rc5 or..does it work at all?

I have used PIM in previous versions of ROS quite successfully but now it seems to have been rewritten in a different configuration that has no documentation available other than some vague place holders in the 7.1 wiki.
Any thoughts ??

Thanks,

-tp

ferilagi · Thu Oct 28, 2021 8:32 am

*) winbox - renamed "Dst. Address" to "Route Dst." under "IP/Firewall/Mangle" menu;

still Dst.Address in mine

nithinkumar2000 · Thu Oct 28, 2021 8:40 am

*) pppoe - fixed DHCPv6 PD;

What exactly is Fixed... Is it the issue with Radius not Recording PD.????

mducharme · Thu Oct 28, 2021 9:37 am

What exactly is Fixed... Is it the issue with Radius not Recording PD.????

I doubt it is the feature you (and me as well) are wanting. The RADIUS not recording prefix delegation is not a bug, it is the lack of a feature.

Grant · Thu Oct 28, 2021 9:41 am

OpenVPN still doesn't work

ZeeBOB · Thu Oct 28, 2021 12:47 pm

*) pppoe - fixed DHCPv6 PD;

Still not getting a prefix via DHCPv6-PD on a PPPoE interface on a VLAN

Was reported in 7.1rc4: viewtopic.php?t=178704#p881144
and here: viewtopic.php?t=177984

Any advice how to troubleshoot further?

borr · Thu Oct 28, 2021 12:57 pm

hap ac2, after upgrading to rc5 from rc4 wireguard peers lost ability to connect with ipv6, local clients can use ipv6 as before

after downgrading to rc4 with the same config everything run as it should be

msatter · Thu Oct 28, 2021 1:27 pm

*) winbox - renamed "Dst. Address" to "Route Dst." under "IP/Firewall/Mangle" menu;

still Dst.Address in mine

This is indeed a incorrect description. What happened is that the second Dst. Address in the list is being renamed to Route Dst. With V7.1RC the Dst.-Address was twice present in the list and this caused to crash Winbox or mess up your columns.

The correct description could be, *) winbox - renamed, extra "Dst. Address" to "Route Dst." under "IP/Firewall/Mangle" menu;
And because Route Dst. is only defined under Mangle it is only show there.

pe1chl · Thu Oct 28, 2021 1:54 pm

I tried to upgrade an RB4011 running 6.49 to this version. It has address list configuration like this:

/ip firewall address-list
add address=44.128.0.0/10 list=amprnet
add address=44.0.0.0/9 comment="AMPRnet (was 44.0.0.0/8)" list=amprnet
add address=0.0.0.0/8 list=bogons
add address=10.0.0.0/8 list=bogons
add address=100.64.0.0/10 list=bogons

(more items follow)
After the upgrade, the first item in this list was not present in the router. I could manually re-add it.

Edit: after looking at the export, it seems that the first address list item was in-place converted to a list=bgp-networks item. Other bgp-networks items were appended at the end of the address list. So after the conversion the first item in the address list was gone and replaced by the bgp-networks item.

nithinkumar2000 · Thu Oct 28, 2021 2:25 pm

I doubt it is the feature you (and me as well) are wanting. The RADIUS not recording prefix delegation is not a bug, it is the lack of a feature.

Did Anyone Tested it???

buset1974 · Thu Oct 28, 2021 9:03 pm

Cannot set Route Distinguisher on VRF.
VRF cannot work properly!

thx

infabo · Thu Oct 28, 2021 9:14 pm

*) leds - adjust "system-led" color based on cellular connection technology on Chateau devices;

*) wireless - adjusted antenna gain on Chateau devices;

Do I need to write support, to get additional context to these changes?

Thu Oct 28, 2021 9:20 pm

*) leds - adjust "system-led" color based on cellular connection technology on Chateau devices;

*) wireless - adjusted antenna gain on Chateau devices;
Do I need to write support, to get additional context to these changes?

That or waiting for documentation to get updated.

ffries · Thu Oct 28, 2021 9:58 pm

Upgraded from v7.1rc4 to rc5 on RB5009, rebooted and I can't connect to VPN based on IKEv2 with RSA authentication anymore. Windows 10 gives an error "The error code returned on failure is 13816". Haven't tried with macOS. If that fails too, looks like I will have to visit a client in office anytime soon.

See my post. IPsec VPN client is not being migrated and is missing the password. Could be a similar issue. Compare your export dumps.

evgenij · Thu Oct 28, 2021 10:11 pm

calculating download size... on my CHR

/system/package/update> download
channel: development
installed-version: 7.1rc4
latest-version: 7.1rc5
status: calculating download size...

anuser · Thu Oct 28, 2021 10:27 pm

I would like to request a separate smaller wifiwave2-package for cAP ac, hAP ac2, ... i.e. all devices with IPQ4018/IPQ4019 chipsets which could be possible:
* As the new combined wifiwave2 package contains several firmware files, libraries and linux kernel modules for different chipsets the file npk package is quite big. With its 10MB it is not possible to install it on current devices with 16MB of ROM, e.g. cAP ac, hAP ac2, new wAP ac, ... If you split that package you could also install on devices with 16 MB of ROM:
Image
* Regarding the RAM requirement, I have to note that my cAP ac device shows over 80 MB of free RAM, even when 30+ clients are concurrently connected. So I assume that there is plenty of RAM left for using the new wireless firmware and drivers on IPQ4018/IPQ4019 devices which have 128 MB of RAM installed. Has MikroTik tried to simply modprobe the inbuild modules for IPQ4018/IPQ4019 at all? What went wrong? Which limitation did appear?

bpwl · Fri Oct 29, 2021 1:42 am

calculating download size... on my CHR
/system/package/update> download
channel: development
installed-version: 7.1rc4
latest-version: 7.1rc5
status: calculating download size...

Had the same problem, removing the container package before download solved mine.

Fri Oct 29, 2021 4:35 am

re download size on chr

IMO - I suggest when spinning up a new CHR , prior to first CHR power-up -- always increase the hard disk size. I believe a CHR ( on VmWare ESXi ) can be sized to 16-Gig. Then on CHR first power up , it will auto resize the the CHR disk to properly use a larger disk. Thus , with a larger disk , you will likely never run out of disk space ( logs, graphing, scripts ... )

Fri Oct 29, 2021 7:32 am

v7.1rc5 broke /interface/wifiwave2/channel usage in wifiwave2 interfaces:

Thank you for the report. This will be fixed in the next release.

Fri Oct 29, 2021 9:30 am

Anyone else having trouble creating certificates in RouterOS v7.1rc5?
I create a CA certificate but cannot sign it.

Fri Oct 29, 2021 9:55 am

Anyone else having trouble creating certificates in RouterOS v7.1rc5?
I create a CA certificate but cannot sign it.

The changes in 7.1rc5 introduced an issue that causes a certificate to not be signed if the user does not explicitly specify the digest algorithm.
This will be addressed in the next release. For now, a workaround is to always specify the desired digest algorithm (the default is SHA256).

rushlife · Fri Oct 29, 2021 10:41 am

On RB5009 still quite unstable SFP port.

With original Mikrotik sfp modules or with mikrotik DAC, still "link downs" sometimes occured.

Sit75 · Fri Oct 29, 2021 12:26 pm

*) pppoe - fixed DHCPv6 PD;
Still not getting a prefix via DHCPv6-PD on a PPPoE interface on a VLAN

Was reported in 7.1rc4: viewtopic.php?t=178704#p881144
and here: viewtopic.php?t=177984

Any advice how to troubleshoot further?

I can confirm, it works. My problem/mistake was with checked "Add default route" on IPv6 DHCP client tab. Anyway, my working configuration looks like this:

/interface ethernet
set [ find default-name=ether1 ] mtu=1550

/interface vlan
add interface=ether1 mtu=1508 name=vlan-848 vlan-id=848

/interface pppoe-client
add add-default-route=yes disabled=no interface=vlan-848 max-mru=1500 max-mtu=1500 name=pppoe-out1 user=xxx

/interface list member
add interface=pppoe-out1 list=WAN

/ipv6 address
add from-pool=tmobile interface=bridge
/ipv6 dhcp-client
add interface=pppoe-out1 pool-name=tmobile request=prefix

/ipv6 nd
set [ find default=yes ] other-configuration=yes

Alter1000 · Fri Oct 29, 2021 5:08 pm

I'm having some troubles with OpenVpn, I'm not sure if it's a bug in this version or not

I'm using 7.1rc5 on a RB5009, and have the configuration coming from a working Hex running 6.49.

To make openvpn work I had to disable "Require Client Certificate". If it's enabled in the log I'm getting just
debug: <xx.xx.xx.xx>: disconnected <TLS failed>
with no details on the reason. I checked ca CRL and it's ok.

I think it's somehow related to certificates (I'm using the same working on 6.49, created with XCA) , but I see nothing useful in the logs.
I enabled certificate and openvpn logging, and checked my crl (seems to be ok).

EDIT: It was not a OpenVPN problem - leaving the question above in case it could be useful for someone having the same problem.

I had the clock still in 1/1/1970 after system reset .. ntp was not configured correctly. Fixed the clock, and openvpn is working again even with "Require Client Certificate".

Still I think there are some problems:
1) openvpn logging may benefit from some more descriptive errror, something like "client certificate not yet valid" in this case.
2) In the certificate section, expired certificates are flagged with "E". The same is not happening if the certificate is not yet valid.
In this case I had 2 certificates which looked good (no "E") , but where indeed invalid.
I think they should be flagged as well (maybe with a different letter for not yet valid certificates).

gumilev · Sat Oct 30, 2021 1:49 am

I have a slow internet speed through wi-fi if fasttrack is disable on 7.1x
if fasttrack is enable i have 90/90
if fasttrack is disable i have 30/90

Through LAN i always have 90/90

this was not on version 6.4х

Device: hAP ac²

I have had this problem on chateau 12 for a very long time. I wrote to support, provided access to the device, but they say that it is possible that the fault is in my LTE operator, in my tariff, in anything, but not in the device. Although they themselves say that without fasttrack, the processor should easily pull out such speed.
Here are my support videos. They don't see this as a problem.
https://youtu.be/y_6K_3qtIdw

chiem · Sat Oct 30, 2021 3:38 am

#11 - I ask ( not required ) , that you post in this Mikrotik forum what country/city your are located in and your btest throughput results.

Bay Area, CA. Reached 3.0 gbps up, 2.3 gbps down.

arfoll · Sat Oct 30, 2021 9:21 am

Anyone else having trouble creating certificates in RouterOS v7.1rc5?
I create a CA certificate but cannot sign it.
The changes in 7.1rc5 introduced an issue that causes a certificate to not be signed if the user does not explicitly specify the digest algorithm.
This will be addressed in the next release. For now, a workaround is to always specify the desired digest algorithm (the default is SHA256).

Thanks for the hint this works fine if you set a digest in the certificate template.

However the capsman certificate auto request doesn't work anymore, it says failure to sign certificate just like when there is no digest set in the template so I guess it's not working.

Grant · Sat Oct 30, 2021 4:05 pm

I have a slow internet speed through wi-fi if fasttrack is disable on 7.1x
if fasttrack is enable i have 90/90
if fasttrack is disable i have 30/90

Through LAN i always have 90/90

this was not on version 6.4х

Device: hAP ac²
I have had this problem on chateau 12 for a very long time. I wrote to support, provided access to the device, but they say that it is possible that the fault is in my LTE operator, in my tariff, in anything, but not in the device. Although they themselves say that without fasttrack, the processor should easily pull out such speed.
Here are my support videos. They don't see this as a problem.
https://youtu.be/y_6K_3qtIdw

this is a problem in firmware version 7.1x
because on version 6.4x there is no such problem
and I have not lte, but cable Internet

it feels like the shaper is turning on

this problem is both on the pc and on the phone

how can there be a reason in the operator if the problem is only with the Wi-Fi

bpwl · Sun Oct 31, 2021 11:10 am

Here are my support videos. They don't see this as a problem.
https://youtu.be/y_6K_3qtIdw

Well just some thoughts .... Slow download problem is quite common on internet (download is affected, upload is almost not affected).
There are quite some articles on this on the Internet. e.g. They also explain why upload congestion is causing download problems.
Getting full throughput through a (MT) tunnel with TCP is also a challenge.

Some relate this to congestion controls that suddenly kick in. A little timing difference (e.g. in the ACK) might be the cause of the congestion control kicking in.
And there are many different controls, and they change with the years: https://en.wikipedia.org/wiki/TCP_congestion_control
The congestion control is in the end device, not in the router, but the router queue's and timing, could make them act differently.
Windows is mostly on "Compound", Linux on "Cubic".

So changing from ethernet to wifi might be that little difference needed to make a major throughput reduction.

I saw tutorials where they insisted on rebooting the router after disable-ing the fasttrack, so that some extra FW rules disappeared. No idea if this is a requirement or not to avoid some delay or queue.

noradtux · Sun Oct 31, 2021 12:30 pm

hap ac2, after upgrading to rc5 from rc4 wireguard peers lost ability to connect with ipv6, local clients can use ipv6 as before

after downgrading to rc4 with the same config everything run as it should be

I think I am seeing something similar. I have a wireguard interface with two peers defined on it. I seems like only one of them will work at any given time. This setup was fine with rc4 on my rb5009.
Currently I created a second interface to handle the second peer, which works for now.

Sun Oct 31, 2021 12:43 pm

I think I am seeing something similar. I have a wireguard interface with two peers defined on it. I seems like only one of them will work at any given time. This setup was fine with rc4 on my rb5009.
Currently I created a second interface to handle the second peer, which works for now.

Server side, peer definition, allowed addresses: did you specify ip of wg on client side ?
Otherwise the interface does not know where to go to with multiple peers.

pe1chl · Sun Oct 31, 2021 1:00 pm

I am experimenting with v7.1rc5 on my RB4011. I have upgraded an existing config with 2 BGP instances and 5 active BGP peers.
After the upgrade 2 of the 5 peers are shown in red and when the config window is opened it shows "invalid" in the status bar.
I cannot find what is invalid for them. It looks like what they have in common is that the interface name is set as the update source, while the others have the IP address in that field. But when I change that in the invalid entries they do not become valid.
How do I proceed debugging that?
One of them is:

/routing bgp connection
add as=4220406101 connect=yes disabled=no hold-time=15s input.filter=\
    hamnet-in listen=yes local.address=l2tp-hamnet .role=ebgp .ttl=1 name=\
    gw-44-137-test nexthop-choice=force-self output.default-originate=\
    if-installed .filter-chain=hamnet-out .network=bgp-networks \
    remote.address=44.137.61.254 .as=4220406100 routing-table=ampr templates=\
    default

The logs show long streams of errors like this:
Oct/31/2021 12:44:15 route,bgp,info Write to bgp failed (9) { #buf=43 max=64 sk=Socket{ -1[0] } }
Oct/31/2021 12:44:15 route,bgp,info Write to bgp failed (9) { #buf=44 max=64 sk=Socket{ -1[0] } }
Oct/31/2021 12:44:15 route,bgp,info Write to bgp failed (9) { #buf=45 max=64 sk=Socket{ -1[0] } }

I presume that is related to it. Looks like bgp tries to write to a socket that is not connected? But I cannot find why it is not connected.
In an attempt to restart BGP I disabled and re-enabled the "templates" (that are the result of conversion of the "instances" in v6).
After that, these templates show as invalid as well.
The export of the templates is:

/routing bgp template
set default as=4220406101 disabled=no name=default output.network=bgp-networks routing-table=ampr
add as=65530 disabled=no name=bgp2 output.network=bgp-networks

What could be invalid about them?

Edit: after researching a bit more, it appears that the bgp configuration is not correctly configured. As I already mentioned above, the bgp-networks list is not correctly created, it overwrites the first existing address list item.
But also, it appears that peers that run over a network that is not part of bgp-networks are declared invalid.
Of course bgp-networks is the list of networks that is to be published by BGP, and the peering connections are not necessarily inside those networks!

noradtux · Sun Oct 31, 2021 1:17 pm

I think I am seeing something similar. I have a wireguard interface with two peers defined on it. I seems like only one of them will work at any given time. This setup was fine with rc4 on my rb5009.
Currently I created a second interface to handle the second peer, which works for now.
Server side, peer definition, allowed addresses: did you specify ip of wg on client side ?
Otherwise the interface does not know where to go to with multiple peers.

Allowed addresses are defined and don't overlap.

osc86 · Sun Oct 31, 2021 4:03 pm

I have migrated my home router from v6 to v7.1beta5 and noticed a few changes/problems.

- It seems ROS DNS server isn't responding to requests that origin from VRFs other than main. I haven't tested if that also applies to other services like ssh, www, etc., but from a security perspective this is a welcomed change. I have to find a solution for this, maybe use an external server. (I assume DoH & cond. FWD still can't be used together)
- Firewall Filter In / Out Interface, routing-table matcher doesn't work with interfaces that belong to a vrf.
- OSPFv2 isn't working, simple config, p2p link, no auth, stays in init state with openbsd neighbor, no errors in the (debug) log.
- Adding inter-vrf routes like described in the new wiki fails using winbox. Route immediately is inactive, unreachable. Adding them using the exact same parameters in cli works.
- ND isn't working on interfaces that belong to a vrf. Clients don't receive RA, devices are not shown in neighbor table. Probably wrong binding of daemon.
- Socks 5 proxy is broken, results in PR_END_OF_FILE_ERROR in firefox for secure connections; v4 works correctly.
- Winbox: IPv6/Route/Rules New Route doesn't show all available vrfs, only main.
- UPNP not working with vrf interfaces.

- IPv6 policy routing works correctly. (Thanks!)
- That long lasting bug where IPv6 connected routes randomly disappear for vrf-interfaces is fixed.

JoshDi · Sun Oct 31, 2021 4:48 pm

I have migrated my home router from v6 to v7.1beta5 and noticed a few changes/problems.

- It seems ROS DNS server isn't responding to requests that origin from VRFs other than main. I haven't tested if that also applies to other services like ssh, www, etc., but from a security perspective this is a welcomed change. I have to find a solution for this, maybe use an external server. (I assume DoH & cond. FWD still can't be used together)
- Firewall Filter In / Out Interface, routing-table matcher doesn't work with interfaces that belong to a vrf.
- OSPFv2 isn't working, simple config, p2p link, no auth, stays in init state with openbsd neighbor, no errors in the (debug) log.
- Adding inter-vrf routes like described in the new wiki fails using winbox. Route immediately is inactive, unreachable. Adding them using the exact same parameters in cli works.
- ND isn't working on interfaces that belong to a vrf. Clients don't receive RA, devices are not shown in neighbor table. Probably wrong binding of daemon.
- Socks 5 proxy is broken, results in PR_END_OF_FILE_ERROR in firefox for secure connections; v4 works correctly.
- Winbox: IPv6/Route/Rules New Route doesn't show all available vrfs, only main.

- IPv6 policy routing works correctly. (Thanks!)
- That long lasting bug where IPv6 connected routes randomly disappear for vrf-interfaces is fixed.

I am also having OSPF v2 issues with v7.1rc5 and previous versions. I dont ever get any neighbors after upgrading. I have tried to edit my configuration to get it to work, but nothing I do fixes it.

I have tried adding interface-templates by IP address range and by interface, but that doesnt solve the problem. Our auth-key is blank ("") but reading the v7 configuration, it says to omit it to replicate the same configuration in v7

interface-templates for interface:

/routing/ospf/interface-template/add area=backbone-v2 interfaces=mesh cost=10 type=ptmp priority=1 auth-id=1
/routing/ospf/interface-template/add area=backbone-v2 interfaces=nycmesh-SN3-L2TP-VPN cost=50 type=ptmp priority=1 auth-id=1

OR

interface-templates by IP address:

/routing/ospf/interface-template/add area=backbone networks=10.70.72.0/24 cost=50 type=ptmp priority=1 auth-id=1
/routing/ospf/interface-template/add area=backbone networks=10.70.91.0/24 cost=50 type=ptmp priority=1 auth-id=1
/routing/ospf/interface-template/add area=backbone networks=10.68.0.0/16 cost=10 type=ptmp priority=1 auth-id=1
/routing/ospf/interface-template/add area=backbone networks=10.69.0.0/16 cost=10 type=ptmp priority=1 auth-id=1

For v7.1rc5, how do we enable type-1 OSPF ext-type for connected routes? Is this command below correct for ospf-out and ospf-in filters?

/routing/ospf/instance/set default-v2 redistribute=connected
/routing/filter/rule/add chain=ospf-in rule="set distance 205; set bgp-communities 65000:110;"
/routing/filter/rule/add chain=ospf-out rule="if (dst in 10.70.72.1 && dst-len == 32) {reject}"
/routing/filter/rule/add chain=ospf-out rule="if (dst in 10.0.0.0/8 && dst-len in 18-32) {set ospf-ext-type type1; accept}"
/routing/filter/rule/add chain=ospf-out rule="if (dst in 0.0.0.0/0 || protocol connected) {set ospf-ext-type type1; accept}"

osc86 · Sun Oct 31, 2021 5:17 pm

/routing/filter/rule/add chain=ospf-out rule="if (dst in 0.0.0.0/0 || protocol connected) {set ospf-ext-type type1; accept}"

Be careful with that last rule, if I'm reading that correctly, you're exporting a default route.

dksoft · Sun Oct 31, 2021 5:19 pm

I have upgraded rc4 to rc5 on ccr2004-16g-2s and everything looks normal.
But when the l2tp client wants to connect, all the LED lights on the machine seem to be off, I don’t know if it is, restart it?
And client failed to connect. When donwgrade to rc4, it returns to normal.

I can confirm this on a CCR2004-1G-12S+2XS. The router is rebooting. Downgrade to rc4 fixed the problem.

JoshDi · Sun Oct 31, 2021 5:24 pm

/routing/filter/rule/add chain=ospf-out rule="if (dst in 0.0.0.0/0 || protocol connected) {set ospf-ext-type type1; accept}"
Be careful with that last rule, if I'm reading that correctly, you're exporting a default route.

Yes, that is similar to my v6.49 OSPF filter configuration.

Here are my OSPF filters for v6.49 currently (what I am trying to replicate in v7.1rc5):

[admin@nycmesh-177-sxtsq] > /routing ospf interface print 
Flags: X - disabled, I - inactive, D - dynamic, P - passive 
 #    INTERFACE                                                                              COST PRIORITY NETWORK-TYPE   AUTHENTICATION AUTHENTICATION-KEY
 0    mesh                                                                                     10        1 ptmp           none                             
 1    nycmesh-SN3-L2TP-VPN                                                                     50        1 ptmp           none                             
 
[admin@nycmesh-177-sxtsq] > /routing ospf instance print 
Flags: X - disabled, * - default 
 0  * name="default" router-id=10.69.1.177 distribute-default=never redistribute-connected=as-type-1 redistribute-static=no redistribute-rip=no 
      redistribute-bgp=no redistribute-other-ospf=no metric-default=500 metric-connected=20 metric-static=20 metric-rip=20 metric-bgp=auto 
      metric-other-ospf=auto in-filter=ospf-in out-filter=ospf-out 
      
[admin@nycmesh-177-sxtsq] > /routing filter print 
Flags: X - disabled 
 0   chain=ospf-in invert-match=no action=passthrough set-distance=205 set-bgp-prepend-path="" set-bgp-communities=65000:110 

 1   chain=ospf-out invert-match=no action=jump jump-target=meshaddrs set-bgp-prepend-path="" 

 2   chain=meshaddrs prefix=10.70.72.1 prefix-length=32 invert-match=no action=discard set-bgp-prepend-path="" 

 3   chain=meshaddrs prefix=10.0.0.0/8 prefix-length=18-32 invert-match=no action=accept set-bgp-prepend-path="" 

 4   chain=meshaddrs prefix=0.0.0.0/0 invert-match=no action=accept set-bgp-prepend-path="" 

 5   chain=meshaddrs invert-match=no action=discard set-bgp-prepend-path=""

Would this rule below only enable ospf type1 for connected routes?

/routing/filter/rule/add chain=ospf-out rule="if (protocol connected) {set ospf-ext-type type1; accept}"

Znevna · Sun Oct 31, 2021 6:15 pm

In RouterOS v6 if you remove all the IPv6 Firewall rules the filtering turns off or something because I'm getting ~700Mbps instead of ~300Mbps (with hAP ac2 or RB750Gr3) via IPv6.
This does not seem to be the case in RouterOS v7, even with everything removed from the IPv6 firewall I'm getting the same speeds as with the default firewall. (~300Mbps).
What's going on here?

gumilev · Sun Oct 31, 2021 11:56 pm

I saw tutorials where they insisted on rebooting the router after disable-ing the fasttrack, so that some extra FW rules disappeared. No idea if this is a requirement or not to avoid some delay or queue.

Support also told me that the rule will not take effect if you do not restart the device.
But the reboot did not affect my final speed measurement in any way. Only the video would be longer, no more changes

jookraw · Mon Nov 01, 2021 10:35 am

In RouterOS v6 if you remove all the IPv6 Firewall rules the filtering turns off or something because I'm getting ~700Mbps instead of ~300Mbps (with hAP ac2 or RB750Gr3) via IPv6.
This does not seem to be the case in RouterOS v7, even with everything removed from the IPv6 firewall I'm getting the same speeds as with the default firewall. (~300Mbps).
What's going on here?

Until IPv6 get some kind of hw acceleration support, this will be the norm.
the only method is brute-force (with a strong CPU), I had to go big with an RB4011 for my 1Gig/300m wan. I heard something about the lack of route cache on rOS v7
My hAP AC2 had one of its CPU cores maxed out at 300-400 IPv6 as all processes seems to share the same CPU core, not using the other ones.

Znevna · Mon Nov 01, 2021 10:39 am

hAP ac2 (I think all ipq401x) has another IPv6 bug, present in ROS6 too, all IPv6 traffic is processed on core3 which gets maxed out at 100% quickly, testing even with multiple TCP streams they don't get split across cores, on mmips (RB750Gr3) this doesn't happen, testing multiple streams you can see load on more than one core (valid on mmips).

Znevna · Mon Nov 01, 2021 11:09 am

And while talking about IPv6, I'll ask again about this: viewtopic.php?t=153437
Can/will something like this be implemented?
Because this, is bad (not the only thing that causes a prefix change, but just an example):

/ipv6/address/print where interface=bridge global=yes
0 G 2a02:yyy:xxx:c30c::8/64  wan1-pd    bridge     yes

 /interface/bridge/set [find where name=bridge] protocol-mode=none

/ipv6/address/print where interface=bridge global=yes
0 G 2a02:yyy:xxx:c30e::8/64  wan1-pd    bridge     yes

 /interface/bridge/set [find where name=bridge] protocol-mode=rstp

/ipv6/address/print where interface=bridge global=yes
0 G 2a02:yyy:xxx:c30f::8/64  wan1-pd    bridge     yes

And on clients while doing all that you end up with this:

Ethernet adapter Ethernet:
   [...]
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c300:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c302:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c303:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c305:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c306:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c307:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c308:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c309:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c30a:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c30b:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c30c:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c30d:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c30e:edited(Preferred)
   IPv6 Address. . . . . . . . . . . : 2a02:yyy:xxx:c30f:edited(Preferred)

infabo · Mon Nov 01, 2021 12:47 pm

rc5 is locking up quite often. I really dislike, that there is absolutely no way to debug these device hangups. On a regular Linux machine I can dig logfiles or dmesg to gather infos. But MT makes a secret of the underlying system. People are left in the rain. It is frustrating.

jookraw · Mon Nov 01, 2021 12:57 pm

rc5 is locking up quite often. I really dislike, that there is absolutely no way to debug these device hangups. On a regular Linux machine I can dig logfiles or dmesg to gather infos. But MT makes a secret of the underlying system. People are left in the rain. It is frustrating.

I'm having no locking up on any RB's that I own, both RB4011 and hAP ac2 with more than 5d of uptime, no issues

mducharme · Mon Nov 01, 2021 2:54 pm

 /interface/bridge/set [find where name=bridge] protocol-mode=none

I agree - changing something like the RSTP setting should not result in getting a new prefix from the pool.

infabo · Mon Nov 01, 2021 3:00 pm

It depends on your configuration. I am sure, my device would run with no issue in a more or less default configuration.

What I request as a feature: better debugging abilities. This RC won't leave RC state when this whole system is a blackbox and we "volunteers" can't collect ANY useful info we can hand over to support@mikrotik.com. It is completely useless to create a supout of a correctly runnimg system, send it to MT with the note: "just wait. Maybe happens. Maybe not". This is BS.

pe1chl · Mon Nov 01, 2021 3:08 pm

Code: Select all
 /interface/bridge/set [find where name=bridge] protocol-mode=none 
I agree - changing something like the RSTP setting should not result in getting a new prefix from the pool.

Such config changes result in a down/up action on the interface and thus in a new address assignment. But in such cases it should get the same address as before.
I have seen this same issue in v6 but I don't know if it was fixed. Normally I do not do such actions on operational routers. But in the past I have seen my LAN getting a different address after fiddling with interface settings.

Znevna · Mon Nov 01, 2021 3:10 pm

Code: Select all
 /interface/bridge/set [find where name=bridge] protocol-mode=none 
I agree - changing something like the RSTP setting should not result in getting a new prefix from the pool.

I think changing protocol mode triggers a switch reset on this device, and when it comes back the system treats it as a new interface and assigns the next unused(?) prefix.
Still, it would be nice to have the ability the specify what prefix to use on an interface, instead of assigning them incrementally.
@pe1chl beat me to it. ^^

siuswat · Mon Nov 01, 2021 4:12 pm

I have upgraded rc4 to rc5 on ccr2004-16g-2s and everything looks normal.
But when the l2tp client wants to connect, all the LED lights on the machine seem to be off, I don’t know if it is, restart it?
And client failed to connect. When donwgrade to rc4, it returns to normal.

I can confirm this on a CCR2004-1G-12S+2XS. The router is rebooting. Downgrade to rc4 fixed the problem.

Yes it is rebooted. My CCR2004-16G keeps rebooting itself within a minute after IPSec site to site tunnel is established on rc5.

nazimkhan10172 · Mon Nov 01, 2021 9:06 pm

Hi Glad too see more update is coming over ROS.7

Just i updated my x86-ROS6 to 7 because i installed intel X710 10G Card
Card is working fine
but now i am getting issue in CPU frequency its shows 1200mhz
but i am using Processor E5-2697V2

Can you please let me know will their will be soon update or we need to downgrade it
my cpu is restarting suddenly without reason and i found their much be some hardware not supporting in it

fflo · Tue Nov 02, 2021 7:55 am

Due to occasional hardware reboots on CCR2004-1G-12S+2XS gear I have upgraded to v7.1rc5.

It's been a mess of a few hours to update the configuration to match the new configuration style.

OSPFv2 is unstable communicating with Cisco ASR routers in case the broadcast network interface is using MD5 protection.
OSPFv3 is only working if I disable and re-enable the IPv6 interface address and then disable and re-enable the backbone-v3 OSPFv3 service.

Any hints are welcome on how to use CCR2004-1G-12S+2XS equipment without spontaneous watchdog reboots.

benoitc · Tue Nov 02, 2021 11:35 am

would be cool if you can upgrade the version of zerotier on next release. Right now the version provided for arm is 1.6.6. Where latest is 1.8.x. Also any idea how we can handle failover with it? I would like to be able to fail over LTE when the fiber connection is down.

pe1chl · Tue Nov 02, 2021 2:11 pm

More findings w.r.t. BGP (see viewtopic.php?p=888525#p888525 ):

- crossfig did not handle conversion of IBGP peers correctly. I had 2 peers with AS# 65530 and a BGP instance with that AS#. After conversion, the connections have .role=ebgp and are marked invalid, that is resolved by setting the role to ibgp. I think crossfig should do that.

- I regularly use EBGP over L2TP/IPsec. The central router has a subnet where the router itself has an address (on a bridge used as loopback) and each clients gets a fixed address based on PPP username.
BGP peers are defined at each end, with the router address of the other side (passive at the central router). This works fine in v6.
In v7, the connections fail with "route,bgp,info EBGP peer is not on a shared network and multihop is not configured". This is because in such a L2TP/IPsec setup the local address is a /32 and there is a /32 route towards the other side dynamically inserted in the routing table. So BGP sees this as 2 networks while in fact it is one network, and it isn't multihop. We need a workaround for this.

- as written before, it apears that crossfig overwrites the first ip address-list entry while converting bgp networks to a bgp-networks address list.

- there are many error messages like this:

Nov/02/2021 11:16:24 route,bgp,info Write to bgp failed (9) { #buf=2 max=64 sk=Socket{ -1[0] } }
Nov/02/2021 11:16:34 route,bgp,info Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 5[

Please add more info to these, like the bgp connection they are related to.

- it looks like crossfig does not convert "ip route rule" into "routing rule". or export does not export these (they do not appear in the v7 export)

scampbell · Tue Nov 02, 2021 9:09 pm

RB750UP (PowerBOX) still not upgrading POE F/W

Failed to upgrade poe FW on /dev/poe, diag code 80/0

mikegleasonjr · Tue Nov 02, 2021 9:17 pm

Please allow us to specify what kind of Cake queue we are creating, ingress or egress. It has been said lots of time by a lot of users please..

fflo · Wed Nov 03, 2021 4:03 am

Do you have a hint how to use the feature /routing/ospf/interface-template prefix-list for route filtering?
I did not succeed using the same syntax as instance in- and out-filters.

pe1chl · Wed Nov 03, 2021 1:06 pm

My internet connection uses PPPoE and for IPv6 I have to do a DHCPv6 prefix request to receive a /48 prefix and put it in a pool for local assignment.
That worked fine in v6 and it auto-adds two default routes, one is with the PPPoE interface as gateway (I think this one is added by the PPPoE client) and another one is with a gateway of fe80:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx%pppoe_interface which is added by the DHCPv6 client. That one is shown as inactive in v6 although it has the same distance (1) as the other route.

In v7 both routes are shown as active and IPv6 does not work. After I have changed the default-route-distance in the DHCPv6 client to 2, it now inserts that route at distance 2, it becomes inactive, and IPv6 routing now works.

It is probably best to include some workaround for this situation, either make inserting default route optional in the DHCPv6 client (as it is in IPv4 and PPPoE clients), or by increasing the default distance for the default route in the DHCPv6 client.

Znevna · Wed Nov 03, 2021 1:22 pm

I've mentioned this in v7.1rc1 topic viewtopic.php?t=177800#p874200
And the add default route for DHCPv6 client is optional, you can disable it.

pe1chl · Wed Nov 03, 2021 1:32 pm

More BGP observations/bugs (see viewtopic.php?p=888525#p888525 and viewtopic.php?p=888820#p888820 ):

- when a BGP peer was defined in v6 with update-source=interfacename, after conversion to v7 it has local.address=interfacename and it does not work. it logs messages like:

11:42:32 route,bgp,info Write to bgp failed (32) { #buf=1 max=64 sk=Socket{ 5[\00OUT] } } 
11:42:32 route,bgp,info Write to bgp failed (9) { #buf=2 max=64 sk=Socket{ -1[0] } }

after changing the local.address to the actual address of the interface, it works.

- the Peer Cache screen always shows 0 for the "Prefixes" and it lacks useful information like "uptime", "state", "used holdtime", etc. difficult to see if everything is working OK and remains so.

- BFD does not work. any ETA?

- crossfig does not convert route filter rules that refer to BGP AS-path. it simply drops them. the documentation of bgp-as-path filtering is unfinished and it is impossible to find using the auto-complete how to filter on an AS number at the front, the middle, or the end of the path. please update the documentation!

- the sequence shown in winbox for routing filter rules makes no sense. they should be ordered by rule number.

pe1chl · Wed Nov 03, 2021 1:37 pm

And the add default route for DHCPv6 client is optional, you can disable it.

Ok apparently only from cmdline, I do not see a checkmark or other gui trick for this (like removing default route distance) but in cmdline it worked.
So probably this requires only gui change. Thanks.

pe1chl · Wed Nov 03, 2021 1:47 pm

On RB4011, the selected and active CPU speed is no longer settable and visible (as it was in v6, did not try earlier v7 releases on this router).

pe1chl · Wed Nov 03, 2021 1:50 pm

Routing tables: as mentioned before, crossfig did not convert the ip route rule from v6 to v7, re-done them manually.
But, crossfig created these routing tables:

/routing table
add fib name=main
add fib name=""

(and others I have in my config)
The running system shows two tables named main, one is Dynamic. And a table with an empty name.
Is this correct and can one or more of those be deleted?

Znevna · Wed Nov 03, 2021 2:01 pm

And the add default route for DHCPv6 client is optional, you can disable it.
Ok apparently only from cmdline, I do not see a checkmark or other gui trick for this (like removing default route distance) but in cmdline it worked.
So probably this requires only gui change. Thanks.

DHCPv6 Client WinBox.JPG

DHCPv6 Client WebFig.JPG

aliclubb · Wed Nov 03, 2021 2:15 pm

On RB4011, the selected and active CPU speed is no longer settable and visible (as it was in v6, did not try earlier v7 releases on this router).

It's been like that in v7 forever from what I can remember.

pe1chl · Wed Nov 03, 2021 2:28 pm

DHCPv6 Client WinBox.JPGDHCPv6 Client WebFig.JPG

Arghh I completely overlooked that because winbox shows a window for IPv6 dhcp-client that is just a little too small and has this checkmark outside the visible area...
That is what you get when working too long on a router.
Well at least I now have RouterOS v7 in a state where I do not need to revert back to v6 after experiments to have a usable network.
(unfortunately the nasty DSCP problem I encountered with my RB4011 is not fixed in v7... could have been lucky)

theosoft · Wed Nov 03, 2021 2:42 pm

Fresh RB5009 with 7.1RC5 SW and FW.
Repartition doesn't work.

Am i wrong ??

regards....

OK. ARM64 seems not supporting this...

mkx · Wed Nov 03, 2021 2:52 pm

And the add default route for DHCPv6 client is optional, you can disable it.
Ok apparently only from cmdline, I do not see a checkmark or other gui trick for this (like removing default route distance) but in cmdline it worked.
So probably this requires only gui change. Thanks.

Looking at my 6.48.4 ... I can see that default value of add-default-route property in DHCPv6 client is "no" ... So it seems like 7.1rc changed default to yes?

pe1chl · Wed Nov 03, 2021 2:55 pm

Looking at my 6.48.4 ... I can see that default value of add-default-route property in DHCPv6 client is "no" ... So it seems like 7.1rc changed default to yes?

It looks like I have set it in v6, believing that this was a reasonable choice (or maybe copying it from someone else's example), but then it worked OK.
In v7 it no longer works when this option is active...

aliclubb · Wed Nov 03, 2021 4:19 pm

Fresh RB5009 with 7.1RC5 SW and FW.
Repartition doesn't work.

Am i wrong ??

regards....

OK. ARM64 seems not supporting this...

Do you have the container package installed? This causes re-partitioning to fail in my experience. I keep meaning to log a support issue but lazy/no time/pick my pathetic excuse.

aliclubb · Wed Nov 03, 2021 4:22 pm

Looking at my 6.48.4 ... I can see that default value of add-default-route property in DHCPv6 client is "no" ... So it seems like 7.1rc changed default to yes?
It looks like I have set it in v6, believing that this was a reasonable choice (or maybe copying it from someone else's example), but then it worked OK.
In v7 it no longer works when this option is active...

Probably haven't fixed/enabled the dynamic frequency support in v7 kernel for RB4011 CPU yet or something like that? It feels intentionally gone right now given that the option is missing too, but I'm sure it won't stay that way!

pe1chl · Wed Nov 03, 2021 4:42 pm

Probably haven't fixed/enabled the dynamic frequency support in v7 kernel for RB4011 CPU yet or something like that? It feels intentionally gone right now given that the option is missing too, but I'm sure it won't stay that way!

In RouterOS v6 there is no dynamic frequency support for the RB4011 (al2) either. But I had set the CPU to 800 MHz statically.
On the hAP ac2 (ipq4000L) the dynamic frequency support is available in v6. But I could not upgrade it to v7 yet (no space, maybe need to netinstall).

aliclubb · Wed Nov 03, 2021 6:11 pm

Probably haven't fixed/enabled the dynamic frequency support in v7 kernel for RB4011 CPU yet or something like that? It feels intentionally gone right now given that the option is missing too, but I'm sure it won't stay that way!
In RouterOS v6 there is no dynamic frequency support for the RB4011 (al2) either. But I had set the CPU to 800 MHz statically.
On the hAP ac2 (ipq4000L) the dynamic frequency support is available in v6. But I could not upgrade it to v7 yet (no space, maybe need to netinstall).

My bad, I thought it was. Too many devices, too much hardware, too much feature diversity. Keeping it all in ones head is a pain sometimes...

theosoft · Wed Nov 03, 2021 7:04 pm

Fresh RB5009 with 7.1RC5 SW and FW.
Repartition doesn't work.

Am i wrong ??

regards....

OK. ARM64 seems not supporting this...
Do you have the container package installed? This causes re-partitioning to fail in my experience. I keep meaning to log a support issue but lazy/no time/pick my pathetic excuse.

No, upgraded from 7.0.5 to RC5. Till now, container is missing for RC5

aliclubb · Wed Nov 03, 2021 7:19 pm

Do you have the container package installed? This causes re-partitioning to fail in my experience. I keep meaning to log a support issue but lazy/no time/pick my pathetic excuse.
No, upgraded from 7.0.5 to RC5. Till now, container is missing for RC5

My eyes read RC4, sorry 'bout that. Sounds like a bug then...

Fluke · Wed Nov 03, 2021 10:44 pm

How can one remove certain route?

Works on 6.48.x:

[admin@MikroTik] > ip route print 
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADS  0.0.0.0/0                          10.0.0.1                  1
 1  DS  0.0.0.0/0                          10.171.11.1              20
 [admin@MikroTik] > ip route remove 0

Fails on 7.1rc5:

[admin@MikroTik] > ip route/print 
Flags: D - DYNAMIC; A - ACTIVE; c, d, v, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS       GATEWAY      DISTANCE
DAv 0.0.0.0/0         10.0.0.1            1
D d 0.0.0.0/0         10.171.11.1        20
[admin@MikroTik] > ip/route/remove 0
no such item

pe1chl · Wed Nov 03, 2021 11:09 pm

You can only remove items that have a number in the first column. These D (dynamic) items cannot be removed.
You have to adjust the mechanism that adds them to the table. E.g. DHCP client, PPPoE client, etc.

rbngr · Fri Nov 05, 2021 2:35 am

IPv6 got another problem:

As soon as traffic flows through a queue the ipv6 firewall will drop that traffic as invalid

Kaldek · Fri Nov 05, 2021 5:21 am

Fresh RB5009 with 7.1RC5 SW and FW.
Repartition doesn't work.

Am i wrong ??

regards....

OK. ARM64 seems not supporting this...

Same issue here - fresh RB5009 upgraded to 7.1rc5 as soon as I had it connected to the Internet. Where did the statement about ARM64 not supporting partitions come from?

cohortcw · Fri Nov 05, 2021 5:58 am

Can anyone advise if Netwatch and web proxy tools (found in advanced-tools and system npk respectively) are available in v7.1rc5 release? I don't see the packages available for installation.

pe1chl · Fri Nov 05, 2021 10:39 am

Everything except the packages still shown available for v7.1 has been moved into one large routeros package.
So these things are still available, you can no longer opt to install them or not.
It was likely done to resolve many cross-dependencies between packages like security, ppp, dhcp etc.
But I still would have preferred it when "application" packages (that should not have other packages dependent on them) like web proxy, SMB server, Hotspot would have been kept separate.

cohortcw · Fri Nov 05, 2021 10:55 am

Everything except the packages still shown available for v7.1 has been moved into one large routeros package.
So these things are still available, you can no longer opt to install them or not.
It was likely done to resolve many cross-dependencies between packages like security, ppp, dhcp etc.
But I still would have preferred it when "application" packages (that should not have other packages dependent on them) like web proxy, SMB server, Hotspot would have been kept separate.

Many thanks for your inputs.

klatoszy · Fri Nov 05, 2021 2:01 pm

I was trying to establish encrypted vxlan over wireguard. Vxlan interface will never enter running state if parent is wiregaurd. Is that a bug or limitation?

Tested on 7.1rc5 between hap ac2 and CHR.

Halfeez92 · Fri Nov 05, 2021 2:05 pm

Where can I download the previous version of development channel build? I can't find it on the download archive page. It only have long-term and stable releases.

Fri Nov 05, 2021 2:12 pm

Where can I download the previous version of development channel build? I can't find it on the download archive page. It only have long-term and stable releases.

Copy download link and edit url.
Why would you use previous versions ? Unless it's for Container package ?

kujo · Fri Nov 05, 2021 2:40 pm

Hi!
I tested certificate gen. and seen that ca-crl-host don't copy to new signed certificates (like in v6)
version: 7.1rc5 (testing) build-time: Oct/25/2021 17:15:25
board-name: CHR platform: MikroTik

/certificate add common-name=CA digest-algorithm=sha512 key-usage=key-cert-sign,crl-sign,key-cert-sign name=CA state=UA
/certificate add name=server2 common-name=server2.local key-usage=digital-signature,data-encipherment,key-encipherment digest-algorithm=sha256 state=UA
/certificate sign CA ca-crl-host=192.168.88.18
/certificate sign server ca=CA ca-crl-host=192.168.88.18

Dear Mikrotik, will you fix this problem?

theosoft · Fri Nov 05, 2021 4:03 pm

Fresh RB5009 with 7.1RC5 SW and FW.
Repartition doesn't work.

Am i wrong ??

regards....

OK. ARM64 seems not supporting this...
Same issue here - fresh RB5009 upgraded to 7.1rc5 as soon as I had it connected to the Internet. Where did the statement about ARM64 not supporting partitions come from?

https://help.mikrotik.com/docs/display/ROS/Partitions .....
Maybe outdated, hopefully

Fri Nov 05, 2021 4:08 pm

https://help.mikrotik.com/docs/display/ROS/Partitions .....
Maybe outdated, hopefully

Something else wrong there too then (better worded: inconsistent)

Minimum partition sizes:

32MB on MIPS
40MB on PowerPC
48MB on TILE

But on Hex (which is MMIPS)

[xyz@MTHex] /partitions> print detail
Flags: A - active; R - running
0 AR name="part0" fallback-to=next version="RouterOS v7.1rc5 Oct/25/2021 17:15:25" size=16MiB

pe1chl · Fri Nov 05, 2021 4:28 pm

- MMIPS is not the same as MIPS
- the total size of flash is not the same as the minimal size of a partition (the systems with 16MB flash have some special handling for that)

Fri Nov 05, 2021 5:09 pm

- MMIPS is not the same as MIPS
- the total size of flash is not the same as the minimal size of a partition (the systems with 16MB flash have some special handling for that)

I know. But why am I able to get into that section and get out some details if it's not applicable ?
Not consistent.

mducharme · Sat Nov 06, 2021 4:53 am

Hello,

I believe I have found a bug with treatment of /routing/rules with min-prefix set. The documentation states:

min-prefix (integer [0..4294967295]) | Equivalent to Linux ip rule suppress_prefixlength . For example to suppress default route in routing decision set the value to 0.

However, setting 0 does not work, only setting 1 works to suppress default route in routing decision. The device seems to incorrectly treat 0 the same as unset and does not suppress the default route.

cohortcw · Sat Nov 06, 2021 4:55 am

Hi All,

I tried upgrading from v6.48.5 to v7.1rc5 on my RB4011 and everything went smoothly. Tested on my Wifi connected which is wired to UAP without issues. Same goes for my internet surfing and video streaming apps. However, I noticed something peculiar. See below for the images.

Screen Shot 2021-11-06 at 10.31.19 AM.png

Screen Shot 2021-11-06 at 10.33.32 AM.png

My access port ether2 seems to have issues with HW offload but not the rest. (Note that ether 3 thro ether 5 is not connected to any devices). Is it because that v7.1rc5 only allows one switch group to work in HW Offload mode but not both? Anyone has similar issues? Or is this an intended operation?

There are 2 switch groups, SW1 (ether1-5), SW2 (ether6-10)

mducharme · Sat Nov 06, 2021 4:59 am

There are 2 switch groups, SW1 (ether1-5), SW2 (ether6-10)

How many bridges do you have? I see your bridge is called BR1, do you have a BR2?

cohortcw · Sat Nov 06, 2021 5:19 am

Hi,
I actually have 2 bridges enabled. Is this the cause of the disabled HW offload?

Screen Shot 2021-11-06 at 11.16.51 AM.png

mducharme · Sat Nov 06, 2021 5:26 am

I actually have 2 bridges enabled. Is this the cause of the disabled HW offload?

It is the case in both RouterOS v6 and v7 that if you have more than one bridge on a device, only one bridge can have hardware offload (per switch chip). Therefore it is better to use bridge VLAN filtering and multiple VLANs instead of multiple bridges.

In your case you could alternatively disable hw-offload support for ether5 and then ether2-4 should suddenly become offloaded.

cohortcw · Sat Nov 06, 2021 5:28 am

Hi, mducharme
I just tried disabling my ether5 and ether2 HW offload turned active. So the HW offload is only meant to support one bridge due to RB4011 hardware limitations correct?

mducharme · Sat Nov 06, 2021 5:32 am

I just tried disabling my ether5 and ether2 HW offload turned active. So the HW offload is only meant to support one bridge due to RB4011 hardware limitations correct?

With all MikroTik devices, you can only have one bridge that is hardware offloaded per switch chip. In your case bridge1 was being hardware offloaded on the first switch chip so BR1 was not, but BR1 was being hardware offloaded on switch chip 2 because bridge1 does not exist there. This is not a difference between RouterOS v6 and v7, both have this limitation. If this only started in RouterOS v7, probably the order that the bridges were initialized changed in v7 so that bridge1 was initialized first and had hardware offloading enabled before BR1 started.

In your case you could disable hw-offload support for ether5 and then ether2-4 should suddenly become offloaded.

cohortcw · Sat Nov 06, 2021 5:34 am

I just tried your suggestion and it works beautifully. Many thanks mducharme!

syadnom · Sun Nov 07, 2021 10:19 pm

found a repeatable bug.

When hardware routing on NP16, all but one port in a bridge (ether2 removed from bridge), after a reboot hardware routing shows as up but wont route packets. Have to wait about a minute then disable and re-enable hardware routing.

I wasn't able to do any more troubleshooting on this because this is a 'production' site. It's a beta site, but I've reached the threshold of downtime I can put on these customers.

Unfortunately I haven't found any test that I can do on-device to see if the hardware routes are valid, so I can't automate a fix. Right now I'm just disabling hardware routing, doing 60 1 second interval pings, and then enabling hardware routing on the switch on startup as a workaround.

Kaldek · Mon Nov 08, 2021 9:26 am

The changes in 7.1rc5 introduced an issue that causes a certificate to not be signed if the user does not explicitly specify the digest algorithm.
This will be addressed in the next release. For now, a workaround is to always specify the desired digest algorithm (the default is SHA256).

I can confirm that in adding the option of "digest-algorithm=<value>" in my Certificate templates and then creating certificates based on that template, that IKEv2 based IPSec VPNs are working in 7.1rc5. This is on an RB5009.

emils · Mon Nov 08, 2021 12:41 pm

New version 7.1rc6 has been released in development RouterOS channel:

viewtopic.php?t=180153