v7.1beta6 [development] is released!

emils · Wed May 19, 2021 11:12 am

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

What's new in 7.1beta6 (2021-May-18 14:49):

!) added support for Let's Encrypt certificate generation;
!) added L3 HW support for all CRS3xx devices;
!) added MLAG support for CRS3xx devices (CLI only);
!) ported features and fixes introduced in v6.49;
*) other minor fixes and improvements;

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

Wed May 19, 2021 11:26 am

Here is the user guide on Layer 3 Hardware Offloading for CRRS3xx devices:
https://help.mikrotik.com/docs/display/ ... Offloading

parham · Wed May 19, 2021 11:39 am

no way!!!
!) added support for Let's Encrypt certificate generation;

Documentation pleaseeeee.

huntermic · Wed May 19, 2021 11:45 am

I'm a bit disappointed, would like to see more focus on stability and features that not in V7 but are available in V6 instead of brand new features.

parham · Wed May 19, 2021 11:48 am

no needed found it:
certificate/enable-ssl-certificate dns-name=

ufm · Wed May 19, 2021 11:53 am

!) added support for Let's Encrypt certificate generation;
!) added L3 HW support for all CRS3xx devices;
!) added MLAG support for CRS3xx devices (CLI only);

👍

Wed May 19, 2021 12:13 pm

I'm a bit disappointed, would like to see more focus on stability and features that not in V7 but are available in V6 instead of brand new features.

Are there known stability issues? AFAIK they are just waiting for routing protocols to be finished to move out of beta.
running a lot of beta5 at non-essential places, can't say that i'm having stability issues.

parham · Wed May 19, 2021 12:18 pm

Hey Mikrotik,

What a fantastic job on lets encrypt, well done.
very easy to generate, just need few more tweaks, can you please add a name during the setup as each time its generate new file. something like:

certificate/enable-ssl-certificate dns-name=vpn.abcd.xyz name=Certificate

also it will be good if we can add multi dns like:
certificate/enable-ssl-certificate dns-name=vpn.abcd.xyz,MT01.abcd.xyz,sstp.abcd.xyz name=Certificate

they you can just use certificate in where ever you need it and it will automatically renew the same file name.

right now if you rename it it will generate new names the below:
# NAME COMMON-NAME SUBJECT-ALT-NAME FINGERPRINT
0 KT Certificate vpn.abcd.xyz DNS:vpn.abcd.xyz 86d5977540a550d6b92d7777777777777777777
1 KT letsencrypt-autogen_2021-05-19T09:06:49Z vpn.abcd.xyz DNS:vpn.abcd.xyz af46ae12b3025900d6b94a444b948adc5418888888888888

aussetg · Wed May 19, 2021 12:23 pm

I'm a bit disappointed, would like to see more focus on stability and features that not in V7 but are available in V6 instead of brand new features.
Are there known stability issues? AFAIK they are just waiting for routing protocols to be finished to move out of beta.
running a lot of beta5 at non-essential places, can't say that i'm having stability issues.

Well Cake QoS crashes routeros but other than that it has been flawless for me. Well that and the CCR2004 has problems with mixed speeds SFPs but that's part of the 6.49 fixes :)

Now I'm only missing 4 addresses bridging mode on WifiWave2 to be perfectly happy :)

huntermic · Wed May 19, 2021 12:42 pm

I'm a bit disappointed, would like to see more focus on stability and features that not in V7 but are available in V6 instead of brand new features.
Are there known stability issues? AFAIK they are just waiting for routing protocols to be finished to move out of beta.
running a lot of beta5 at non-essential places, can't say that i'm having stability issues.

I don't know of any specific instabilities but have heard rumors in the past about some instabilities.
Personally I'm waiting for IGMP-Proxy to be implemented because without that ROS is useless for me, like it is for millions of other users in for instance the Netherlands like me that need this to be able to watch TV on a fiber connection.

xvo · Wed May 19, 2021 12:51 pm

From newly added part about L3 HW offloading on Marvell DX3000/2000 Series chips: https://help.mikrotik.com/docs/display/ ... Offloading

*1 Since total amount of routes that can be offloaded is very limited, prefixes with higher netmask are preferred to be forwarded by hardware (e.g /32 /30 /29 etc, last route is 0.0.0.0/0 always processed by CPU), any other prefix that does not fit in the HW table will be processed by the CPU.

Does this mean that even if there is only a limited amount of connected/static routes present, the default route will still be processed by CPU?
Or does it apply only for a situation when the total routes number exceeds the maximum?

Gooogast · Wed May 19, 2021 1:05 pm

MLAG support for CRS3xx devices (CLI only); - how to test it ?

mikegleasonjr · Wed May 19, 2021 1:06 pm

Well Cake QoS crashes routeros

Does it crashes this beta (beta6) as well?

Wed May 19, 2021 1:07 pm

From newly added part about L3 HW offloading on Marvell DX3000/2000 Series chips: https://help.mikrotik.com/docs/display/ ... Offloading
*1 Since total amount of routes that can be offloaded is very limited, prefixes with higher netmask are preferred to be forwarded by hardware (e.g /32 /30 /29 etc, last route is 0.0.0.0/0 always processed by CPU), any other prefix that does not fit in the HW table will be processed by the CPU.
Does this mean that even if there is only a limited amount of connected/static routes present, the default route will still be processed by CPU?
Or does it apply only for a situation when the total routes number exceeds the maximum?

Hi there,

The fallback to CPU applies only to a situation when the total number of routes exceeds the maximum. Otherwise, everything can be routed by the hardware, including the default gateway(-s).

kiler129 · Wed May 19, 2021 1:09 pm

I know it was said that there are no plans for AR9300 to be supported in WiFiWave2 package. However are there any plans of supporting running both wifiwave2 and the normal wireless package alongside?

While 2.4Ghz is far from amazing having to pick between good 5Ghz and no 2.4 at all vs 5Ghz limited by the driver and 2.4 is rather bad. There are a plethora of devices which don’t support 5Ghz (e.g. almost every IoT). Lack of support for 2.4 during 7 beta period is imho perfectly fine but leaving it like that is slightly worrisome.

anav · Wed May 19, 2021 1:21 pm

How are IP cloud names handled as wireguard endpoints? Are they like Firewall addresses that are resolved (dynamically) and checked/updated every xx seconds??

xvo · Wed May 19, 2021 1:27 pm

The fallback to CPU applies only to a situation when the total number of routes exceeds the maximum. Otherwise, everything can be routed by the hardware, including the default gateway(-s).

Great, thanks! That makes the huge new field of how to use the mentioned switches.

Probably you should rephrase the text in the wiki, so that this "always processed by CPU" don't raise any questions.

ErfanDL · Wed May 19, 2021 1:44 pm

why openwrt supported WPA3 on very old devices and WPA3 not supported in mikrotik devices ? like hAP lite, 951Ui,........ why ????????????

I installed openwrt 21.01 on tp-link W8970 ( 2013 Product ) and it's supporting WPA3, but in mikrotik...... LMAO :))

Wed May 19, 2021 1:54 pm

Because RouterOS is made for all devices, but your example with OpenWRT is compiled specifically for one product only.
Until RouterOS doesn't have NPK file for each model separately, it will always be bigger, as it has more drivers inside.

Wed May 19, 2021 1:56 pm

The fallback to CPU applies only to a situation when the total number of routes exceeds the maximum. Otherwise, everything can be routed by the hardware, including the default gateway(-s).
Great, thanks! That makes the huge new field of how to use the mentioned switches.

Probably you should rephrase the text in the wiki, so that this "always processed by CPU" don't raise any questions.

The documentation has been updated.

Thanks for the feedback!

Wed May 19, 2021 1:59 pm

I know it was said that there are no plans for AR9300 to be supported in WiFiWave2 package. However are there any plans of supporting running both wifiwave2 and the normal wireless package alongside?

There are no plans to support running both packages at the same time, no.
The wifiwave2 package beta is offered as a preview of wireless functionality developed for future products. For currently available products, the regular wireless package is still being maintained and improved.

NeoPhyTex360 · Wed May 19, 2021 2:04 pm

Is cake crashing RoS with beta6?

ErfanDL · Wed May 19, 2021 2:08 pm

Because RouterOS is made for all devices, but your example with OpenWRT is compiled specifically for one product only.
Until RouterOS doesn't have NPK file for each model separately, it will always be bigger, as it has more drivers inside.

So do we have any chance to get wpa3 on older devices with 2.4GHz ?

Wed May 19, 2021 2:09 pm

FToms already answered this above

jimmer · Wed May 19, 2021 2:14 pm

Release notes end with:

other minor fixes and improvements;
Is there an elaboration on what those fixes are?

Is one of those fixes OpenVPN Server in UDP mode?

On 7.1b5 I noticed OpenVPN in UDP mode would randomly stop moving packets after an hour or two despite everything looking like it was connected perfectly. the same behaviour didn't happen with the TCP mode on 7.1b5 (as per previous RouterOS versions) - this was on the RB750Gr3 - I've just upgraded to a RB3011 and will try again and report back.

Appreciate all the hard work that's gone into the 7.1 development tree!

Kind Regards,
Jim.

OlofL · Wed May 19, 2021 2:20 pm

I'm a bit disappointed, would like to see more focus on stability and features that not in V7 but are available in V6 instead of brand new features.

Totally agree. Also it would be interesting in seeing progress on protocols here: https://help.mikrotik.com/docs/display/ ... col+Status
Im sure there is a lot of work behind the scenes that doesnt show up in the changelogs. But just looking at changelog from beta5 to beta6, there isnt much progress.

Wazza · Wed May 19, 2021 2:51 pm

!) added MLAG support for CRS3xx devices (CLI only);

Any doco on this? This is a LONG awaited feature...

jimmer · Wed May 19, 2021 3:00 pm

Trying to perform a downgrade on 7.1b6 on an RB3011 results in this appearing on the serial console:

system will reboot shortly

Rebooting...
[ 746.341100] Internal error: Oops: 17 [#1] SMP ARM
[ 746.341143] CPU: 1 PID: 298 Comm: sysinit Not tainted 5.6.3 #60
[ 746.344785] Hardware name: RB3011
[ 746.350515] PC is at _stext+0x2c610/0x4338e8
[ 746.353985] LR is at _stext+0x2c5c8/0x4338e8
[ 746.358324] pc : [<8012c610>] lr : [<8012c5c8>] psr: 60000093
[ 746.362580] sp : bab9dbb8 ip : 00000000 fp : 00000000
[ 746.368568] r10: 8087d23c r9 : 00000004 r8 : 8087d23c
[ 746.373776] r7 : ba9d1900 r6 : 00000001 r5 : bcabfe00 r4 : 00000000
[ 746.378989] r3 : 00000001 r2 : 00000001 r1 : 07ffffff r0 : 00000000
[ 746.385585] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment non
e
[ 746.392097] Control: 10c5787d Table: 7a9b406a DAC: 00000051
[ 746.399300] Process sysinit (pid: 298, stack limit = 0x29cb3e70)
[ 746.405122] {bab9dbe4} _stext+0x2c820/0x4338e8
[ 746.411211] {bab9dbfc} switch_switchdev_event+0x1cc/0x244 [switch@0x7f0e9000]
[ 746.415456] {bab9dc1c} _stext+0x32ab4/0x4338e8
[ 746.422651] {bab9dc3c} _stext+0x32c70/0x4338e8
[ 746.426990] {bab9dc4c} _stext+0x32c8c/0x4338e8
[ 746.431446] {bab9dc5c} br_switchdev_fdb_notify+0xbc/0xc4 [bridge2@0x7f0f7000]
[ 746.435868] {bab9dc74} br_fdb_find_port+0x73c/0xdb0 [bridge2@0x7f0f7000]
[ 746.443070] {bab9dc9c} br_fdb_find_port+0xa88/0xdb0 [bridge2@0x7f0f7000]
[ 746.449839] {bab9dd84} br_fdb_delete_by_port+0x88/0xb4 [bridge2@0x7f0f7000]
[ 746.456522] {bab9dda4} br_device_event+0x1b0/0x1dc [bridge2@0x7f0f7000]
[ 746.463195] {bab9ddc4} _stext+0x32ab4/0x4338e8
[ 746.469784] {bab9dde4} _stext+0x32d28/0x4338e8
[ 746.474299] {bab9ddf4} _stext+0x36124c/0x4338e8
[ 746.478727] {bab9de04} _stext+0x366d54/0x4338e8
[ 746.483154] {bab9de24} _stext+0x3673d0/0x4338e8
[ 746.487665] {bab9de3c} _stext+0x3e44c8/0x4338e8
[ 746.492182] {bab9de8c} _stext+0x3e66ac/0x4338e8
[ 746.496696] {bab9def4} _stext+0x3490fc/0x4338e8
[ 746.501208] {bab9df34} _stext+0xdd9cc/0x4338e8
[ 746.505723] {bab9df3c} _stext+0xdded0/0x4338e8
[ 746.510235] {bab9dfa4} _stext+0x1000/0x4338e8
[ 746.514662] Exception stack(0xbab9dfa8 to 0xbab9dff0)
[ 746.519109] dfa0: 7efffbd0 0002d390 00000003 00008914 7efff
b88 7efffb18
[ 746.524156] dfc0: 7efffbd0 0002d390 00000002 00000036 00000001 00000003 00000
000 00000000
[ 746.532302] dfe0: 0002d018 7efffb00 00015410 76fced14
[ 746.540463] Code: 01a04003 0a000003 e1a0000b ebfffcd0 (e5940000)
[ 746.545486] ---[ end trace 9851032d4f912bef ]---
[ 746.552560] Kernel panic - not syncing: Fatal exception in interrupt
[ 746.556261] CPU0: stopping
[ 746.562580] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D 5.6.3 #
60
[ 746.565098] Hardware name: RB3011
[ 746.572304] {80901f04} _stext+0x97a4/0x4338e8
[ 746.575775] {80901f0c} _stext+0x420060/0x4338e8
[ 746.580118] {80901f1c} _stext+0xbef0/0x4338e8
[ 746.584455] {80901f34} _stext+0x1b348c/0x4338e8
[ 746.588970] {80901f4c} _stext+0x1acc/0x4338e8
[ 746.593308] Exception stack(0x80901f50 to 0x80901f98)
[ 746.597836] 1f40: 008ca8d0 00000000 008ca
8d0 801142a0
[ 746.602888] 1f60: 80900000 00000001 80903e24 80903e60 80824a38 512f04d0 10c53
87d 00000000
[ 746.611040] 1f80: 00000000 80901fa0 80106f60 80106f50 60000013 ffffffff
[ 746.619182] {80901f9c} _stext+0x6f50/0x4338e8
[ 746.625602] {80901fa4} _stext+0x3a0d8/0x4338e8
[ 746.630116] {80901fbc} _stext+0x3a368/0x4338e8
[ 746.634457] {80901fc4} _sinittext+0x934/0x20d80
[ 746.650717] flash_ioctl: programming injected settings id 8
[ 746.686565] spi_program_sector 00000020

after further investigation it looks like it kernel panics on every reboot before it shows the boot loader.

Edit: from the console logs on first login:

may/19/2021 21:42:10 system,error,critical kernel failure in previous boot
may/19/2021 21:54:50 system,error,critical kernel failure in previous boot
may/19/2021 21:58:20 system,error,critical kernel failure in previous boot

aussetg · Wed May 19, 2021 3:01 pm

Well Cake QoS crashes routeros
Does it crashes this beta (beta6) as well?

I haven't tested yet. I will when I'm back home tomorrow.

dacoshild · Wed May 19, 2021 3:50 pm

My OSPF stoped working after upgrade. When I downgrade back to 7.1beta5 it works again.

StubArea51 · Wed May 19, 2021 3:58 pm

Thanks for the new features like MLAG!

Were the issues with OSPFv3 checksum fixed?

rpingar · Wed May 19, 2021 4:20 pm

issues found (X86):
- winbox crashes opend the window about ipv6 bgp peer
- ip route crashes loading the fullroute where there are routes with big communities
- routing filter rules still not finished, they miss all the action about set bgp (so not all routing filter roules are ported from v6 backup)
- rpki session stays in connecting state
- router configuration about osfp is not ported from v6

regards
Ros

Manfred · Wed May 19, 2021 4:21 pm

There seems to be a bug with the MTU - Size in bridge - generation.
After generating a new bridge and adding the first port ( Ethernet ) to it, the wrong MTU - size is used.
It seems, the L2 MTU ( 1598 ) instead of the real MTU ( 1500 ) is used as MTU for the bridge !

To fix this, the MTU of the Ethernet Port has to be changed and put back to 1500.
After that, the bridge uses the correct MTU too.

anuser · Wed May 19, 2021 4:23 pm

RouterOS version 7.1beta5 has been released in public "development" channel!
*) wifiwave2 - improved interface stability with multiple WPA3 authenticated clients;

I would like to request a separate wifiwave2 package for IPQ4018/IPQ4019 devices with 16MB of ROM. With such a package a lot of more users could test this it, send feedbacks and bug reports which will result in an earlier available bugfree stable release.

jookraw · Wed May 19, 2021 4:37 pm

My OSPF stoped working after upgrade. When I downgrade back to 7.1beta5 it works again.

.
this also happened to me, I found that if the config for interface templates looks like this, it will not work:

/routing ospf interface-template
add area=ospf-area-0 interfaces=ovpn-in1,ovpn-in2 networks="" type=ptp
add area=ospf-area-0 interfaces=OSPF_vlan networks=""

.
removing the networks= fixed for me:
.

/routing ospf interface-template
add area=ospf-area-0 interfaces=OSPF_vlan
add area=ospf-area-0 interfaces=ovpn-in1,ovpn-in2 type=ptp

Cablenut9 · Wed May 19, 2021 4:52 pm

I just noticed that MPLS is back in Winbox! Also, I keep getting crashes with L2TP and Android 11.

dacoshild · Wed May 19, 2021 5:23 pm

My OSPF stoped working after upgrade. When I downgrade back to 7.1beta5 it works again.
.
this also happened to me, I found that if the config for interface templates looks like this, it will not work:
Code: Select all
/routing ospf interface-template
add area=ospf-area-0 interfaces=ovpn-in1,ovpn-in2 networks="" type=ptp
add area=ospf-area-0 interfaces=OSPF_vlan networks=""
.
removing the networks= fixed for me:
.
Code: Select all
/routing ospf interface-template
add area=ospf-area-0 interfaces=OSPF_vlan
add area=ospf-area-0 interfaces=ovpn-in1,ovpn-in2 type=ptp

Thank you! It really worked. Do you know if it is already possible to set costs for OSPF?

wispmikrotik · Wed May 19, 2021 5:37 pm

What's new in 7.1beta6 (2021-May-18 14:49):

!) ported features and fixes introduced in v6.49;

All the features of v6.49beta46?

Regards,

mfrey · Wed May 19, 2021 5:59 pm

My hAP ac3 hasn't crashed after setting cake as my download qeue type in queue tree so far, so that's an improvement.

VRF (with a VLAN and a WireGuard interface) still doesn't work and leads to WinBox crashing when showing IP -> Routes.

Wed May 19, 2021 6:34 pm

Do you know if it is already possible to set costs for OSPF?

Yes, now you can set cost in interface template

muetzekoeln · Wed May 19, 2021 6:47 pm

I would like to request a separate wifiwave2 package for IPQ4018/IPQ4019 devices with 16MB of ROM. With such a package a lot of more users could test this it, send feedbacks and bug reports which will result in an earlier available bugfree stable release.

+1

anav · Wed May 19, 2021 6:51 pm

My hAP ac3 hasn't crashed after setting cake as my download qeue type in queue tree so far, so that's an improvement.

VRF (with a VLAN and a WireGuard interface) still doesn't work and leads to WinBox crashing when showing IP -> Routes.

mfry i have wireguard working with vlans but dont use VRF on beta5. Assuming same for beta6

khialb32 · Wed May 19, 2021 8:16 pm

Guys, could any one of you use the hotspot feature, I tried many things and it doesn't seem to respond. ( used beta 5 and now trying on beta 6 and nothing yet)

now it is working, the problem i had is that DHCP add arp for leases didn't work with reply only on the interface of the hotspot, i changed to proxy-arp and its working!

hknet · Wed May 19, 2021 8:47 pm

Mmmm MLAG - sounds tasty.

Any hint on how this could be configured and how it is implemented between boxes?

thx!

mafiosa · Wed May 19, 2021 9:17 pm

is ospf and ospfv3 working?

ksteink · Wed May 19, 2021 10:37 pm

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

What's new in 7.1beta6 (2021-May-18 14:49):

!) added support for Let's Encrypt certificate generation;
!) added L3 HW support for all CRS3xx devices;
!) added MLAG support for CRS3xx devices (CLI only);
!) ported features and fixes introduced in v6.49;
*) other minor fixes and improvements;

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

For the L3 HW off-load support on CRS3xx can you confirm if that includes even the CRS305 model?

dave864 · Wed May 19, 2021 10:52 pm

I know it was said that there are no plans for AR9300 to be supported in WiFiWave2 package. However are there any plans of supporting running both wifiwave2 and the normal wireless package alongside?
There are no plans to support running both packages at the same time, no.
The wifiwave2 package beta is offered as a preview of wireless functionality developed for future products. For currently available products, the regular wireless package is still being maintained and improved.

@normis mk messaging is not clear about this. What is clear is that wifiwave2 will not come to old products.

MK will not support both packages running in v7 - I guess this is what is meant?
MK will not back port wpa3 to the old v6 wi-fi package but that package is still actively maintained, for now - am I correct?

Please be clearer. That is why we keep banging on about all this. Just give us clear messaging. I'm sure you're just as tired of this merry-go-round as we are.

Finally, consider releasing a self downloadable module, for unsupported for old CAPac.

doneware · Wed May 19, 2021 11:03 pm

can't wait to see this bad boy: crs520-4xs-16xq

Chupaka · Wed May 19, 2021 11:16 pm

In Winbox -> Check for Updates, the changelog for this version is empty, all other channels show their changelogs correctly:

Screenshot 2021-05-19 at 23.12.25.png

amix · Wed May 19, 2021 11:18 pm

routing filters still dont working
now bgp dont send anything (sending all networks in rt in beta5)

aussetg · Wed May 19, 2021 11:46 pm

Just noticed there's a 7.1beta6 TheDude's client, it's new ? :)

The CHR version seems completely broken. My router is up, I guess, but it responds to ping only 20% of the tine, lot of packet loss and I'm unable to connect to it.

EDIT: I found the problem and it's not CHR related. When upgrading from beta5 to beta6 OSPF interface-templates lose the interface=SOMETHING restriction and start advertising EVERYTHING. Including the WAN. And routing goes crazy and flaps.

thadrumr · Thu May 20, 2021 1:31 am

The issue with FQCODEL iss still happening with 7.1beta6. I have a verry simple queue setup with FQCODEL on my LAN interface with download of 225M and upload of 12M. Shortly after enabling the queue I got a reboot with and error in the logs stating a kernel failure in previous boot. When I change the queue to use CAKE I am for the moment not getting a kernel failure reboot and getting good resultes on the dslreports speedtest.

Well guess that was short lived even with CAKE it last longer but I still get a kernel failure after being up for not even an hour.

mducharme · Thu May 20, 2021 2:36 am

Thanks for the new features like MLAG!

Were the issues with OSPFv3 checksum fixed?

OSPFv3 seems to be even more broken than before, sadly. Adding an area to OSPFv3 (without any interface-templates) causes one CPU to go into high utilization and all of the OSPF menus stop responding. It is not possible to remove the configuration since the menus stop responding, and the only solution is to reset the device config and restore from backup.

I would probably advise people planning to upgrade to delete their OSPF and BGP configuration first before upgrading, and put it back in carefully taking backups beforehand at at very step of the way.

mducharme · Thu May 20, 2021 4:14 am

Is there is a way to use this new Lets Encrypt support without having to open www (and, by extension, webfig) to the world? The Lets Encrypt support is a great idea and I am glad it is there, it is really handy for VPNs etc, but it seems like I am having to open port 80 and webfig to the planet if I want to use it - unless I am missing something.

Thu May 20, 2021 5:33 am

can't wait to see this bad boy: crs520-4xs-16xq

:O

Me too mate. I also really hope the new CRS models have MPLS push/pop support!

killersoft · Thu May 20, 2021 6:21 am

Has 802.11AE / MACSEC been fixed yet ?

vecernik87 · Thu May 20, 2021 6:23 am

Is there is a way to use this new Lets Encrypt support without having to open www (and, by extension, webfig) to the world? The Lets Encrypt support is a great idea and I am glad it is there, it is really handy for VPNs etc, but it seems like I am having to open port 80 and webfig to the planet if I want to use it - unless I am missing something.

That is the reason I was against this feature. Don't get me wrong - LetsEncrypt is beautiful, but opens whole can of worms because many tasks are done by custom made scripts. e.g. I want a DNS challenge on cloudflare. Someone else wants a DNS challenge on Azure etc... It would be all beautiful, but my feeling is, that full support of all (or at least major) methods of validation will take too much development effort.

In the end, it is easier for me to run separate docker/VM with fully featured certbot and a script which will push it to my router automatically

ToTheCLI · Thu May 20, 2021 6:32 am

Wireguard as client is not working even with MSS Clamp fix was working in beta 5.

mducharme · Thu May 20, 2021 6:56 am

That is the reason I was against this feature. Don't get me wrong - LetsEncrypt is beautiful, but opens whole can of worms because many tasks are done by custom made scripts. e.g. I want a DNS challenge on cloudflare. Someone else wants a DNS challenge on Azure etc... It would be all beautiful, but my feeling is, that full support of all (or at least major) methods of validation will take too much development effort.

I don't necessarily have an issue with port 80 validation, but I would want to be able to do that without webfig and everything else being opened at the same time. For instance, certbot has the standalone mode where it runs only a limited webserver for getting the certificate. With such a solution, the www service could be left disabled. It is unusual to open the main www service on a MikroTik router to the world, to say the least - it is contrary to all recommended security practice.

Thu May 20, 2021 9:09 am

For the L3 HW off-load support on CRS3xx can you confirm if that includes even the CRS305 model?

Yes, all CRS3xx devices now support L3 HW offloading. That includes CRS305.

L3HW: Supported Devices

Thu May 20, 2021 9:26 am

What's new in 7.1beta6 (2021-May-18 14:49):

!) ported features and fixes introduced in v6.49;

All the features of v6.49beta46?

Regards,

The changes (in the form of features and fixes) introduced with 6.49beta46, are included in 7.1beta6.
That said, there are features of RouterOS v6, which RouterOS v7 does not support (e.g. MetaRouter), so it would not be accurate to say that 7.1beta6 includes all features of 6.49beta46.

doneware · Thu May 20, 2021 9:38 am

but I would want to be able to do that without webfig and everything else being opened at the same time. For instance, certbot has the standalone mode where it runs only a limited webserver for getting the certificate.

yup.
we need some url level/functionality based acls or decouple services from management functionalities.. the same gues with the REST API. i just don’t want stuff to be visible to anywhere. i love REST, i use it only locally from scripts running on the same device. (tbh it would be totally cool if i could do REST calls using http to localhost, as it would use far less resources compared to the TLS wrapped one. and since it goes to ::1, no one from the outside could see it.)

so i’d like to see a management control knob in routeros to be able to switch on off certain elements:
- webfig
- REST
- quickset

today with exception to www/www-ssl all management methods are linked to a specific tcp port, but with http based different methods in the basked it’s not possible to do proper separation.
and opening a port just for the time of cert validation currently exposes everything.

memelchenkov · Thu May 20, 2021 10:15 am

Is "MikroTik support #[SUP-37062]: ROS 7.1b4: Packet mark issue" fixed in this version? I'd love to see detailed changelog for each beta, because "other minor fixes and improvements" is not very informative, and usually these "minor fixes" are not minor at all.

psannz · Thu May 20, 2021 10:29 am

Mmmm MLAG - sounds tasty.

Any hint on how this could be configured and how it is implemented between boxes?

thx!

https://help.mikrotik.com/docs/display/ ... tion+Group

kriszos · Thu May 20, 2021 1:31 pm

I am very interested in Dudev7 as v6 has many not resolved bugs like this one viewtopic.php?t=129111. But I cant find the server package and CHR don't have one installed by default.

buset1974 · Thu May 20, 2021 1:49 pm

I'm a bit disappointed, would like to see more focus on stability and features that not in V7 but are available in V6 instead of brand new features.

agree, make stable and release it.

gdanov · Thu May 20, 2021 2:11 pm

my LTE stopped working after upgrading (from beta3). This is simply ridiculous.

board: rbm33g
modem: R11e-LTE6
firmware: R11e-LTE6_V026

after upgrading the board it booted with "A newer version of modem firmware is available!" sign at the top of the modem page. pin status is ok but "tx and rc rf disabled".
nothing brings it back to life.

Cablenut9 · Thu May 20, 2021 2:38 pm

my LTE stopped working after upgrading (from beta3). This is simply ridiculous.

board: rbm33g
modem: R11e-LTE6
firmware: R11e-LTE6_V026

after upgrading the board it booted with "A newer version of modem firmware is available!" sign at the top of the modem page. pin status is ok but "tx and rc rf disabled".
nothing brings it back to life.

I had the same problem, keep messing around with manual band selection and USB resets until it works again.

geon · Thu May 20, 2021 3:01 pm

Missing one from changelog : Chelsio NIC driver support.

Alpenfreddy · Thu May 20, 2021 3:13 pm

my LTE stopped working after upgrading (from beta3). This is simply ridiculous.

board: rbm33g
modem: R11e-LTE6
firmware: R11e-LTE6_V026

after upgrading the board it booted with "A newer version of modem firmware is available!" sign at the top of the modem page. pin status is ok but "tx and rc rf disabled".
nothing brings it back to life.

Some problem here: wAP ac LTE kit with R11e-LTE modem firmware MikroTik_CP_2.160.000_v018

pin status is ok but "tx and rc rf disabled" after upgrading from 7.1beta5 to 7.1beta6
With a downgrade back to 7.1beta5 the LTE is working again.

Rfulton · Thu May 20, 2021 3:46 pm

OSPF doesn't work on CCR2004.

Simple queues targeting an interface makes all ipv6 traffic marked as invalid in firewall filter.

gdanov · Thu May 20, 2021 4:09 pm

This "beta" thing has been absolute shitshow. I'm bleep furious. Running mikrotik modem on mikrotik board does not work.

Whoever is responsible for ros7 must be fired. This is absolute disgrace and disappointment.

my LTE stopped working after upgrading (from beta3). This is simply ridiculous.

board: rbm33g
modem: R11e-LTE6
firmware: R11e-LTE6_V026

after upgrading the board it booted with "A newer version of modem firmware is available!" sign at the top of the modem page. pin status is ok but "tx and rc rf disabled".
nothing brings it back to life.
Some problem here: wAP ac LTE kit with R11e-LTE modem firmware MikroTik_CP_2.160.000_v018

pin status is ok but "tx and rc rf disabled" after upgrading from 7.1beta5 to 7.1beta6
With a downgrade back to 7.1beta5 the LTE is working again.

rushlife · Thu May 20, 2021 4:17 pm

This "beta" thing has been absolute shitshow

Do you know what BETA is ?

gdanov · Thu May 20, 2021 4:35 pm

Yes, I do. I've been doing software for 2 decades for a living. I'd be ashamed to deliver such consistently untested software

This "beta" thing has been absolute shitshow
Do you know what BETA is ?

mafiosa · Thu May 20, 2021 4:45 pm

Hello can anyone from mikrotik confirm if route filters and ospfv3 is working or not?

gdanov · Thu May 20, 2021 4:56 pm

This "beta" thing has been absolute shitshow
Do you know what BETA is ?

and because you seem to approve of the beta rollout process probably can help me find the beta5 binaries so that I can downgrade from the latest UNTESTED beta

rextended · Thu May 20, 2021 5:03 pm

This "beta" thing has been absolute shitshow
Do you know what BETA is ?
and because you seem to approve of the beta rollout process probably can help me find the beta5 binaries so that I can downgrade from the latest UNTESTED beta

You like shitshow, and more shitshow than before...
If you are unpleased, why do not use stable or long-term version?

ksteink · Thu May 20, 2021 6:27 pm

For the L3 HW off-load support on CRS3xx can you confirm if that includes even the CRS305 model?

Yes, all CRS3xx devices now support L3 HW offloading. That includes CRS305.

L3HW: Supported Devices

Excellent thank you!

nescafe2002 · Thu May 20, 2021 6:41 pm

and because you seem to approve of the beta rollout process probably can help me find the beta5 binaries so that I can downgrade from the latest UNTESTED beta

Thu May 20, 2021 6:45 pm

Hello can anyone from mikrotik confirm if route filters and ospfv3 is working or not?

Route filters are working

rextended · Thu May 20, 2021 6:48 pm

>>>I've been doing software for 2 decades for a living<<<

blah, blah, blah...
your ego is so big ... what a pleasure to discover that there is someone more modest than me ...
Well, for a "programmer"? ("doing software") do not find a link with intuition is ridiculous...
I'm a programmer too, but unlike you, I have the intuition...
I do not reply to anything for you, please do not consider my words, I'm so idiot and modest from decades.

Thu May 20, 2021 6:50 pm

Anyone who has some problems with OSPF please contact support with attached supout files and brief description on what exactly is not working. "OSPF not work" doesn't help much.

dlhitmhcx6i · Thu May 20, 2021 7:11 pm

MBIM support for Sierra is still broken since 7.1beta3.
viewtopic.php?f=1&t=170940

gdanov · Thu May 20, 2021 7:17 pm

yeah, I guess they belong here in the forum, right? because...why put them on the download/archives page.
and my (actually 3 decades, 1 for fun, 2 for living) helped me find it anyway. but thank you.

and because you seem to approve of the beta rollout process probably can help me find the beta5 binaries so that I can downgrade from the latest UNTESTED beta

Hello person who has been doing software development for decades; you can find the binaries of the previous untested beta release for your device architecture via the following links:

mipsbe: https://download.mikrotik.com/routeros/ ... mipsbe.npk
arm64: https://download.mikrotik.com/routeros/ ... -arm64.npk
smips: https://download.mikrotik.com/routeros/ ... -smips.npk
tile: https://download.mikrotik.com/routeros/ ... 5-tile.npk
ppc: https://download.mikrotik.com/routeros/ ... a5-ppc.npk
arm: https://download.mikrotik.com/routeros/ ... a5-arm.npk
x86: https://download.mikrotik.com/routeros/ ... 1beta5.npk
mmips: https://download.mikrotik.com/routeros/ ... -mmips.npk

gdanov · Thu May 20, 2021 7:21 pm

BETA does not equal "throw a tag at the wall and see if it sticks". There's euphemism for what MT is doing is "outsourcing testing to our clients", and while this isn't bad practice alone, MT are doing it very sloppy.

you can comment my ego and personality as much as you want. If you work at place where such betas are OK, you either have no customers, or sooner or later will get burned by your shitty quality.

MT will "graduate" one of these betas to candidat release, and I don't see indications their quality practices would be drastically different. If you have free time to lose, your choice. But I have better things to do than resetting and downgrading boards because of MT's lazyness.

>>>I've been doing software for 2 decades for a living<<<
blah, blah, blah...
your ego is so big ... what a pleasure to discover that there is someone more modest than me ...
Well, for a "programmer"? ("doing software") do not find a link with intuition is ridiculous...
I'm a programmer too, but unlike you, I have the intuition...
I do not reply to anything for you, please do not consider my words, I'm so idiot and modest from decades.

dakobg · Thu May 20, 2021 8:04 pm

Mlag :)

memelchenkov · Thu May 20, 2021 9:02 pm

@gdanov, don't spend time explaining, you are absolutely right, it's not a beta, it's about alpha quality, just keep it in mind. It's already discussed there many times and nothing really changed. I'm surprised why Mikrotik still adds new features instead of stabilizing existing ones. This is some kind of nonsense. Okay, on their conscience. They also have no roadmap which is also an indicator.

PS: a developer with more than a two decades too :)

rushlife · Thu May 20, 2021 9:47 pm

This "beta" thing has been absolute shitshow
Do you know what BETA is ?
and because you seem to approve of the beta rollout process probably can help me find the beta5 binaries so that I can downgrade from the latest UNTESTED beta

wget https://download.mikrotik.com/routeros/ ... mipsbe.npk
and so on....

Rfulton · Thu May 20, 2021 10:32 pm

Anyone who has some problems with OSPF please contact support with attached supout files and brief description on what exactly is not working. "OSPF not work" doesn't help much.

So they can tell you "Sorry works on my machine" lmao alright fam.

jirinovak · Thu May 20, 2021 11:03 pm

Hello
I tested this version on my RB1100AHx4 and after installation I lost licence and got new soft_ID. Downgrade to v6 gave me the old licence back. Do I need licence for v7? Sorry if that question was asked somwhere else. Is it bug.

filequit · Thu May 20, 2021 11:05 pm

My CCR2004's interface lights are turned on over the wrong interfaces and the interfaces are actually active have no lights over them (I am using sfpplus11, sfpplus12 and sfp28-1 and the LEDs that are lit are sfpplus10, 8 and 5) .

kiler129 · Thu May 20, 2021 11:30 pm

7.1b6 seems to have a strange issue with 5Ghz WiFi which I cannot really explain or debug - maybe someone can chime in?

I'm currently testing on hAP AC. In essence when pushing a stream of 50-80Mb/s it will stop passing TCP traffic after 20-60 minutes. What's interesting it will still allow for pinging but every existing or new TCP connection will freeze. Connections aren't dropped, they just stop carrying data. It seems like this problem is isolated to the 5Ghz interface only. I see nothing in the log. Reconnecting to the AP solves the issue for up to an hour.

Since it's my first attempts to play with v7 on a wireless-capable device I'm not sure if such issue was described anywhere.

aussetg · Fri May 21, 2021 12:13 am

Cake still crashes IMMEDIATELY on the CCR2004

buset1974 · Fri May 21, 2021 7:27 am

anyone 've try mpls?
i've create this simple lab with 4 routers connected each other making a ring/ loop:
first step: OSPF successful created and each router can ping each router loopback.
second step: MPLS activated and problem happen, each router have spesific problem with some router, they can not ping each other with some router not all router.

thx

elel · Fri May 21, 2021 11:46 am

Too many complaints about beta or alpha.
It is a testing release so bad things happen. Whether it is beta or alpha, I do not see the point, you install it and take the risk of things not working as supposed to. Remember that mikrotik tries to put lot of features in one box so it is not that easy to fix lots of them in one shot. It is not like other vendors who put a couple of features in one router and that is it.
Instead of many complaints, try to cooperate and pinpoint the issue if you can, or write to support for the issue you are experiencing, that is how testing works. I do not see you trying to solve the issues but venting your frustration in the forum which has been said a thousands times that is just a user forum, you need to write to support for problem solving if not found in the forum.

NeoPhyTex360 · Fri May 21, 2021 12:17 pm

Cake still shitty (random reboots) after months reporting it, when it get fixed mention me. No more v7 installations until that (with your hard work I think in 2026)

You still porting features from 6.49 instead fix the problems and make a "USABLE" beta. Congratulations you can still making a rubbish firmware with a lot of features that doesn't work

Sorry but it's not a beta, alpha neither.

RB4011

dave864 · Fri May 21, 2021 2:13 pm

The only thing clear is that wifiwave2 will not come to old products.

MT will not support both packages running in v7 - I guess this is what is meant?
MT will not back port wpa3 to the old v6 wi-fi package but that package is still actively maintained, for now - am I correct?

Does this mean that capac etc will not migrate to v7?

Please be clearer. That is why we keep banging on about all this. Just give us clear messaging. I'm sure you're just as tired of this merry-go-round as we are.

mada3k · Fri May 21, 2021 2:27 pm

!) added support for Let's Encrypt certificate generation;

Fun feature, but why? Who absolutly needs valid certificates for the www-ssl service, and can not do it separatly?

nostromog · Fri May 21, 2021 2:29 pm

In essence when pushing a stream of 50-80Mb/s it will stop passing TCP traffic after 20-60 minutes. What's interesting it will still allow for pinging but every existing or new TCP connection will freeze. Connections aren't dropped, they just stop carrying data. It seems like this problem is isolated to the 5Ghz interface only. I see nothing in the log. Reconnecting to the AP solves the issue for up to an hour.

I have seen similar issues both in a hAP ac and an hAP ac^2, in all betas from beta3, but in some cases the radio blacklists the clients (or the client blacklists the AP, not an expert on how it goes) and I need to reboot the router or at least a disable; enable cycle to get it accepting clients again. This kind of error seems related to noisy associations (low signal or noisy channels),

It is tricky to diagnose because it seems to depend of noise and interaction of the AP with different clients. For instance I have a laptop with a Intel Wireless 8260 card that requires sudo modprobe -r iwlmwm; sudo modprobe iwlmvm to keep it working from time to time, again in low signal situations, it never fails when close to the AP; some phones stop connecting to this radio after a while, etc.

Sit75 · Fri May 21, 2021 3:30 pm

Gents, I appreciate it. It is first version of V7 Branch, I can use on hAP ac^2 (256MB RAM) in my home network installation for long time without issues. Good job!

mikegleasonjr · Fri May 21, 2021 3:40 pm

Too many complaints about beta or alpha.
It is a testing release so bad things happen. Whether it is beta or alpha, I do not see the point, you install it and take the risk of things not working as supposed to. Remember that mikrotik tries to put lot of features in one box so it is not that easy to fix lots of them in one shot. It is not like other vendors who put a couple of features in one router and that is it.
Instead of many complaints, try to cooperate and pinpoint the issue if you can, or write to support for the issue you are experiencing, that is how testing works. I do not see you trying to solve the issues but venting your frustration in the forum which has been said a thousands times that is just a user forum, you need to write to support for problem solving if not found in the forum.

We had a constructive and respectful discussion about that earlier in an earlier beta. People expecting beta quality are disappointed because beta means a different thing in the software engineering world than it means to Mikrotik and some of their users. Which I won't bother explaining again. Let's just say that it creates frustrations and loss of time. Ppl feel tricked when basic functionality don't work. Ultimately it hurts Mikrotik and they lose a testing pool of users, without even talking about trust and brand recognition (and ultimately sales). It's a shame their wireless products, their hardware products released using "beta" software and the quality of their release cycle is so poor. They could have eaten shares out of the Ubiquity fiasco recently. And we see their steer their brand more in the consumer market now. But good luck fooling the "consumer" market. Again, see how many users went away of Ubiquity recently.

I, too, felt tricked when I wasn't even able to apply my basic config or to do an actual export of my config on my RB4011. Then my device was constantly rebooting. It was a massive waste of everyone's time and I won't bother testing MK products again. The beta is a pre-alpha. Pushing a feature which is command line only is pre-alpha. A beta is "I am finished, I won't introduce any new features, can you test it please?" Not "I half hack together a new feature each beta, can you check if it does anything? I didn't have time to implement the GUI part of it though". It's not playing with words, it's knowing what you're getting yourself into. I am an adult, I made the decision, I felt tricked, and I got burned. Not crying wolf of being a baby about it, that's the reality. Mikrotik lost a tester and a customer. I hate my Cap ACs on my ceilings knowing they have a capable chipset but a poor software implementation. I hate to see that they sell products that only works on the beta branch. That's deceiving to a customer. The more I am around, the more I see things like that. I am so disappointed because I loved the CLI and the fact that I could keep a version of my config in git and completely configure a device without clicking on anything. I loved that I could automate things (I have a script which fallsback on a secondary DNS, I have a script which connects to a remove VPN if at least one person is connected to a specific wifi ex.: "Guest France"). I loved that the big features were available on lower end devices, but that's not true anymore (see wifiwave2).

EDIT: I removed the last part where I am frustrating of the toxic MK community. I feel it will only cause more frustrations. Meanwhile I am trying to support an openwrt project that would bring better wifi drivers to my cAP acs at home.

gtj0 · Fri May 21, 2021 5:12 pm

The changes (in the form of features and fixes) introduced with 6.49beta46, are included in 7.1beta6.
That said, there are features of RouterOS v6, which RouterOS v7 does not support (e.g. MetaRouter), so it would not be accurate to say that 7.1beta6 includes all features of 6.49beta46.

There are also features that are only in v7 that have had issues so any fixes wouldn't be in the 6.49beta release notes. A compete list for v7 would be very helpful.

anav · Fri May 21, 2021 6:22 pm

Yes, I do. I've been doing software for 2 decades for a living. I'd be ashamed to deliver such consistently untested software

This "beta" thing has been absolute shitshow
Do you know what BETA is ?

Wrong, when one should get irate or have expectations is paid delivery of released firmware versions.
Even then, all 'released' software, unless its for my iphone, and including military systems has issues................
The forum is full of whiners, who seem to have expectations beyond the scope of the beta releases provided.

if they wanted to do something constructive then they should donate lots of money to Normis so he can hire more programmers and more testers for in-house work.
Magically some think it gets done for free and by prayer, or smoking much ganja.

rextended · Fri May 21, 2021 6:26 pm

Yes, I do. I've been doing software for 2 decades for a living. I'd be ashamed to deliver such consistently untested software

This "beta" thing has been absolute shitshow
Do you know what BETA is ?

Wrong, when one should get irate or have expectations is paid delivery of released firmware versions.
Even then, all 'released' software, unless its for my iphone, and including military systems has issues................
The forum is full of whiners, who seem to have expectations beyond the scope of the beta releases provided.

if they wanted to do something constructive then they should donate lots of money to Normis so he can hire more programmers and more testers for in-house work.
Magically some think it gets done for free and by prayer, or smoking much ganja.

I would also pay € 1000 per year.
Will they ever consider like kickstarter funding?

Fri May 21, 2021 6:41 pm

Magically some think it gets done for free and by prayer, or smoking much ganja.

Everyday life in testing:

Cablenut9 · Fri May 21, 2021 7:02 pm

If you want the latest features and have reliability, go to Cisco and pay an enormous amount per year for licensing.

infabo · Fri May 21, 2021 7:26 pm

v7 beta releases are somewhat nightly builds with a tag. thats just it. After filing some issues at their support system I can at least tell, that they respond in time and provide preview-builds that indeed help to resolve or at least weaken my reported problems. So I am still not euphoric about the stability, but it gets better. At least slowly. Sad that stabilizing CAKE is apparently not on their priority list - but when are aware of that you can disable cake queue until they have a fix. I guess they are still figuring out which linux kernel fits best, maybe they are heading towards 5.10 lts and start fixing issues after that is done.

mikegleasonjr · Fri May 21, 2021 7:27 pm

if they wanted to do something constructive then they should donate lots of money to Normis so he can hire more programmers and more testers for in-house work.
Magically some think it gets done for free and by prayer, or smoking much ganja.

We all paid when we bought the package, which includes support and upgrades. The time devoted by a user to test is also a support in some sense. The years of expertise of someone testing your product is also a form a contribution. Buying more products and recommending it to friends is also some kind of support. Normis also already has a salary, it does not do it for free because he is a saint. Mikrotik makes money and also does it for the business of it. Seeing the official reply from Mikrotik also does it for me and also confirms the lack of seriousness of the community revolving around it. Seriously, who replies with some kind of memes to a question like that.

As Mikrotik does not require you to test "beta" software and are under no obligation of anything whatsoever, test users are not required to give their free time either. And the lack of transparency is what is being criticized here. Again, *it would help Mikrotik* being more transparent to their users. Right now, test users feel they are being mislead. They are also free to take their business elsewhere else, including future recommendations to peers, etc. Which I will do.

If you're unhappy and lack resources to do your job, take it to your manager and talk about it. Stop meming your lack of professionalism.

mikegleasonjr · Fri May 21, 2021 7:37 pm

v7 beta releases are somewhat nightly builds with a tag.

If it was advertised as such, I wouldn't have said anything in the first place and I would make a decision based on that.

Side note, so we all agree that there are devices out there (ex.: Chateau), on shelves, required to be run on a nightly build. Is that what we're saying here. And the manufacturer is posting memes about it.

Okay..

infabo · Fri May 21, 2021 7:58 pm

That is the realty. We all have to deal with it - or leave behind Mikrotik devices.

Many are complaining about the wording. I understand that 100%. Times of software with "beta" versions have long passed. Today you either have Early Access versions, release candidates and stable releases. Early access would match better than beta.

But what really astonishing is the lack of a roadmap. Noone knows what next beta release will bring of new features. Where is the forecast, the roadmap or at least anything you can hold on? It is just not there. Maybe they have an internal roadmap, but from the outside view I can't recognize a vision where v7 is going and when it will be stable released. And once it is stable, we all won't know what will be inside.

Providing wifiwave2 as a testing package for a hand of devices and telling people: "you are testing it now, but your device will not receive the stable one because wifiwave2 is for future devices only". thats kind of irritating and people investing time evaluating that package should think twice.

mafiosa · Fri May 21, 2021 8:18 pm

Hello can anyone from mikrotik confirm if route filters and ospfv3 is working or not?
Route filters are working

Route filters aren't working. See detailed post: viewtopic.php?f=1&t=175428 Also check ticket# SUP-50226

vinigas · Fri May 21, 2021 10:35 pm

Yes, I do. I've been doing software for 2 decades for a living. I'd be ashamed to deliver such consistently untested software

This "beta" thing has been absolute shitshow
Do you know what BETA is ?

Well, then you should also know what "development" branch/channel is...

7.1 is in development channel;
6.49beta46 is in testing channel;
6.48.2 is in stable AKA main release branch;
6.47.9 is longterm branch which is for get-it-and-forget-it;

Choose accordingly.

---

Btw LetEncrypt certbot integration is cool addition for my case.

mafiosa · Fri May 21, 2021 11:15 pm

Hello can anyone from mikrotik confirm if route filters and ospfv3 is working or not?
Route filters are working
Route filters aren't working. See detailed post: viewtopic.php?f=1&t=175428 Also check ticket# SUP-50226

Got the working partially with the help of Mrz via support portal. Will update once it get it fully working. Maybe updated documentation will do the job for others.

infabo · Sat May 22, 2021 1:23 am

How to debug this further?

Bildschirmfoto 2021-05-22 um 00.22.14.png

mducharme · Sat May 22, 2021 4:05 am

How to debug this further?

You have to have service "www" enabled and port 80 open to the world.

This is the issue that I had - I don't like having to have www port 80 open to everywhere - even if it is just for a brief time to renew LetsEncrypt with a scheduled task. There should be a way of renewing this without webfig being opened globally, even if it is just for 30 seconds every week to update the certificate.

mducharme · Sat May 22, 2021 5:02 am

Good news for this new version for hAP mini users - unlike 7.1beta5, this version works without the device becoming unresponsive. This probably also applies to other smips architecture devices. I had to keep my hAP mini on 7.1beta4 while all of my other devices were on beta5.

jimmer · Sat May 22, 2021 5:45 am

Side note, so we all agree that there are devices out there (ex.: Chateau), on shelves, required to be run on a nightly build. Is that what we're saying here. And the manufacturer is posting memes about it.

Okay..

Agree, I find it hard to believe that the RBD53G-5HacD2HnD-TC&EG12-EA was released and has been sold for quite some time with alpha code availble for it, it should never have been released before mainline software support was available, otherwise you're just releasing a commercial product that costs actual money but are forced to run buggy and potentially insecure code that has not been properly tested internally, add this to the fact that some of these devices will go into 'production' with 'development' code that never sees the light of an upgrade then you have a product with undeveloped alpha code with unfinished features sitting on potentially the public internet awaiting its fate.

I do love MikroTik gear but 7.1 needs to lose the beta tag, testing has a beta tag and people expect the same maturity from an RC line as they do with 7.x.
Also I believe a product shouldn't be commercially sold until mainline stable code is available for it, by all means ship it to users in a development testing program but it shouldn't see the hands of the average joe until thats sorted out.

Now I'll go and netinstall my RB3011 to remove the 7.1beta6 that wont downgrade or sidegrade due to a kernel panic in the reboot cycle.

vinigas · Sat May 22, 2021 12:42 pm

Side note, so we all agree that there are devices out there (ex.: Chateau), on shelves, required to be run on a nightly build. Is that what we're saying here. And the manufacturer is posting memes about it.

Okay..
Agree, I find it hard to believe that the RBD53G-5HacD2HnD-TC&EG12-EA was released and has been sold for quite some time with alpha code availble for it, it should never have been released before mainline software support was available, otherwise you're just releasing a commercial product that costs actual money but are forced to run buggy and potentially insecure code that has not been properly tested internally, add this to the fact that some of these devices will go into 'production' with 'development' code that never sees the light of an upgrade then you have a product with undeveloped alpha code with unfinished features sitting on potentially the public internet awaiting its fate.

I do love MikroTik gear but 7.1 needs to lose the beta tag, testing has a beta tag and people expect the same maturity from an RC line as they do with 7.x.
Also I believe a product shouldn't be commercially sold until mainline stable code is available for it, by all means ship it to users in a development testing program but it shouldn't see the hands of the average joe until thats sorted out.

Now I'll go and netinstall my RB3011 to remove the 7.1beta6 that wont downgrade or sidegrade due to a kernel panic in the reboot cycle.

It probably would be more ethical to add note to the product which doesn't have yet stable software, like Pinephone manufacturers does:

Note:
Beta Edition PinePhones are aimed solely at early adopters. More specifically, only intend for these units to find their way into the hands of users with extensive Linux experience.
Quote source: https://pine64.com/product/pinephone-be ... 46c16e2e66

If hardware is ready, I think it's ok to release product earlier. Because you can get it now with RouterOS functionality, instead of looking to other vendors which may have less of features. 5G is not broadly adopted yet anyway.

cmartin · Sat May 22, 2021 12:52 pm

MikroTik gentleman, you have my big thanks for this. This is definitely step in right direction!

mafiosa · Sat May 22, 2021 1:08 pm

RB3011 crashed thrice in the last 12 hours. Once while adding new DHCP server, next while executing routing/route/ print where filtered and once randomly. In the first two cases, it triggered a memory leak and ate up the entire ram.

xvo · Sat May 22, 2021 1:41 pm

I wonder what exactly the new option hw-offload=yes in firewall action=fasttrack rule do?
I guess it is added so we can choose which of fasttracked connection to be L3 HW Offloaded on CRS3XX.
But does setting it to yes/no change anything on other devices, that don't have L3 HW Offloading?

sindy · Sat May 22, 2021 2:52 pm

Given that there is a possibility to fasttrack connections on CHR and the connections are even marked as fasttracked in /ip firewall connection print, although all their packets actually take the full path (at least they do in 6.x), and given that you can set up /interface ethernet switch vlan items on devices with RTL8367 switch chips on which VLANs are not supported (at least in RouterOS), I'd guess this setting will just be silently ignored on other-than-CRS3xx devices.

Especially because the OS decides dynamically per connection whether to let the switch chip handle that particular one, preferring hardware offloading of those with highest flow rates. So I assume hw-offload is just another attribute stored in the connection tracking context, which the system uses where possible (CRS3xx) and ignores elsewhere.

xvo · Sat May 22, 2021 3:04 pm

I'd guess this setting will just be silently ignored on other-than-CRS3xx devices.

That's what I thought too.
And that is how that should be.
But given the beta state there is still a possibility, that it currently might break something if set on the improper device and not handled properly by os.
So basically my question is: are there any known issues connected with it?

jimmer · Sat May 22, 2021 3:23 pm

I can confirm that my RB3011's kernel panic on downgrade/upgrade and on reboot after upgrading to 7.1beta6 was resolved by doing a netinstall back to 6.48.2 and restore of backup config taken prior to 7.1beta6 upgrade. I think i'll hold off for a few more versions before trying again.

Sit75 · Sat May 22, 2021 8:25 pm

Gents, I appreciate it. It is first version of V7 Branch, I can use on hAP ac^2 (256MB RAM) in my home network installation for long time without issues. Good job!

One error found - IPv6 doesn't work unfortunately.

Sat May 22, 2021 8:33 pm

What exactly is not working with IPv6?

mducharme · Sat May 22, 2021 9:13 pm

I can confirm that my RB3011's kernel panic on downgrade/upgrade and on reboot after upgrading to 7.1beta6 was resolved by doing a netinstall back to 6.48.2 and restore of backup config taken prior to 7.1beta6 upgrade. I think i'll hold off for a few more versions before trying again.

You shouldn't just upgrade from one beta to the next keeping the configuration, unless your configuration is simple (ex. basic home router config). The issue is that going from one beta to another does NOT update the config syntax where there were syntax changes, so it can potentially make the device unstable. This will be the case for the routing protocols and other parts of the router where the syntax is still in flux. You should export to RSC, reset to no-defaults, upgrade, and paste the RSC back in section by section. This way any incorrect syntax will throw an error and not make it into the config, rather than having a situation with wrong syntax already being there and causing malfunctions because it should not exist in the config in the first place.

anav · Sat May 22, 2021 9:36 pm

That seems like a very logical and accurate assessment mudcharm, should be a beta written SOP (standard operating procedure) somewhere.

kalamaja · Sun May 23, 2021 12:48 am

What exactly is not working with IPv6?

I can confirm on 4011 recently upgraded from 6.48.2. Simple SLAAC configuration with prefix and address:
/ipv6 dhcp-client add add-default-route=yes interface=ether1 pool-name=ipv6-pool request=prefix use-peer-dns=no
/ipv6 address add address=::1 from-pool=ipv6-pool interface=bridge

Results in:
may/23 00:35:32 radvd,debug RADVD:: skip Router Advertisement sending on bridge: no link local address
may/23 00:36:11 radvd,debug RADVD:: skip Router Advertisement sending on wlan1: no prefixes to send
may/23 00:37:07 radvd,debug RADVD:: skip Router Advertisement sending on ether4: no prefixes to send
may/23 00:38:39 radvd,debug RADVD:: skip Router Advertisement sending on wlan2: no prefixes to send
may/23 00:39:45 radvd,debug RADVD:: skip Router Advertisement sending on ether8: no prefixes to send
may/23 00:41:18 radvd,debug RADVD:: skip Router Advertisement sending on ether2: no prefixes to send

mducharme · Sun May 23, 2021 12:55 am

may/23 00:35:32 radvd,debug RADVD:: skip Router Advertisement sending on bridge: no link local address

Make sure admin mac address is set for your bridge, and that "Disable IPv6" is not checked under IPv6->Settings.

nescafe2002 · Sun May 23, 2021 12:59 am

This has been reported but was unconfirmed by MikroTik support.

SUP-45712 [7.1beta5] No link-local communication after bridge reconfiguration

Quick solution is to briefly disable and enable IPv6;

/ipv6/settings/set disable-ipv6=yes
/ipv6/settings/set disable-ipv6=no

The issue re-appears after a bridge mac address reconfiguration, e.g. due to port membership update.
It doesn't matter which bridge (can be an unrelated bridge).

mducharme · Sun May 23, 2021 1:01 am

The issue re-appears after a bridge mac address reconfiguration, e.g. due to port membership update.
It doesn't matter which bridge (can be an unrelated bridge).

You can prevent port membership updates from affecting the bridge mac by hard setting the admin MAC instead of using auto MAC for the bridge.

nescafe2002 · Sun May 23, 2021 1:03 am

You can prevent port membership updates from affecting the bridge mac by hard setting the admin MAC instead of using auto MAC for the bridge.

Yes, but reconfiguring any bridge (e.g. bridge2) should not lead to loss of link local address of another bridge (e.g. bridge1).

mducharme · Sun May 23, 2021 1:11 am

Yes, but reconfiguring any bridge (e.g. bridge2) should not lead to loss of link local address of another bridge (e.g. bridge1).

Yes, it is a bug and certainly should be fixed, but there have been many auto MAC related bugs in the past similar to this, enough that kalamaja should probably set it as a part of best practice configuration to avoid encountering these sorts of bugs.

Sun May 23, 2021 11:50 am

I wonder what exactly the new option hw-offload=yes in firewall action=fasttrack rule do?
I guess it is added so we can choose which of fasttracked connection to be L3 HW Offloaded on CRS3XX.
But does setting it to yes/no change anything on other devices, that don't have L3 HW Offloading?

If the switch chip does not support L3 HW offloading, the hw-offload option of firewall rules is ignored. It is still safe to leave hw-offload=yes on unsupported devices, e.g., if you want to use the same firewall rules on multiple devices, some of them supporting L3HW. Please keep in mind that not all CRS3xx devices support Fasttrack offloading, even if they support L3HW. One such example - CRS305.

List of devices that support L3 HW offloading

Serj12life · Sun May 23, 2021 3:30 pm

my LTE stopped working after upgrading (from beta3). This is simply ridiculous.

board: rbm33g
modem: R11e-LTE6
firmware: R11e-LTE6_V026

after upgrading the board it booted with "A newer version of modem firmware is available!" sign at the top of the modem page. pin status is ok but "tx and rc rf disabled".
nothing brings it back to life.
Some problem here: wAP ac LTE kit with R11e-LTE modem firmware MikroTik_CP_2.160.000_v018
pin status is ok but "tx and rc rf disabled" after upgrading from 7.1beta5 to 7.1beta6
With a downgrade back to 7.1beta5 the LTE is working again.

When will you fix the bug with LTE in bete6?

xvo · Sun May 23, 2021 7:06 pm

Thanks for clarification!

garis · Sun May 23, 2021 7:38 pm

Found a possible issue with 6to4 HE tunnel config with the beta firmware (5 and 6), solved by reverting to stable viewtopic.php?f=2&t=175295&p=858779#p858779

SUP-46778 if someone from Mikrotik is interested.

doush · Sun May 23, 2021 9:37 pm

Isnt it a bit weird that now Mikrotik Switches can route and filter/nat much faster than actual Mikrotik Routers ? :)

mducharme · Sun May 23, 2021 10:11 pm

The issue re-appears after a bridge mac address reconfiguration, e.g. due to port membership update.
It doesn't matter which bridge (can be an unrelated bridge).

I've been able to reproduce it - it happens to me even when there is no bridge MAC address reconfiguration taking place, i.e. just one bridge with admin MAC set. So there must be some other trigger for this issue.

whatever · Sun May 23, 2021 10:18 pm

Isnt it a bit weird that now Mikrotik Switches can route and filter/nat much faster than actual Mikrotik Routers ? :)

Well, they are called Cloud Router Switch, after all.
It's a pity that L3 offloading is limited to IPv4 only, but it's impressive nevertheless.

mducharme · Sun May 23, 2021 10:21 pm

It's a pity that L3 offloading is limited to IPv4 only, but it's impressive nevertheless.

I may be mistaken, but my understanding is that it is only limited to IPv4 for now, and L3 offloading for IPv6 is coming.

anuser · Sun May 23, 2021 11:59 pm

Meanwhile I am trying to support an openwrt project that would bring better wifi drivers to my cAP acs at home.

https://github.com/openwrt/openwrt/pull/4055 => Nice to see that work was restarted for getting a port done. The actual goal would be to get it into official 21.02 branch in order to reach long term support.

mducharme · Mon May 24, 2021 12:00 am

I've been able to reproduce it - it happens to me even when there is no bridge MAC address reconfiguration taking place, i.e. just one bridge with admin MAC set. So there must be some other trigger for this issue.

On my device, a kernel panic occurs on reboot that appears to be related to this issue. If I have no bridges, the kernel panic does not occur. If I have at least one bridge, I get this kernel panic each time I try to reboot:

[admin@Michael-RB4011] >
Rebooting...
[  573.721183] Internal error: Oops: 17 [#1] SMP ARM
[  573.725884] CPU: 2 PID: 263 Comm: sysinit Not tainted 5.6.3 #60
[  573.731791] Hardware name: Annapurna Labs Alpine
[  573.736402] PC is at _stext+0x2c610/0x4338e8
[  573.740663] LR is at _stext+0x2c5c8/0x4338e8
[  573.744924] pc : [<8012c610>]    lr : [<8012c5c8>]    psr: 60000093
[  573.751177] sp : bf0afbb8  ip : 00000000  fp : 00000000
[  573.756390] r10: 8087d23c  r9 : 00000004  r8 : 8087d23c
[  573.761604] r7 : bcefd6c0  r6 : 00000002  r5 : bcdc4e00  r4 : 00000000
[  573.768118] r3 : 00000003  r2 : 00000002  r1 : 07ffffff  r0 : 00000000
[  573.774632] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  573.781839] Control: 10c5387d  Table: 3975c06a  DAC: 00000051
[  573.787572] Process sysinit (pid: 263, stack limit = 0xed12ffa8)
[  573.793571] {bf0afbe4} _stext+0x2c820/0x4338e8
[  573.798014] {bf0afbfc} switch_switchdev_event+0x1cc/0x244 [switch@0x7f0e6000]
[  573.805139] {bf0afc1c} _stext+0x32ab4/0x4338e8
[  573.809573] {bf0afc3c} _stext+0x32c70/0x4338e8
[  573.814009] {bf0afc4c} _stext+0x32c8c/0x4338e8
[  573.818453] {bf0afc5c} br_switchdev_fdb_notify+0xbc/0xc4 [bridge2@0x7f0f4000]
[  573.825583] {bf0afc74} br_fdb_find_port+0x73c/0xdb0 [bridge2@0x7f0f4000]
[  573.832278] {bf0afc9c} br_fdb_find_port+0xa88/0xdb0 [bridge2@0x7f0f4000]
[  573.838972] {bf0afd84} br_fdb_delete_by_port+0x88/0xb4 [bridge2@0x7f0f4000]
[  573.845927] {bf0afda4} br_device_event+0x1b0/0x1dc [bridge2@0x7f0f4000]
[  573.852527] {bf0afdc4} _stext+0x32ab4/0x4338e8
[  573.856962] {bf0afde4} _stext+0x32d28/0x4338e8
[  573.861397] {bf0afdf4} _stext+0x36124c/0x4338e8
[  573.865919] {bf0afe04} _stext+0x366d54/0x4338e8
[  573.870441] {bf0afe24} _stext+0x3673d0/0x4338e8
[  573.874962] {bf0afe3c} _stext+0x3e44c8/0x4338e8
[  573.879484] {bf0afe8c} _stext+0x3e66ac/0x4338e8
[  573.884006] {bf0afef4} _stext+0x3490fc/0x4338e8
[  573.888527] {bf0aff34} _stext+0xdd9cc/0x4338e8
[  573.892963] {bf0aff3c} _stext+0xdded0/0x4338e8
[  573.897397] {bf0affa4} _stext+0x1000/0x4338e8
[  573.901745] Exception stack(0xbf0affa8 to 0xbf0afff0)
[  573.906787] ffa0:                   7efffbd0 0002d390 00000003 00008914 7efffb88 7efffb18
[  573.914948] ffc0: 7efffbd0 0002d390 00000002 00000036 00000001 00000003 00000000 00000000
[  573.923108] ffe0: 0002d018 7efffb00 00015410 76fced14
[  573.928151] Code: 01a04003 0a000003 e1a0000b ebfffcd0 (e5940000)
[  573.934234] ---[ end trace 35b3c22b82377f68 ]---
[  573.939842] Kernel panic - not syncing: Fatal exception in interrupt
[  573.946189] CPU1: stopping
[  573.948896] CPU: 1 PID: 259 Comm: kworker/1:0 Tainted: G      D           5.6.3 #60
[  573.956534] Hardware name: Annapurna Labs Alpine
[  573.961158] Workqueue: events phy_poll_task [phy_helper@0x7f0d5000]
[  573.967417] {bf3e1e54} _stext+0x97a4/0x4338e8
[  573.971766] {bf3e1e5c} _stext+0x420060/0x4338e8
[  573.976288] {bf3e1e6c} _stext+0xbef0/0x4338e8
[  573.980637] {bf3e1e84} _stext+0x1b348c/0x4338e8
[  573.985159] {bf3e1e9c} _stext+0x1acc/0x4338e8
[  573.989507] Exception stack(0xbf3e1ea0 to 0xbf3e1ee8)
[  573.994550] 1ea0: 00000001 bdaef8c0 00000000 00000000 00000002 80965b70 00000000 bf7c3d00
[  574.002712] 1ec0: 00000002 00000000 7f0dd498 8090aa70 80965b68 bf3e1ef0 bf3e0000 801479bc
[  574.010871] 1ee0: 20000013 ffffffff
[  574.014354] {bf3e1eec} _stext+0x479bc/0x4338e8
[  574.018790] {bf3e1ef4} __schedule+0xed4/0xcc718
[  574.023318] {bf3e1f2c} phy_poll_task+0x10/0x6c [phy_helper@0x7f0d5000]
[  574.029834] {bf3e1f3c} _stext+0x2cae4/0x4338e8
[  574.034269] {bf3e1f64} _stext+0x2cde4/0x4338e8
[  574.038704] {bf3e1f8c} _stext+0x31acc/0x4338e8
[  574.043139] {bf3e1fac} _stext+0x10e8/0x4338e8
[  574.047486] Exception stack(0xbf3e1fb0 to 0xbf3e1ff8)
[  574.052528] 1fa0:                                     00000000 00000000 00000000 00000000
[  574.060689] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  574.068848] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[  574.075449] CPU3: stopping
[  574.078155] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G      D           5.6.3 #60
[  574.085449] Hardware name: Annapurna Labs Alpine
[  574.090059] {bf09bf34} _stext+0x97a4/0x4338e8
[  574.094409] {bf09bf3c} _stext+0x420060/0x4338e8
[  574.098931] {bf09bf4c} _stext+0xbef0/0x4338e8
[  574.103280] {bf09bf64} _stext+0x1b348c/0x4338e8
[  574.107802] {bf09bf7c} _stext+0x1acc/0x4338e8
[  574.112149] Exception stack(0xbf09bf80 to 0xbf09bfc8)
[  574.117193] bf80: 0056f0a8 00000000 0056f0a8 801142a0 bf09a000 00000008 80903e24 80903e60
[  574.125354] bfa0: 0000406a 412fc0f4 00000000 00000000 00000000 bf09bfd0 80106f60 80106f50
[  574.133512] bfc0: 60000013 ffffffff
[  574.136994] {bf09bfcc} _stext+0x6f50/0x4338e8
[  574.141343] {bf09bfd4} _stext+0x3a0d8/0x4338e8
[  574.145778] {bf09bfec} _stext+0x3a368/0x4338e8
[  574.150212] {bf09bff4} 0x10246c
[  574.153348] CPU0: stopping
[  574.156055] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G      D           5.6.3 #60
[  574.163348] Hardware name: Annapurna Labs Alpine
[  574.167958] {80901f04} _stext+0x97a4/0x4338e8
[  574.172307] {80901f0c} _stext+0x420060/0x4338e8
[  574.176829] {80901f1c} _stext+0xbef0/0x4338e8
[  574.181178] {80901f34} _stext+0x1b348c/0x4338e8
[  574.185699] {80901f4c} _stext+0x1acc/0x4338e8
[  574.190046] Exception stack(0x80901f50 to 0x80901f98)
[  574.195089] 1f40:                                     03e58ba8 00000000 03e58ba8 801142a0
[  574.203251] 1f60: 80900000 00000001 80903e24 80903e60 80824a38 412fc0f4 10c5387d 00000000
[  574.211411] 1f80: 00000000 80901fa0 80106f60 80106f50 60000013 ffffffff
[  574.218013] {80901f9c} _stext+0x6f50/0x4338e8
[  574.222361] {80901fa4} _stext+0x3a0d8/0x4338e8
[  574.226796] {80901fbc} _stext+0x3a368/0x4338e8
[  574.231231] {80901fc4} _sinittext+0x934/0x20d80
[  574.235820] save panic in NOR
[  574.238782] al_spi_flash_init
[  574.241751] ------------[ cut here ]------------
[  574.246358] kernel BUG at mm/vmalloc.c:2111!
[  574.250619] Internal error: Oops - BUG: 0 [#2] SMP ARM
[  574.255747] CPU: 2 PID: 263 Comm: sysinit Tainted: G      D           5.6.3 #60
[  574.263039] Hardware name: Annapurna Labs Alpine
[  574.267647] PC is at _stext+0xbd370/0x4338e8
[  574.271908] LR is at _stext+0xbd558/0x4338e8
[  574.276169] pc : [<801bd370>]    lr : [<801bd558>]    psr: 20000113
[  574.282422] sp : bf0af998  ip : ff800000  fp : bf0afab0
[  574.287636] r10: 809077a8  r9 : 00000000  r8 : c0800000
[  574.292848] r7 : 00000cc0  r6 : 00000001  r5 : fd882000  r4 : 00001000
[  574.299362] r3 : 00000400  r2 : 00000400  r1 : 00000001  r0 : 00001000
[  574.305874] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  574.312994] Control: 10c5387d  Table: 3975c06a  DAC: 00000051
[  574.318727] Process sysinit (pid: 263, stack limit = 0xed12ffa8)
[  574.324722] {bf0af9bc} _stext+0xbd558/0x4338e8
[  574.329157] {bf0af9d4} _stext+0x11e1c/0x4338e8
[  574.333592] {bf0af9f4} _stext+0x11ea0/0x4338e8
[  574.338036] {bf0afa04} al_spi_flash_init+0x28/0xac [flash@0x7f000000]
[  574.344470] {bf0afa1c} custom_spi_on+0x14/0x190 [flash@0x7f000000]
[  574.350642] {bf0afa24} panic_saver_release+0x110/0x1dc [panics@0x7f00f000]
[  574.357502] {bf0afa44} _stext+0x32ab4/0x4338e8
[  574.361937] {bf0afa64} _stext+0x32c70/0x4338e8
[  574.366372] {bf0afa74} _stext+0x32c8c/0x4338e8
[  574.370807] {bf0afa84} _stext+0x19b24/0x4338e8
[  574.375243] {bf0afaac} _stext+0x9a20/0x4338e8
[  574.379591] {bf0afae4} _stext+0xff90/0x4338e8
[  574.383940] {bf0afafc} _stext+0x102b0/0x4338e8
[  574.388375] {bf0afb3c} _stext+0x103f8/0x4338e8
[  574.392809] {bf0afb64} _stext+0x1a38/0x4338e8
[  574.397157] Exception stack(0xbf0afb68 to 0xbf0afbb0)
[  574.402198] fb60:                   00000000 07ffffff 00000002 00000003 00000000 bcdc4e00
[  574.410359] fb80: 00000002 bcefd6c0 8087d23c 00000004 8087d23c 00000000 00000000 bf0afbb8
[  574.418518] fba0: 8012c5c8 8012c610 60000093 ffffffff
[  574.423559] {bf0afbb4} _stext+0x2c610/0x4338e8
[  574.427994] {bf0afbe4} _stext+0x2c820/0x4338e8
[  574.432433] {bf0afbfc} switch_switchdev_event+0x1cc/0x244 [switch@0x7f0e6000]
[  574.439553] {bf0afc1c} _stext+0x32ab4/0x4338e8
[  574.443988] {bf0afc3c} _stext+0x32c70/0x4338e8
[  574.448423] {bf0afc4c} _stext+0x32c8c/0x4338e8
[  574.452865] {bf0afc5c} br_switchdev_fdb_notify+0xbc/0xc4 [bridge2@0x7f0f4000]
[  574.459993] {bf0afc74} br_fdb_find_port+0x73c/0xdb0 [bridge2@0x7f0f4000]
[  574.466687] {bf0afc9c} br_fdb_find_port+0xa88/0xdb0 [bridge2@0x7f0f4000]
[  574.473381] {bf0afd84} br_fdb_delete_by_port+0x88/0xb4 [bridge2@0x7f0f4000]
[  574.480335] {bf0afda4} br_device_event+0x1b0/0x1dc [bridge2@0x7f0f4000]
[  574.486935] {bf0afdc4} _stext+0x32ab4/0x4338e8
[  574.491370] {bf0afde4} _stext+0x32d28/0x4338e8
[  574.495805] {bf0afdf4} _stext+0x36124c/0x4338e8
[  574.500326] {bf0afe04} _stext+0x366d54/0x4338e8
[  574.504847] {bf0afe24} _stext+0x3673d0/0x4338e8
[  574.509368] {bf0afe3c} _stext+0x3e44c8/0x4338e8
[  574.513890] {bf0afe8c} _stext+0x3e66ac/0x4338e8
[  574.518411] {bf0afef4} _stext+0x3490fc/0x4338e8
[  574.522931] {bf0aff34} _stext+0xdd9cc/0x4338e8
[  574.527366] {bf0aff3c} _stext+0xdded0/0x4338e8
[  574.531801] {bf0affa4} _stext+0x1000/0x4338e8
[  574.536148] Exception stack(0xbf0affa8 to 0xbf0afff0)
[  574.541190] ffa0:                   7efffbd0 0002d390 00000003 00008914 7efffb88 7efffb18
[  574.549350] ffc0: 7efffbd0 0002d390 00000002 00000036 00000001 00000003 00000000 00000000
[  574.557509] ffe0: 0002d018 7efffb00 00015410 76fced14
[  574.562552] Code: e59f30fc e0033002 e3530000 0a000000 (e7f001f2)
[  574.568633] ---[ end trace 35b3c22b82377f69 ]---
[  574.574240] Kernel panic - not syncing: Fatal exception in interrupt

Device is RB4011 wifi model. 7.1beta6 works OK aside from this.

Mon May 24, 2021 8:52 am

It's a pity that L3 offloading is limited to IPv4 only, but it's impressive nevertheless.
I may be mistaken, but my understanding is that it is only limited to IPv4 for now, and L3 offloading for IPv6 is coming.

Exactly. L3 HW for IPv6 is on the roadmap.

Mon May 24, 2021 9:07 am

It's a pity that L3 offloading is limited to IPv4 only, but it's impressive nevertheless.
I may be mistaken, but my understanding is that it is only limited to IPv4 for now, and L3 offloading for IPv6 is coming.
Exactly. L3 HW for IPv6 is on the roadmap.

Be still, my beating heart !

This will be epic.

Florian · Mon May 24, 2021 10:01 am

It's a pity that L3 offloading is limited to IPv4 only, but it's impressive nevertheless.
I may be mistaken, but my understanding is that it is only limited to IPv4 for now, and L3 offloading for IPv6 is coming.
Exactly. L3 HW for IPv6 is on the roadmap.

And any news on fasttrack for ipv6 on CCRs (when you have fw rules) ?

jimmer · Mon May 24, 2021 11:29 am

On my device, a kernel panic occurs on reboot that appears to be related to this issue. If I have no bridges, the kernel panic does not occur. If I have at least one bridge, I get this kernel panic each time I try to reboot:

[admin@Michael-RB4011] >
Rebooting...
[  573.721183] Internal error: Oops: 17 [#1] SMP ARM
[  573.725884] CPU: 2 PID: 263 Comm: sysinit Not tainted 5.6.3 #60
[  573.731791] Hardware name: Annapurna Labs Alpine
[  573.736402] PC is at _stext+0x2c610/0x4338e8
[  573.740663] LR is at _stext+0x2c5c8/0x4338e8
[  573.744924] pc : [<8012c610>]    lr : [<8012c5c8>]    psr: 60000093
[  573.751177] sp : bf0afbb8  ip : 00000000  fp : 00000000
[  573.756390] r10: 8087d23c  r9 : 00000004  r8 : 8087d23c
[  573.761604] r7 : bcefd6c0  r6 : 00000002  r5 : bcdc4e00  r4 : 00000000
[  573.768118] r3 : 00000003  r2 : 00000002  r1 : 07ffffff  r0 : 00000000
[  573.774632] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  573.781839] Control: 10c5387d  Table: 3975c06a  DAC: 00000051
[  573.787572] Process sysinit (pid: 263, stack limit = 0xed12ffa8)
[  573.793571] {bf0afbe4} _stext+0x2c820/0x4338e8
[  573.798014] {bf0afbfc} switch_switchdev_event+0x1cc/0x244 [switch@0x7f0e6000]
[  573.805139] {bf0afc1c} _stext+0x32ab4/0x4338e8
[  573.809573] {bf0afc3c} _stext+0x32c70/0x4338e8
[  573.814009] {bf0afc4c} _stext+0x32c8c/0x4338e8
[  573.818453] {bf0afc5c} br_switchdev_fdb_notify+0xbc/0xc4 [bridge2@0x7f0f4000]
[  573.825583] {bf0afc74} br_fdb_find_port+0x73c/0xdb0 [bridge2@0x7f0f4000]
[  573.832278] {bf0afc9c} br_fdb_find_port+0xa88/0xdb0 [bridge2@0x7f0f4000]
[  573.838972] {bf0afd84} br_fdb_delete_by_port+0x88/0xb4 [bridge2@0x7f0f4000]
[  573.845927] {bf0afda4} br_device_event+0x1b0/0x1dc [bridge2@0x7f0f4000]
[  573.852527] {bf0afdc4} _stext+0x32ab4/0x4338e8
[  573.856962] {bf0afde4} _stext+0x32d28/0x4338e8
[  573.861397] {bf0afdf4} _stext+0x36124c/0x4338e8
[  573.865919] {bf0afe04} _stext+0x366d54/0x4338e8
[  573.870441] {bf0afe24} _stext+0x3673d0/0x4338e8
[  573.874962] {bf0afe3c} _stext+0x3e44c8/0x4338e8
[  573.879484] {bf0afe8c} _stext+0x3e66ac/0x4338e8
[  573.884006] {bf0afef4} _stext+0x3490fc/0x4338e8
[  573.888527] {bf0aff34} _stext+0xdd9cc/0x4338e8
[  573.892963] {bf0aff3c} _stext+0xdded0/0x4338e8
[  573.897397] {bf0affa4} _stext+0x1000/0x4338e8
[  573.901745] Exception stack(0xbf0affa8 to 0xbf0afff0)
[  573.906787] ffa0:                   7efffbd0 0002d390 00000003 00008914 7efffb88 7efffb18
[  573.914948] ffc0: 7efffbd0 0002d390 00000002 00000036 00000001 00000003 00000000 00000000
[  573.923108] ffe0: 0002d018 7efffb00 00015410 76fced14
[  573.928151] Code: 01a04003 0a000003 e1a0000b ebfffcd0 (e5940000)
[  573.934234] ---[ end trace 35b3c22b82377f68 ]---
[  573.939842] Kernel panic - not syncing: Fatal exception in interrupt
[  573.946189] CPU1: stopping
[  573.948896] CPU: 1 PID: 259 Comm: kworker/1:0 Tainted: G      D           5.6.3 #60
[  573.956534] Hardware name: Annapurna Labs Alpine
[  573.961158] Workqueue: events phy_poll_task [phy_helper@0x7f0d5000]
[  573.967417] {bf3e1e54} _stext+0x97a4/0x4338e8
[  573.971766] {bf3e1e5c} _stext+0x420060/0x4338e8
[  573.976288] {bf3e1e6c} _stext+0xbef0/0x4338e8
[  573.980637] {bf3e1e84} _stext+0x1b348c/0x4338e8
[  573.985159] {bf3e1e9c} _stext+0x1acc/0x4338e8
[  573.989507] Exception stack(0xbf3e1ea0 to 0xbf3e1ee8)
[  573.994550] 1ea0: 00000001 bdaef8c0 00000000 00000000 00000002 80965b70 00000000 bf7c3d00
[  574.002712] 1ec0: 00000002 00000000 7f0dd498 8090aa70 80965b68 bf3e1ef0 bf3e0000 801479bc
[  574.010871] 1ee0: 20000013 ffffffff
[  574.014354] {bf3e1eec} _stext+0x479bc/0x4338e8
[  574.018790] {bf3e1ef4} __schedule+0xed4/0xcc718
[  574.023318] {bf3e1f2c} phy_poll_task+0x10/0x6c [phy_helper@0x7f0d5000]
[  574.029834] {bf3e1f3c} _stext+0x2cae4/0x4338e8
[  574.034269] {bf3e1f64} _stext+0x2cde4/0x4338e8
[  574.038704] {bf3e1f8c} _stext+0x31acc/0x4338e8
[  574.043139] {bf3e1fac} _stext+0x10e8/0x4338e8
[  574.047486] Exception stack(0xbf3e1fb0 to 0xbf3e1ff8)
[  574.052528] 1fa0:                                     00000000 00000000 00000000 00000000
[  574.060689] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  574.068848] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[  574.075449] CPU3: stopping
[  574.078155] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G      D           5.6.3 #60
[  574.085449] Hardware name: Annapurna Labs Alpine
[  574.090059] {bf09bf34} _stext+0x97a4/0x4338e8
[  574.094409] {bf09bf3c} _stext+0x420060/0x4338e8
[  574.098931] {bf09bf4c} _stext+0xbef0/0x4338e8
[  574.103280] {bf09bf64} _stext+0x1b348c/0x4338e8
[  574.107802] {bf09bf7c} _stext+0x1acc/0x4338e8
[  574.112149] Exception stack(0xbf09bf80 to 0xbf09bfc8)
[  574.117193] bf80: 0056f0a8 00000000 0056f0a8 801142a0 bf09a000 00000008 80903e24 80903e60
[  574.125354] bfa0: 0000406a 412fc0f4 00000000 00000000 00000000 bf09bfd0 80106f60 80106f50
[  574.133512] bfc0: 60000013 ffffffff
[  574.136994] {bf09bfcc} _stext+0x6f50/0x4338e8
[  574.141343] {bf09bfd4} _stext+0x3a0d8/0x4338e8
[  574.145778] {bf09bfec} _stext+0x3a368/0x4338e8
[  574.150212] {bf09bff4} 0x10246c
[  574.153348] CPU0: stopping
[  574.156055] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G      D           5.6.3 #60
[  574.163348] Hardware name: Annapurna Labs Alpine
[  574.167958] {80901f04} _stext+0x97a4/0x4338e8
[  574.172307] {80901f0c} _stext+0x420060/0x4338e8
[  574.176829] {80901f1c} _stext+0xbef0/0x4338e8
[  574.181178] {80901f34} _stext+0x1b348c/0x4338e8
[  574.185699] {80901f4c} _stext+0x1acc/0x4338e8
[  574.190046] Exception stack(0x80901f50 to 0x80901f98)
[  574.195089] 1f40:                                     03e58ba8 00000000 03e58ba8 801142a0
[  574.203251] 1f60: 80900000 00000001 80903e24 80903e60 80824a38 412fc0f4 10c5387d 00000000
[  574.211411] 1f80: 00000000 80901fa0 80106f60 80106f50 60000013 ffffffff
[  574.218013] {80901f9c} _stext+0x6f50/0x4338e8
[  574.222361] {80901fa4} _stext+0x3a0d8/0x4338e8
[  574.226796] {80901fbc} _stext+0x3a368/0x4338e8
[  574.231231] {80901fc4} _sinittext+0x934/0x20d80
[  574.235820] save panic in NOR
[  574.238782] al_spi_flash_init
[  574.241751] ------------[ cut here ]------------
[  574.246358] kernel BUG at mm/vmalloc.c:2111!
[  574.250619] Internal error: Oops - BUG: 0 [#2] SMP ARM
[  574.255747] CPU: 2 PID: 263 Comm: sysinit Tainted: G      D           5.6.3 #60
[  574.263039] Hardware name: Annapurna Labs Alpine
[  574.267647] PC is at _stext+0xbd370/0x4338e8
[  574.271908] LR is at _stext+0xbd558/0x4338e8
[  574.276169] pc : [<801bd370>]    lr : [<801bd558>]    psr: 20000113
[  574.282422] sp : bf0af998  ip : ff800000  fp : bf0afab0
[  574.287636] r10: 809077a8  r9 : 00000000  r8 : c0800000
[  574.292848] r7 : 00000cc0  r6 : 00000001  r5 : fd882000  r4 : 00001000
[  574.299362] r3 : 00000400  r2 : 00000400  r1 : 00000001  r0 : 00001000
[  574.305874] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  574.312994] Control: 10c5387d  Table: 3975c06a  DAC: 00000051
[  574.318727] Process sysinit (pid: 263, stack limit = 0xed12ffa8)
[  574.324722] {bf0af9bc} _stext+0xbd558/0x4338e8
[  574.329157] {bf0af9d4} _stext+0x11e1c/0x4338e8
[  574.333592] {bf0af9f4} _stext+0x11ea0/0x4338e8
[  574.338036] {bf0afa04} al_spi_flash_init+0x28/0xac [flash@0x7f000000]
[  574.344470] {bf0afa1c} custom_spi_on+0x14/0x190 [flash@0x7f000000]
[  574.350642] {bf0afa24} panic_saver_release+0x110/0x1dc [panics@0x7f00f000]
[  574.357502] {bf0afa44} _stext+0x32ab4/0x4338e8
[  574.361937] {bf0afa64} _stext+0x32c70/0x4338e8
[  574.366372] {bf0afa74} _stext+0x32c8c/0x4338e8
[  574.370807] {bf0afa84} _stext+0x19b24/0x4338e8
[  574.375243] {bf0afaac} _stext+0x9a20/0x4338e8
[  574.379591] {bf0afae4} _stext+0xff90/0x4338e8
[  574.383940] {bf0afafc} _stext+0x102b0/0x4338e8
[  574.388375] {bf0afb3c} _stext+0x103f8/0x4338e8
[  574.392809] {bf0afb64} _stext+0x1a38/0x4338e8
[  574.397157] Exception stack(0xbf0afb68 to 0xbf0afbb0)
[  574.402198] fb60:                   00000000 07ffffff 00000002 00000003 00000000 bcdc4e00
[  574.410359] fb80: 00000002 bcefd6c0 8087d23c 00000004 8087d23c 00000000 00000000 bf0afbb8
[  574.418518] fba0: 8012c5c8 8012c610 60000093 ffffffff
[  574.423559] {bf0afbb4} _stext+0x2c610/0x4338e8
[  574.427994] {bf0afbe4} _stext+0x2c820/0x4338e8
[  574.432433] {bf0afbfc} switch_switchdev_event+0x1cc/0x244 [switch@0x7f0e6000]
[  574.439553] {bf0afc1c} _stext+0x32ab4/0x4338e8
[  574.443988] {bf0afc3c} _stext+0x32c70/0x4338e8
[  574.448423] {bf0afc4c} _stext+0x32c8c/0x4338e8
[  574.452865] {bf0afc5c} br_switchdev_fdb_notify+0xbc/0xc4 [bridge2@0x7f0f4000]
[  574.459993] {bf0afc74} br_fdb_find_port+0x73c/0xdb0 [bridge2@0x7f0f4000]
[  574.466687] {bf0afc9c} br_fdb_find_port+0xa88/0xdb0 [bridge2@0x7f0f4000]
[  574.473381] {bf0afd84} br_fdb_delete_by_port+0x88/0xb4 [bridge2@0x7f0f4000]
[  574.480335] {bf0afda4} br_device_event+0x1b0/0x1dc [bridge2@0x7f0f4000]
[  574.486935] {bf0afdc4} _stext+0x32ab4/0x4338e8
[  574.491370] {bf0afde4} _stext+0x32d28/0x4338e8
[  574.495805] {bf0afdf4} _stext+0x36124c/0x4338e8
[  574.500326] {bf0afe04} _stext+0x366d54/0x4338e8
[  574.504847] {bf0afe24} _stext+0x3673d0/0x4338e8
[  574.509368] {bf0afe3c} _stext+0x3e44c8/0x4338e8
[  574.513890] {bf0afe8c} _stext+0x3e66ac/0x4338e8
[  574.518411] {bf0afef4} _stext+0x3490fc/0x4338e8
[  574.522931] {bf0aff34} _stext+0xdd9cc/0x4338e8
[  574.527366] {bf0aff3c} _stext+0xdded0/0x4338e8
[  574.531801] {bf0affa4} _stext+0x1000/0x4338e8
[  574.536148] Exception stack(0xbf0affa8 to 0xbf0afff0)
[  574.541190] ffa0:                   7efffbd0 0002d390 00000003 00008914 7efffb88 7efffb18
[  574.549350] ffc0: 7efffbd0 0002d390 00000002 00000036 00000001 00000003 00000000 00000000
[  574.557509] ffe0: 0002d018 7efffb00 00015410 76fced14
[  574.562552] Code: e59f30fc e0033002 e3530000 0a000000 (e7f001f2)
[  574.568633] ---[ end trace 35b3c22b82377f69 ]---
[  574.574240] Kernel panic - not syncing: Fatal exception in interrupt

Device is RB4011 wifi model. 7.1beta6 works OK aside from this.

Looks like identical behaviour that I was seeing on my RB3011-iUAS-RM - Kernel panic was posted a number of posts up.

rz3dvp · Mon May 24, 2021 11:55 am

After update my RBM11G w/ R11e-LTE6 from beta5 to beta6 the LTE modem can't connect to BS. I'm downgrade to beta5 now.

elel · Mon May 24, 2021 12:00 pm

Can we say that MLAG is similar to stackable switches, or did I get it wrong?

Mon May 24, 2021 2:12 pm

Thanks jimmer and mducharme, this kernel panic after device reboot is reproduced in our labs. Hopefully, it will be fixed in the next release.

gdanov · Mon May 24, 2021 3:45 pm

After update my RBM11G w/ R11e-LTE6 from beta5 to beta6 the LTE modem can't connect to BS. I'm downgrade to beta5 now.

someone at MT could add "known problems" and reflect this in the changelog. Basic respect for your users.

infabo · Mon May 24, 2021 5:29 pm

Mikrotik could use the wiki to maintain such a list. Users of v7 would greatly benefit from such a list, as they would be aware of concrete issues. A single source to look up when you face an issue. That would have greatly helped me, as I suffered from kernel panic reboots for over a month. To only find out: fucking cake queue caused that and so many v7 users already knew about the cake queue issue already. But it is all scattered accross beta-release-forum-threads. Thats a mess.

And: it does not show basic respect for users only, in fact such a maintained list would show of professionalism. Mikrotik should not act like any 0815 enterprise corp, that just gives a fuck of users. Do it better, make things transparent.

doneware · Mon May 24, 2021 7:47 pm

After update my RBM11G w/ R11e-LTE6 from beta5 to beta6 the LTE modem can't connect to BS. I'm downgrade to beta5 now.

i also noticed a similar thing. my ltap mini was running 7.1b5, and i upgraded it to 7.1b6. it worked for 2-3 days, and after a reboot it suddenly got into a state, that the LTE modem kept saying "tx/rx circuits disabled". SIM PIN was OK, i even disabled it just to make sure.

it all boiled down to routeros saying "modem not initialised" if i wanted to do cell scan or operator scan. regardless what i did. i did a full reset (/system reset-config no-defaults=yes) and a modem reset via AT command "AT+RSTSET", none of this helped. rebooted / power cycled it, also the modem separately via /sys/routerboard/usb/bus-reset, still no improvement.
i felt puzzled as it clearly worked before and it seemed to be ok.
then i took a breath and downgraded it to 6.49b46, and everything works.

will try to reproduce and do some supout files for support

Alpenfreddy · Mon May 24, 2021 8:48 pm

After update my RBM11G w/ R11e-LTE6 from beta5 to beta6 the LTE modem can't connect to BS. I'm downgrade to beta5 now.
i also noticed a similar thing. my ltap mini was running 7.1b5, and i upgraded it to 7.1b6. it worked for 2-3 days, and after a reboot it suddenly got into a state, that the LTE modem kept saying "tx/rx circuits disabled". SIM PIN was OK, i even disabled it just to make sure.

it all boiled down to routeros saying "modem not initialised" if i wanted to do cell scan or operator scan. regardless what i did. i did a full reset (/system reset-config no-defaults=yes) and a modem reset via AT command "AT+RSTSET", none of this helped. rebooted / power cycled it, also the modem separately via /sys/routerboard/usb/bus-reset, still no improvement.
i felt puzzled as it clearly worked before and it seemed to be ok.
then i took a breath and downgraded it to 6.49b46, and everything works.

will try to reproduce and do some supout files for support

wAP ac LTE kit RBwAPGR-5HacD2HnD&R11e-LTE -> some behavior with 7.1b6 and LTE

Chateau RBD53G-5HacD2HnD-TC&EG12-EA -> LTE works with 7.1b6 even after a few days and several reboots

whatever · Mon May 24, 2021 10:06 pm

Exactly. L3 HW for IPv6 is on the roadmap.

That is great news. Will this include IPv6 fasttrack to allow firewall usage?

RavenWing71 · Tue May 25, 2021 2:19 am

My OSPF v2 experience with upgrading from v7.1beta5 to v7.1beta6.

First off, the interface-templates lost all references to Interface or Network. So as @mducharme suggested, if you are using OSPF, export your OSPF config to file. Remove your OSPF config. Upgrade to v7.1beta6. Import your OSPF config from the file. I did it the hard way by combing the running config and adding the missing bits.

One of the bugs that seems to be fixed is with large network prefixes being specified in interface-templates. Example, I have a /19 IPv4 global subnet. I attached a /26 portion to an interface. If my Interface-Template specified a network of x.x.x.x/24, using a /24 that covered the /26, everything was fine. But if my interface-template specified a network of x.x.x.x/19, again covering the /26, then OSPF would not create the Interfaces entry for the interface. This has been fixed in v7.1beta6.

syadnom · Tue May 25, 2021 4:37 am

Any news on IPv6 hardware offload? That's what I'm waiting on to start testing. I want the hardware offload for an ospfv3 routed network and with no fastpath support for ipv6 in routeros6 (or 7...) it kinda disqualifies the hardware.

mducharme · Tue May 25, 2021 5:21 am

Any news on IPv6 hardware offload? That's what I'm waiting on to start testing. I want the hardware offload for an ospfv3 routed network and with no fastpath support for ipv6 in routeros6 (or 7...) it kinda disqualifies the hardware.

OSPFv3 is still not working in v7. Given that the beta releases have been about 2 months apart from one another, the next will likely be mid to late July, unless they start speeding up.

Tue May 25, 2021 9:59 am

As I already said, L3 HW offloading for IPv6 is on the roadmap. Actually, it is the next big feature to be done for L3 HW. However, do not expect it in the next beta - the expected development effort is extensive, and then testing (you may not believe, but we are actually testing our firmware).

Initially, IPv6 HW offloading will come in full routing mode only (l3-hw-offloading=yes for the switch and ports; no firewall support). We cannot do Fasttrack offloading until the software IPv6 Fasttrack gets implemented. The latter is on the TODO list (backlog) but not on the roadmap yet. I suggest creating a feature request thread on RouterOS v7 forums for IPv6 Fasttrack - if it gets enough user attention, it might receive a priority boost.

Jotne · Tue May 25, 2021 11:47 am

In v7, will there be done any to logging.

Like using RFC for time log format and fix the logging prefix mess?
When I made a support request for it, I was told that you would work on it.

viewtopic.php?t=124291

xvo · Tue May 25, 2021 2:14 pm

For anyone struggling with OSPF interface-templates.

Setting interfaces=all (instead of unset interfaces) works too if you want to specify only networks.
And vice versa - setting networks=0.0.0.0/0 (instead of unset networks) works if you want to specify interfaces directly.
This way it won't reset to improper values any time something is changed in the template from winbox GUI.

The reason is that logic AND is used with this fields, and interface has to fall under both condition.
While default interfaces="" or networks="" wrongly equals to "none", i guess.

OlofL · Tue May 25, 2021 5:35 pm

Too many complaints about beta or alpha.
It is a testing release so bad things happen. Whether it is beta or alpha, I do not see the point, you install it and take the risk of things not working as supposed to. Remember that mikrotik tries to put lot of features in one box so it is not that easy to fix lots of them in one shot. It is not like other vendors who put a couple of features in one router and that is it.
Instead of many complaints, try to cooperate and pinpoint the issue if you can, or write to support for the issue you are experiencing, that is how testing works. I do not see you trying to solve the issues but venting your frustration in the forum which has been said a thousands times that is just a user forum, you need to write to support for problem solving if not found in the forum.

It's marketed as beta, and there is hardware that is shipped with beta software!! Whatever it is, Mikrotik has decided to ship beta/testing/whatever software to it's end customers. Of course you expect a more stable product then.

syadnom · Tue May 25, 2021 6:54 pm

@raimondsp thanks for the info. Do you guys expect this by year end? (HW IPv6)

pushdrt · Tue May 25, 2021 7:48 pm

Good evening, I am using the rbm11g router, this router has 7.1beta6 firmware installed
The Quectel EC25-E module is connected to this device in mbim mode, but there is no connection. The module works, but the IP address of the provider is not issued, an error in the mbim operation is displayed
https://drive.google.com/file/d/1Cm53aY ... sp=sharing
https://drive.google.com/file/d/11HamUs ... sp=sharing

RavenWing71 · Tue May 25, 2021 10:51 pm

My OSPFv3 experience with v7.1beta6 on my RB493AH (MIPSBE 64MB RAM)

OSPFv2 was working fine.

/routing ospf instance
add name=OSPFv2 router-id=TestMTik
/routing ospf area
add instance=OSPFv2 name=Backbone-v2
/routing ospf interface-template
add area=Backbone-v2 interfaces=ether1
add area=Backbone-v2 interfaces=Loopback passive
add area=Backbone-v2 networks=x.x.x.x/19 passive

I enabled Safe Mode in Winbox.
Using the Winbox terminal:

I added an OSPFv3 Instance:

routing/ospf/instance/add name=OSPFv3 router-id=TestMTik version=3

And all was well. The instance appears in Winbox.

I added an OSPFv3 Area:

routing/ospf/area/add instance=OSPFv3 name=Backbone-v3

The new Area did not show up in Winbox. OSPFv2 stops interacting with it's neighbors. Winbox looses connection due to the missing routes.

Using the Serial Console:

routing/ospf/export

The header with model and serial number displays immediately. Then nothing for a while.
After about 10 minuets it gives "#error exporting /routing/ospf/area" and given more time, it goes through the list of subsections for OSPF with similar errors.

The Winbox that I enabled safe mode in says that it's been 40 minutes since it lost connection. The automatic reboot that is supposed to occur upon loss of connection has not happened. I'll be using the console to restore a backup from before the upgrade to v7.1beta6 which did not have OSPFv3 configured.

Edit: It took more than 10 minutes to produce, but I got a support file from when OSPF seized up before I restored the backup. It's attached here.

evbocharov · Tue May 25, 2021 11:12 pm

RB4011iGS+5HacQ2HnD
v7.1beta6 + wave2

errors in log:
memory - script - warning - DefConf gen: Unable to find wireless interface(s)
memory - system - error - critical - error while running customized default configuration script: interrupted

Name wifi is default - wifi1

mikegleasonjr · Wed May 26, 2021 1:22 am

Meanwhile I am trying to support an openwrt project that would bring better wifi drivers to my cAP acs at home.
https://github.com/openwrt/openwrt/pull/4055 => Nice to see that work was restarted for getting a port done. The actual goal would be to get it into official 21.02 branch in order to reach long term support.

I installed OpenWRT on both my CapAcs this weekend and I am truly impressed. My use case is they are dumb access points with 2 VLANs, one for my private network and one for my guest network. The transition went smoothly, the wife didn't even notice.

So roaming is quite impressive. I start an infinite iperf3 test on my phone to a wired server and I can move around and see in real time the transition to 2.4 GHz and 5 GHz, whether it's on the same access point or not.

Prior to that, I had to tweak the DBI on the radios because my ac devices were never connecting to the 5 GHz radio. (Minus 7 db on the 2.4 GHz). Now I don't have to do that and my coverage is better. Also prior to that, my phone would get stuck on the same AP for a really long time.

It has been stable for 3 days now. I get around 400 mbit on my macbook pro and 200-300 on my phone.

mducharme · Wed May 26, 2021 2:39 am

RB4011iGS+5HacQ2HnD
v7.1beta6 + wave2

errors in log:
memory - script - warning - DefConf gen: Unable to find wireless interface(s)
memory - system - error - critical - error while running customized default configuration script: interrupted

Probably if you are doing a factory reset to load the DefConf, you may need to do it without the wifiwave2 package enabled, then enable the wifiwave2 package afterwards.

mducharme · Wed May 26, 2021 2:40 am

The Winbox that I enabled safe mode in says that it's been 40 minutes since it lost connection. The automatic reboot that is supposed to occur upon loss of connection has not happened. I'll be using the console to restore a backup from before the upgrade to v7.1beta6 which did not have OSPFv3 configured.

It isn't just with yours - this happens to everybody with beta6 from what I can tell. I reported this exact issue already earlier in this thread, here: viewtopic.php?f=1&t=175369&p=859147#p858140

Wed May 26, 2021 8:53 am

@raimondsp thanks for the info. Do you guys expect this by year end? (HW IPv6)

That's the plan. Unless something utterly goes wrong.

lordzar · Wed May 26, 2021 9:44 am

I posted the same issue with an EC-25V. Worked fine under beta5 and stopped working under beta6.
Downgraded and everything is running again.

Good evening, I am using the rbm11g router, this router has 7.1beta6 firmware installed
The Quectel EC25-E module is connected to this device in mbim mode, but there is no connection. The module works, but the IP address of the provider is not issued, an error in the mbim operation is displayed
https://drive.google.com/file/d/1Cm53aY ... sp=sharing
https://drive.google.com/file/d/11HamUs ... sp=sharing

akrao · Thu May 27, 2021 1:30 pm

That's the plan. Unless something utterly goes wrong.

Are the DX3000/2000 Series products capable of HW IPv6 routing as well?

If yes, and if implementation is successful, do you expect they'll hold at least 1000-2000 IPv6 prefixes?

fbl · Thu May 27, 2021 1:50 pm

Had to downgrade back to beta2 again. :-(
With beta6, I at least have been able to redistribute routes to BGP neighbours again. Haven't had any success with beta3-beta5.

However, compared to beta2, two massive issues occured:
- Forwarding of IPv6/GRE packets was super slow. Only got 20-30mbit/s inside the GRE, compared to over 800mbit/s (limited by the GRE peer) with beta2.
- Output filters sometimes lead to BGP crashing(?). BGP Sessions were flapping, BGP neighbors report "Connections closed" errors. I haven't been able to isolate the cause of this issue, but sessions have been stable without output filters (-> no announcements), so it probably has something to do with route exports.

I'm running RouterOS 7.1 on a CCR1036-8G-2S+ with up-to-date Routerboard firmware.

Thu May 27, 2021 2:38 pm

That's the plan. Unless something utterly goes wrong.

Are the DX3000/2000 Series products capable of HW IPv6 routing as well?

If yes, and if implementation is successful, do you expect they'll hold at least 1000-2000 IPv6 prefixes?

The DX3000/2000 Series products are capable of HW IPv6 routing (no HW Fasttrack, though). Both IPv4 and IPv6 routes share the same hardware memory; IPv6 routes occupy 4x more space than IPv4. If I'm not mistaken, the DX3000/2000 series products will be able to hold up to 3328 IPv6 prefixes (13312 / 4).

Please take into account that the DX8000 series have a completely different hardware routing engine than DX3000/2000, so we have to write two L3 HW offload implementations. We are focusing on the DX8000 first (CRS309, CRS317, etc.), then move on to DX3000/2000 (CRS305, CRS328, etc.).

robertpenz · Thu May 27, 2021 8:18 pm

IPv6 forward is not working on Hex - is this a known problem and is there a workaround for it?

syadnom · Thu May 27, 2021 9:28 pm

The DX3000/2000 Series products are capable of HW IPv6 routing (no HW Fasttrack, though). Both IPv4 and IPv6 routes share the same hardware memory; IPv6 routes occupy 4x more space than IPv4. If I'm not mistaken, the DX3000/2000 series products will be able to hold up to 3328 IPv6 prefixes (13312 / 4).

Please take into account that the DX8000 series have a completely different hardware routing engine than DX3000/2000, so we have to write two L3 HW offload implementations. We are focusing on the DX8000 first (CRS309, CRS317, etc.), then move on to DX3000/2000 (CRS305, CRS328, etc.).

What's this mean for routeros though? (DX3000/2000 devices) Will we see hardware ipv6 routing so long as we either don't configure any ipv6 firewall rules (ie, no way to get the route 'out' of the CPU) or if we do a VRF or something? Routing via CPU on these devices is abysmal, currently hanging a router-on-a-stick off them but I'd really like to ditch this process and get hardware offload onboard. NP16 is a fantastic device so this is a big ticket item for me and a lot of wisps.

For another network, I use IPv6 as an underlay so customers are isolated in a tunnel at the DMARC (can't wait for vxlan over IP/evpn etc hopefully in hardware...SRv6 even better.). Similar question here in that I mostly want hardware IPv6 routing and a basic firewall for packets targeting the device just to be on the safe side. Generally packets will be encapsulated so no worries. Also, this is likely a DX8xxx series switch, probably CRS309 for those SFP+ ports. It's not clear if you we're saying that only the DX2/3 series can't do fasttrack while the DX8x CAN.

evbocharov · Thu May 27, 2021 10:41 pm

RB4011iGS+5HacQ2HnD
v7.1beta6 + wave2

1) errors in log:
memory - script - warning - DefConf gen: Unable to find wireless interface(s)
memory - system - error - critical - error while running customized default configuration script: interrupted

Name wifi is default - wifi1

Reset configuration - No default conf - couldn't help

2) Lan connection + latest Winbox 3.27 - couldn't reboot a RB4011iGS+5HacQ2HnD. Only wifi device can reboot!

pe1chl · Fri May 28, 2021 12:14 am

@raimondsp thanks for the info. Do you guys expect this by year end? (HW IPv6)
That's the plan. Unless something utterly goes wrong.

Well I do not determine the priorities and I do not know about that big customer that wanted hw acceleration, but I would (and I think I am not the only one) prefer this sequence of v7 implementation:
1. finish the porting of everything that was in v6 so it can be realistically BETA-tested (maybe with exception of the routing code)
2. add/finish the major features that have been promised for the past 5+ years to be available in v7 (new routing, new VPN protocols, better IPv6 support etc)
3. work on completely new features that were not in v6 and now become possible (wifi wave2, hw accel etc)

I do appreciate that MikroTik work on new (for them) features like hw accel, but in the meantime I (and others) am waiting on features were promised for v7, are available as unfinished teasers, but now have to wait longer and longer for a stable version because the effort goes into features I don't need on router or wifi devices...

mducharme · Fri May 28, 2021 4:51 am

Well I do not determine the priorities and I do not know about that big customer that wanted hw acceleration, but I would (and I think I am not the only one) prefer this sequence of v7 implementation:
1. finish the porting of everything that was in v6 so it can be realistically BETA-tested (maybe with exception of the routing code)
2. add/finish the major features that have been promised for the past 5+ years to be available in v7 (new routing, new VPN protocols, better IPv6 support etc)
3. work on completely new features that were not in v6 and now become possible (wifi wave2, hw accel etc)

I do appreciate that MikroTik work on new (for them) features like hw accel, but in the meantime I (and others) am waiting on features were promised for v7, are available as unfinished teasers, but now have to wait longer and longer for a stable version because the effort goes into features I don't need on router or wifi devices...

Although I don't know what their priorities are, one issue that i might see with where you place #1 is that to finish porting everything that is in v6 (meaning the various kernel modifications), they would lock themselves down to a particular kernel version. They might have to redo the modifications in #1 later if they wanted to upgrade the kernel. I suspect they are doing 2 and some of 3 beforehand on purpose, so that they can give the kernel one final update to whatever the latest LTS kernel is, before porting the modifications over, like GRE keepalives. This is just a guess, but otherwise, we would likely have seen GRE keepalives already. This means it would take longer for us to get a v7 with all the kernel modifications to v6, but we could get a newer kernel sooner.

Once v7 stabilizes, we are more likely to see kernel updates only very infrequently. I would rather see the kernel be as up to date as possible (as far as LTS goes) before that happens.

Fri May 28, 2021 9:08 am

What's this mean for routeros though? (DX3000/2000 devices) Will we see hardware ipv6 routing so long as we either don't configure any ipv6 firewall rules (ie, no way to get the route 'out' of the CPU) or if we do a VRF or something? Routing via CPU on these devices is abysmal, currently hanging a router-on-a-stick off them but I'd really like to ditch this process and get hardware offload onboard. NP16 is a fantastic device so this is a big ticket item for me and a lot of wisps.

For another network, I use IPv6 as an underlay so customers are isolated in a tunnel at the DMARC (can't wait for vxlan over IP/evpn etc hopefully in hardware...SRv6 even better.). Similar question here in that I mostly want hardware IPv6 routing and a basic firewall for packets targeting the device just to be on the safe side. Generally packets will be encapsulated so no worries. Also, this is likely a DX8xxx series switch, probably CRS309 for those SFP+ ports. It's not clear if you we're saying that only the DX2/3 series can't do fasttrack while the DX8x CAN.

Here is the documentation: L3 Hardware Offloading. Fasttrack hardware offloading is available only on DX8000 devices. On DX3000/DX2000, Fasttrack connections do not get offloaded and are processed by the CPU.

Summary:

IPv4 hardware routing is available on all CRS3xx devices.
IPv4 Fasttrack offloading is available only on DX8000 devices. DX3000/DX2000 hardware does not support it.
IPv6 hardware routing is not available yet. It should be released later this year.
Theoretically, the hardware of the DX8000 series support IPv6 Fasttrack offloading. However, IPv6 Fasttrack needs to be implemented on the software side first.

Fri May 28, 2021 9:13 am

Well I do not determine the priorities and I do not know about that big customer that wanted hw acceleration, but I would (and I think I am not the only one) prefer this sequence of v7 implementation:
1. finish the porting of everything that was in v6 so it can be realistically BETA-tested (maybe with exception of the routing code)
2. add/finish the major features that have been promised for the past 5+ years to be available in v7 (new routing, new VPN protocols, better IPv6 support etc)
3. work on completely new features that were not in v6 and now become possible (wifi wave2, hw accel etc)

I do appreciate that MikroTik work on new (for them) features like hw accel, but in the meantime I (and others) am waiting on features were promised for v7, are available as unfinished teasers, but now have to wait longer and longer for a stable version because the effort goes into features I don't need on router or wifi devices...

I want to quote Brook's law:

While it takes one woman nine months to make one baby, "nine women can't make a baby in one month"

In other words, the development takes time, and assigning more developers to the same task is not always effective and sometimes even counterproductive. For example, if we had moved developers from Wireguard or L3HW Offloading to aid in routing protocols development, would the latter be finished by this day? Maybe, or maybe not. However, the one is certain: there wouldn't be Wireguad and L3HW now. I can assure you that MikroTik did NOT sacrifice the existing (in v6) features to favor the new ones. On the contrary, the developer staff has been greatly expanded. For instance, such new features as Wireguard, RestAPI, or L3 HW Offloading have been developed by newly hired developers while the existing staff continued doing #1 and #2 of your list.

pe1chl · Fri May 28, 2021 11:02 am

In other words, the development takes time, and assigning more developers to the same task is not always effective and sometimes even counterproductive. For example, if we had moved developers from Wireguard or L3HW Offloading to aid in routing protocols development, would the latter be finished by this day? Maybe, or maybe not.

I know about that, I have developed software for many years, but I also recognize the phenomenon that it is much more attractive to work on shiny new features than to make existing features that were broken by accident or because of unfinished work to be working again.

One example is mentioned above: GRE keepalives. That would have required a kernel patch, and apparently this patch has not yet been ported to the new kernel.
But it would seem to be a task requiring at most a couple of hours, and not fixing it will block some users from testing the new version.
That is why I suggest making everything from v6 OK again so you can have existing v6 users betatesting v7 and reporting any found issues, while in the meantime you continue development of isolated new features.
To me that appears to be a better sequence than to work in parallel on many things and then after X time suddenly release a completely new version.

It is not like the lead time for v7 is short by any means. We have been promised a v7 that fixes everything for well over 5 years (did not look it up, I think it is way more than that), so by now one would expect that the basic task of migrating the codebase from v6 to v7 is well understood within MikroTik. After all it was postponed many times, probably for good reasons (the overwhelming amount of internal patches that were made to opensource software used in RouterOS without being sent back to upstream, and that all have to be reviewed before they can be applied to current versions of the same software).

pe1chl · Fri May 28, 2021 11:07 am

Although I don't know what their priorities are, one issue that i might see with where you place #1 is that to finish porting everything that is in v6 (meaning the various kernel modifications), they would lock themselves down to a particular kernel version. They might have to redo the modifications in #1 later if they wanted to upgrade the kernel.

That is the basic problem behind kernel upgrades in RouterOS and it is caused by working on a fork of the Linux kernel instead of submitting patches back to the kernel developers and getting them accepted.
I understand why they do that, because it is very difficult to get patches accepted and it will take several developer FTE extra to coordinate that, probably much more than to re-develop the patches every couple of years to track the kernel.
I think now a new kernel version for v7 has been decided (a long-term supported version) and only security fixes from upstream will be integrated into their own fork.
We will have that same kernel (at least that version number) for the next 5-10 years.

akrao · Fri May 28, 2021 2:59 pm

The DX3000/2000 Series products are capable of HW IPv6 routing (no HW Fasttrack, though). Both IPv4 and IPv6 routes share the same hardware memory; IPv6 routes occupy 4x more space than IPv4. If I'm not mistaken, the DX3000/2000 series products will be able to hold up to 3328 IPv6 prefixes (13312 / 4).

Please take into account that the DX8000 series have a completely different hardware routing engine than DX3000/2000, so we have to write two L3 HW offload implementations. We are focusing on the DX8000 first (CRS309, CRS317, etc.), then move on to DX3000/2000 (CRS305, CRS328, etc.).

Thank you for the fast and clear response!

We are working towards transitioning to SRv6 on our WISP mesh and we hope the netPower 16P can play a big part in it as P router on every node, along with a router-on-a-stick as PE device.

Spring00 · Fri May 28, 2021 4:14 pm

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

What's new in 7.1beta6 (2021-May-18 14:49):

!) added support for Let's Encrypt certificate generation;
!) added L3 HW support for all CRS3xx devices;
!) added MLAG support for CRS3xx devices (CLI only);
!) ported features and fixes introduced in v6.49;
*) other minor fixes and improvements;

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

Is there any hope for jumbo frames and L3 HW to work at the same time?

Fri May 28, 2021 4:22 pm

Is there any hope for jumbo frames and L3 HW to work at the same time?

Yes, it is also on the roadmap.

gdanov · Fri May 28, 2021 4:28 pm

Although I don't know what their priorities are, one issue that i might see with where you place #1 is that to finish porting everything that is in v6 (meaning the various kernel modifications), they would lock themselves down to a particular kernel version. They might have to redo the modifications in #1 later if they wanted to upgrade the kernel.
That is the basic problem behind kernel upgrades in RouterOS and it is caused by working on a fork of the Linux kernel instead of submitting patches back to the kernel developers and getting them accepted.
I understand why they do that, because it is very difficult to get patches accepted and it will take several developer FTE extra to coordinate that, probably much more than to re-develop the patches every couple of years to track the kernel.
I think now a new kernel version for v7 has been decided (a long-term supported version) and only security fixes from upstream will be integrated into their own fork.
We will have that same kernel (at least that version number) for the next 5-10 years.

What do they expect to be different this time? This sounds like the same process that got us here — 5 years of unprocessed feature backlog, big bang release, etc.

Spring00 · Fri May 28, 2021 4:32 pm

Is there any hope for jumbo frames and L3 HW to work at the same time?

Yes, it is also on the roadmap.

I look forward to it very much, it is my biggest obstacle to using L3 HW

syadnom · Fri May 28, 2021 6:53 pm

keep in mind that mikrotik doesn't have to 'port' a lot of things from v6, they have up-to-date mainline packages they can bring in and just 'port' the UI for it. ie, they aren't going to re-implement openvpn from v6.... they'll bring in mainline openvpn w/o having to do any weird stuff to it because they aren't held back by the old kernel.

A LOT of things are already much more mature.

I'm sure the devs, who are doing great work, are focusing on the fundamentals first because other things depend on them. They likely, as hinted at by raimondsp, have a core group of devs on this part and it takes the time it takes. They can add more devs, but those devs will need to work on the other pieces like vxlan or openvpn and so on and they aren't tied so tightly into the core group as their packages don't need to be tightly integrated like routing+hw offload does for example.

felixka · Fri May 28, 2021 7:01 pm

Although I don't know what their priorities are, one issue that i might see with where you place #1 is that to finish porting everything that is in v6 (meaning the various kernel modifications), they would lock themselves down to a particular kernel version. They might have to redo the modifications in #1 later if they wanted to upgrade the kernel.
That is the basic problem behind kernel upgrades in RouterOS and it is caused by working on a fork of the Linux kernel instead of submitting patches back to the kernel developers and getting them accepted.
I understand why they do that, because it is very difficult to get patches accepted and it will take several developer FTE extra to coordinate that, probably much more than to re-develop the patches every couple of years to track the kernel.
I think now a new kernel version for v7 has been decided (a long-term supported version) and only security fixes from upstream will be integrated into their own fork.
We will have that same kernel (at least that version number) for the next 5-10 years.

Having contributed to the Kernel before I would say the process works pretty well, as long as you are able to align your own development processes with it.
I would argue MikroTik has about as much work with maintaining a fork of their own as it would have putting everything upstream.
I believe MikroTik would have a tougher time because they simply aren't producing the quality required to successfully upstream kernel changes. This is judging from the GPL source drops I have seen (MikroTik's rocky relationship with the GPL aside). A lot of the modifications they do is to integrate upstream SoC vendor's architecture support and workarounds and hacks required to support quirky designs.
I can see how not bothering to upstream these changes can reduce external dependencies and friction. And it is my observation that this aligns well with MikroTik's culture of taking things in, working on them in isolation and then presenting the world with what they came up with. It seems to be working well for MikroTik and it's probably what makes RouterOS the unique Frankenstein of a router platform we know and love.

syadnom · Fri May 28, 2021 7:15 pm

@felixka
should be noted that when Mikrotik got into this hardware vendors weren't "linux first". Many MIPS platforms had other kernels as their first target (vxworks, qnx, highly customized essentially forked linux kernel) so they had to do serious work on them and then linux was basically ported to that platform.

Today, it's linux first. chipset vendors are already working on mainline kernel support before their SoC comes out and openwrt is probably going to run it on day 1. There's an SDK to integrate with on day 1. Marvel drops a new SoC, you can probably get your system running on it in a day by building a kernel targeting it.

It's still dev work for sure, but instead of kernel patches and having to run your own fork, you're probably using a a very near mainline kernel and putting your efforts into your own kit using the vendor SDKs. Likely no less effort up-front, but also way less effort in the future because maintaining that 'forked' kernel isn't necessary. I'm sure there are little things that need address patching hardware support in and bug squashing but nothing like running your own fork.

Jotne · Fri May 28, 2021 7:36 pm

keep in mind that mikrotik doesn't have to 'port' a lot of things from v6

They have removed IP accounting.

pe1chl · Fri May 28, 2021 11:22 pm

keep in mind that mikrotik doesn't have to 'port' a lot of things from v6, they have up-to-date mainline packages they can bring in and just 'port' the UI for it. ie, they aren't going to re-implement openvpn from v6.... they'll bring in mainline openvpn w/o having to do any weird stuff to it because they aren't held back by the old kernel.

Incorrect. RouterOS does not run the opensource openvpn implementation, it has its own crippled version.
And it was already rewritten for v7 it seems.
What I mean with implementing the v6 features is to make everything that was done in v6 by patching the kernel and other software again working in v7, either by reworking the patches or maybe by using whatever became available in newer kernel and software from upstream.
Just so that v7 can be realistically used and tested.

pe1chl · Fri May 28, 2021 11:26 pm

Having contributed to the Kernel before I would say the process works pretty well, as long as you are able to align your own development processes with it.
I would argue MikroTik has about as much work with maintaining a fork of their own as it would have putting everything upstream.

I don't mean work in the development, but work w.r.t. convincing kernel developers that some addition is a good idea, that it should not be done in a
different way, that the coding style is what the reviewer wants to see, that the documentation is according to the required templates, etc.
This can make submitting a 5-line patch into a long discussion and a lot of work, and an understandable decision is to just not bother with it.

syadnom · Sat May 29, 2021 2:44 am

you guys are way too deep in the weeds here. In the past maybe a bunch of kernel patches were necessary but today the kernel is really mature and most anything mikrotik wants to do is likely in mainline already, else it's being handled by the SoC vendors because they need that feature to work too.

mducharme · Sat May 29, 2021 3:05 am

you guys are way too deep in the weeds here. In the past maybe a bunch of kernel patches were necessary but today the kernel is really mature and most anything mikrotik wants to do is likely in mainline already, else it's being handled by the SoC vendors because they need that feature to work too.

I'm pretty sure none of these are in mainline, even today: PPP BCP, GRE keepalives, iptables and ebtables "set priority" and other priority related handling. Probably more things aside from those.

For something like GRE keepalives I can a potential reason for hesitation to add it to the kernel - it is a Cisco proprietary extension and is not part of the normal GRE standard. They may say that Linux GRE should only support what is part of the standard and not support things that Cisco added to it. For BCP, not many people use it, and they could argue it is not worth including because it is so rarely used.

Reiney · Sat May 29, 2021 7:05 am

Hi All ...

I'm trying desperately to get a v6 config running on v7 beta 6. I need OSPF and BGP to be working and
I am almost there; except I can't get outgoing BGP route filters to work. The session to my test router
is up, and my input filters work and I can receive route updates. I can send updates as well but not
filter them. If I put them in the main routing table as blackhole routes, they are announced and my test
router receives them. Take 'em out of routing table; they go away on the test router. Nothing I seem
to do in /routing/filter/rule with the "cmcs-out" chain makes any difference. I am testing with the first
entry for 207.225.52.0/24. I've also eliminated all rules except the last default reject.

Thanks in advance!
Reiney

================================================

[admin@7.1-tst] /routing/bgp/template> print
Flags: * - default; X - disabled, I - inactive
0 * name="default" no-client-to-client-reflection=no routing-table=main router-id=63.225.11.26 as=395245

----------

[admin@7.1-tst] /routing/bgp/connection> print
Flags: D - dynamic, X - disabled, I - inactive
0 name="cmcs"
remote.address=65.19.14.33 .as=14818
local.default-address=65.19.14.34 .role=ebgp-peer
connect=yes listen=yes routing-table=main router-id=63.225.11.26 as=395245 redistribute=static
output.filter=cmcs-out-select
input.filter=bgp-in

1 name="lumen"
remote.address=67.132.229.1 .as=209
local.default-address=67.132.229.2 .role=ebgp-peer
routing-table=main router-id=63.225.11.26 as=395245
output.filter=lumen-out-select
input.filter=bgp-in

----------

[admin@7.1-tst] /routing/filter/rule> print where chain=cmcs-out
Flags: X - disabled, I - inactive
5 chain=cmcs-out rule=if ([prfx value=dst<subsumes>207.225.52.0/24]) then={ action reject}

6 chain=cmcs-out rule=if ([prfx value=dst<subsumes>63.229.162.0/24]) then={ action accept }

7 chain=cmcs-out rule=if ([prfx value=dst<subsumes>63.233.220.0/23]) then={ action accept }

8 chain=cmcs-out rule=if ([prfx value=dst<subsumes>65.19.8.0/23]) then={ action accept }

9 chain=cmcs-out rule=action do=reject

----------

[admin@7.1-tst] /routing/filter/select-rule> print
Flags: X - disabled, I - invalid
0 chain=cmcs-out-select do-where=cmcs-out

----------

[admin@7.1-tst] /routing/bgp/session> print
Flags: E - established
0 E remote.address=65.19.14.33 .as=14818 .id=1.2.3.4 .refused-cap-opt=no .capabilities=mp,rr,as4
.messages=31 .bytes=674 .eor=""
local.role=ebgp-peer .address=65.19.14.34 .as=395245 .id=63.225.11.26 .capabilities=mp,rr,gr,as4
.messages=30 .bytes=648 .eor=""
output.procid=20 .filter=#e0e6289500011128
input.procid=20 .filter=bgp-in ebgp
hold-time=3m keepalive-time=1m

ihaveproblems · Sun May 30, 2021 1:24 am

Hello,

After upgrading my 4011 (from stable) I noticed CPU usage jumped from 0-1% all round to constant 7-10% (one core - cpu0 - is always 20-30%). "Networking" is taking 60% of that.
Has anyone else ran into a similar issue? Any ideas on why this could be happening and where to start looking?

guipoletto · Sun May 30, 2021 12:38 pm

Are there plans for IPV6 address delegation via DHCP?