Community discussions

MikroTik App
 
User avatar
emils
Forum Veteran
Forum Veteran
Topic Author
Posts: 906
Joined: Thu Dec 11, 2014 8:53 am

v7.1beta6 [development] is released!

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
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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
Frequent Visitor
Frequent Visitor
Posts: 62
Joined: Sun Feb 15, 2015 11:35 pm

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

Wed May 19, 2021 11:39 am

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

Documentation pleaseeeee.
 
huntermic
Member Candidate
Member Candidate
Posts: 111
Joined: Wed Oct 26, 2016 3:42 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 62
Joined: Sun Feb 15, 2015 11:35 pm

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

Wed May 19, 2021 11:48 am

no needed found it:
certificate/enable-ssl-certificate dns-name=
 
User avatar
ufm
Member Candidate
Member Candidate
Posts: 103
Joined: Fri Nov 15, 2013 12:02 pm
Location: Ukraine

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

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);
👍
 
User avatar
macgaiver
Forum Guru
Forum Guru
Posts: 1764
Joined: Wed May 18, 2005 5:57 pm
Location: Sol III, Sol system, Sector 001, Alpha Quadrant

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

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
Frequent Visitor
Frequent Visitor
Posts: 62
Joined: Sun Feb 15, 2015 11:35 pm

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

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
just joined
Posts: 19
Joined: Sat Jan 16, 2021 7:31 pm

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

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
Member Candidate
Member Candidate
Posts: 111
Joined: Wed Oct 26, 2016 3:42 pm

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

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.
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1237
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

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

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
just joined
Posts: 12
Joined: Sun Sep 20, 2020 5:57 pm

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

Wed May 19, 2021 1:05 pm

MLAG support for CRS3xx devices (CLI only); - how to test it ?
 
mikegleasonjr
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Tue Aug 07, 2018 3:14 am

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

Wed May 19, 2021 1:06 pm

Well Cake QoS crashes routeros
Does it crashes this beta (beta6) as well?
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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).
 
User avatar
kiler129
Member
Member
Posts: 352
Joined: Tue Mar 31, 2015 4:32 pm
Location: IL, USA
Contact:

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

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.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

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

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??
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1237
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

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

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.
 
User avatar
ErfanDL
Member
Member
Posts: 366
Joined: Thu Sep 29, 2016 9:13 am

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

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 :))
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26293
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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!
 
User avatar
FToms
MikroTik Support
MikroTik Support
Posts: 87
Joined: Fri Jul 24, 2020 3:28 pm

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

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
just joined
Posts: 9
Joined: Wed Apr 04, 2018 4:10 pm

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

Wed May 19, 2021 2:04 pm

Is cake crashing RoS with beta6?
 
User avatar
ErfanDL
Member
Member
Posts: 366
Joined: Thu Sep 29, 2016 9:13 am

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

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 ?
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 26293
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

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

Wed May 19, 2021 2:09 pm

FToms already answered this above
 
User avatar
jimmer
just joined
Posts: 19
Joined: Wed Mar 06, 2019 10:06 am
Location: Tasmania, Australia

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

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
Member Candidate
Member Candidate
Posts: 113
Joined: Mon Oct 12, 2015 2:37 pm

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

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
newbie
Posts: 45
Joined: Thu Oct 13, 2011 10:43 am

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

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...
 
User avatar
jimmer
just joined
Posts: 19
Joined: Wed Mar 06, 2019 10:06 am
Location: Tasmania, Australia

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

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
Last edited by jimmer on Wed May 19, 2021 3:11 pm, edited 1 time in total.
 
aussetg
just joined
Posts: 19
Joined: Sat Jan 16, 2021 7:31 pm

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

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
just joined
Posts: 15
Joined: Wed Nov 11, 2020 12:24 pm

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

Wed May 19, 2021 3:50 pm

My OSPF stoped working after upgrade. When I downgrade back to 7.1beta5 it works again.
 
User avatar
StubArea51
Trainer
Trainer
Posts: 1739
Joined: Fri Aug 10, 2012 6:46 am
Location: stubarea51.net
Contact:

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

Wed May 19, 2021 3:58 pm

Thanks for the new features like MLAG!

Were the issues with OSPFv3 checksum fixed?
 
rpingar
Long time Member
Long time Member
Posts: 592
Joined: Fri May 28, 2004 2:46 pm
Location: Italy

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

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
just joined
Posts: 13
Joined: Wed Feb 06, 2013 3:45 pm

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

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
Long time Member
Long time Member
Posts: 601
Joined: Sat Nov 29, 2014 7:27 pm

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

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
Member Candidate
Member Candidate
Posts: 142
Joined: Mon Aug 19, 2019 3:06 pm

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

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
Long time Member
Long time Member
Posts: 542
Joined: Fri Jan 08, 2021 5:30 am

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

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
just joined
Posts: 15
Joined: Wed Nov 11, 2020 12:24 pm

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

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:
/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
Thank you! It really worked. Do you know if it is already possible to set costs for OSPF?
 
wispmikrotik
Member Candidate
Member Candidate
Posts: 137
Joined: Tue Apr 25, 2017 10:43 am

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

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
newbie
Posts: 36
Joined: Wed Jan 06, 2021 12:31 am

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

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.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

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
Member Candidate
Member Candidate
Posts: 167
Joined: Fri Jun 29, 2018 2:34 pm

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

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
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

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

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
newbie
Posts: 38
Joined: Wed Aug 09, 2017 1:17 am

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

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!
Last edited by khialb32 on Wed May 19, 2021 8:55 pm, edited 1 time in total.
 
User avatar
hknet
Member Candidate
Member Candidate
Posts: 126
Joined: Sun Jul 17, 2016 6:05 pm
Location: Vienna, Austria
Contact:

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

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
Member Candidate
Member Candidate
Posts: 266
Joined: Fri Dec 09, 2016 8:10 pm
Location: Kolkata, India
Contact:

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

Wed May 19, 2021 9:17 pm

is ospf and ospfv3 working?
 
ksteink
Frequent Visitor
Frequent Visitor
Posts: 80
Joined: Thu Mar 31, 2016 6:54 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Fri Mar 11, 2016 2:37 pm

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

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.
 
User avatar
doneware
Trainer
Trainer
Posts: 647
Joined: Mon Oct 08, 2012 8:39 pm
Location: Hungary

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

Wed May 19, 2021 11:03 pm

can't wait to see this bad boy: crs520-4xs-16xq
 
User avatar
Chupaka
Forum Guru
Forum Guru
Posts: 8709
Joined: Mon Jun 19, 2006 11:15 pm
Location: Minsk, Belarus
Contact:

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

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
You do not have the required permissions to view the files attached to this post.
 
amix
just joined
Posts: 8
Joined: Wed May 19, 2021 11:16 pm

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

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
just joined
Posts: 19
Joined: Sat Jan 16, 2021 7:31 pm

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

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
newbie
Posts: 32
Joined: Sat Dec 23, 2017 2:02 am

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2095
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

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

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
Member Candidate
Member Candidate
Posts: 235
Joined: Mon Apr 11, 2011 2:34 pm
Location: Victoria, Australia

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

Thu May 20, 2021 6:21 am

Has 802.11AE / MACSEC been fixed yet ?
 
User avatar
vecernik87
Forum Veteran
Forum Veteran
Posts: 882
Joined: Fri Nov 10, 2017 8:19 am

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

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
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Mon Jan 04, 2016 3:54 am

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

Thu May 20, 2021 6:32 am

Wireguard as client is not working even with MSS Clamp fix was working in beta 5.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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
 
User avatar
FToms
MikroTik Support
MikroTik Support
Posts: 87
Joined: Fri Jul 24, 2020 3:28 pm

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

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.
 
User avatar
doneware
Trainer
Trainer
Posts: 647
Joined: Mon Oct 08, 2012 8:39 pm
Location: Hungary

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

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.
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

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

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
Member Candidate
Member Candidate
Posts: 127
Joined: Mon Nov 09, 2015 3:52 pm
Location: Renningen, Germany

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

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
just joined
Posts: 23
Joined: Thu Dec 21, 2017 3:08 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

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

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
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

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

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
Long time Member
Long time Member
Posts: 542
Joined: Fri Jan 08, 2021 5:30 am

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

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
just joined
Posts: 1
Joined: Fri Feb 09, 2018 4:09 pm

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

Thu May 20, 2021 3:01 pm

Missing one from changelog : Chelsio NIC driver support.
 
Alpenfreddy
just joined
Posts: 2
Joined: Thu May 20, 2021 3:04 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 99
Joined: Tue Aug 08, 2017 2:17 am

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

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
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

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

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.
 
User avatar
rushlife
Member Candidate
Member Candidate
Posts: 243
Joined: Thu Nov 05, 2015 12:30 pm

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

Thu May 20, 2021 4:17 pm

This "beta" thing has been absolute shitshow
Do you know what BETA is ?
 
gdanov
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

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

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
Member Candidate
Member Candidate
Posts: 266
Joined: Fri Dec 09, 2016 8:10 pm
Location: Kolkata, India
Contact:

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

Thu May 20, 2021 4:45 pm

Hello can anyone from mikrotik confirm if route filters and ospfv3 is working or not?
 
gdanov
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

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

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
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11968
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

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

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
Frequent Visitor
Frequent Visitor
Posts: 80
Joined: Thu Mar 31, 2016 6:54 pm

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

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
Forum Veteran
Forum Veteran
Posts: 897
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

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

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

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
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

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
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11968
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

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

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.
Last edited by rextended on Thu May 20, 2021 6:52 pm, edited 1 time in total.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

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
just joined
Posts: 5
Joined: Sat May 01, 2021 10:06 pm

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

Thu May 20, 2021 7:11 pm

MBIM support for Sierra is still broken since 7.1beta3.
viewtopic.php?f=1&t=170940
 
gdanov
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

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

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
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

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

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
Member Candidate
Member Candidate
Posts: 120
Joined: Mon Nov 06, 2017 8:58 am

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

Thu May 20, 2021 8:04 pm

Mlag :)
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

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

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 :)
 
User avatar
rushlife
Member Candidate
Member Candidate
Posts: 243
Joined: Thu Nov 05, 2015 12:30 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 99
Joined: Tue Aug 08, 2017 2:17 am

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

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
just joined
Posts: 6
Joined: Fri Oct 22, 2010 1:45 pm

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

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
just joined
Posts: 1
Joined: Thu Sep 24, 2020 5:48 pm

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

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) .
 
User avatar
kiler129
Member
Member
Posts: 352
Joined: Tue Mar 31, 2015 4:32 pm
Location: IL, USA
Contact:

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

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
just joined
Posts: 19
Joined: Sat Jan 16, 2021 7:31 pm

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

Fri May 21, 2021 12:13 am

Cake still crashes IMMEDIATELY on the CCR2004
 
buset1974
Frequent Visitor
Frequent Visitor
Posts: 86
Joined: Wed Sep 13, 2006 12:12 pm
Location: Jakarta

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

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
 
User avatar
elel
just joined
Posts: 7
Joined: Thu Jun 11, 2020 11:40 am

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

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
just joined
Posts: 9
Joined: Wed Apr 04, 2018 4:10 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 75
Joined: Fri Mar 11, 2016 2:37 pm

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

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
Long time Member
Long time Member
Posts: 682
Joined: Mon Jul 13, 2015 10:53 am
Location: Sweden

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

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
Member Candidate
Member Candidate
Posts: 226
Joined: Wed Jul 18, 2018 3:39 pm

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

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
just joined
Posts: 12
Joined: Thu Mar 11, 2021 9:43 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Tue Aug 07, 2018 3:14 am

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

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.
Last edited by mikegleasonjr on Fri May 21, 2021 5:12 pm, edited 1 time in total.
 
gtj0
just joined
Posts: 15
Joined: Wed Sep 23, 2020 8:08 pm

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

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.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

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

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.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11968
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

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

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?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

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:
Image
 
Cablenut9
Long time Member
Long time Member
Posts: 542
Joined: Fri Jan 08, 2021 5:30 am

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

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
Long time Member
Long time Member
Posts: 586
Joined: Thu Nov 12, 2020 12:07 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Tue Aug 07, 2018 3:14 am

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

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
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Tue Aug 07, 2018 3:14 am

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

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
Long time Member
Long time Member
Posts: 586
Joined: Thu Nov 12, 2020 12:07 pm

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

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
Member Candidate
Member Candidate
Posts: 266
Joined: Fri Dec 09, 2016 8:10 pm
Location: Kolkata, India
Contact:

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

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
 
User avatar
vinigas
just joined
Posts: 18
Joined: Thu Jun 18, 2020 8:48 pm
Location: Lithuania

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

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
Member Candidate
Member Candidate
Posts: 266
Joined: Fri Dec 09, 2016 8:10 pm
Location: Kolkata, India
Contact:

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

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
Long time Member
Long time Member
Posts: 586
Joined: Thu Nov 12, 2020 12:07 pm

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

Sat May 22, 2021 1:23 am

How to debug this further?
Bildschirmfoto 2021-05-22 um 00.22.14.png
You do not have the required permissions to view the files attached to this post.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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.
 
User avatar
jimmer
just joined
Posts: 19
Joined: Wed Mar 06, 2019 10:06 am
Location: Tasmania, Australia

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

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.
 
User avatar
vinigas
just joined
Posts: 18
Joined: Thu Jun 18, 2020 8:48 pm
Location: Lithuania

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

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
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Wed Nov 07, 2007 7:04 pm
Location: Plzeň, Czech Republic

My big thanks for Let's Encrypt module

Sat May 22, 2021 12:52 pm

MikroTik gentleman, you have my big thanks for this. This is definitely step in right direction!
 
mafiosa
Member Candidate
Member Candidate
Posts: 266
Joined: Fri Dec 09, 2016 8:10 pm
Location: Kolkata, India
Contact:

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

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.
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1237
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

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

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
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

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

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.
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1237
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

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

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?
 
User avatar
jimmer
just joined
Posts: 19
Joined: Wed Mar 06, 2019 10:06 am
Location: Tasmania, Australia

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

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
just joined
Posts: 12
Joined: Thu Mar 11, 2021 9:43 pm

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

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.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Sat May 22, 2021 8:33 pm

What exactly is not working with IPv6?
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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.
Last edited by mducharme on Sun May 23, 2021 5:23 am, edited 2 times in total.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

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

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
Member Candidate
Member Candidate
Posts: 112
Joined: Wed May 23, 2018 3:13 pm

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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
Forum Veteran
Forum Veteran
Posts: 897
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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
Forum Veteran
Forum Veteran
Posts: 897
Joined: Tue Aug 11, 2015 12:46 pm
Location: Netherlands

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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
just joined
Posts: 2
Joined: Sun May 23, 2021 3:25 pm

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

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?
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1237
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

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

Sun May 23, 2021 7:06 pm

Thanks for clarification!
 
garis
just joined
Posts: 9
Joined: Sat Apr 10, 2021 3:44 pm

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

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
Long time Member
Long time Member
Posts: 665
Joined: Thu Jun 04, 2009 3:11 pm

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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
Member
Member
Posts: 348
Joined: Thu Jun 21, 2018 9:29 pm

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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
Long time Member
Long time Member
Posts: 601
Joined: Sat Nov 29, 2014 7:27 pm

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

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.
Last edited by anuser on Mon May 24, 2021 12:05 am, edited 1 time in total.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2095
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

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

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
Member Candidate
Member Candidate
Posts: 117
Joined: Sun Mar 13, 2016 9:45 am
Location: France

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

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) ?
 
User avatar
jimmer
just joined
Posts: 19
Joined: Wed Mar 06, 2019 10:06 am
Location: Tasmania, Australia

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

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
just joined
Posts: 3
Joined: Tue Aug 01, 2017 12:22 pm

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

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.
 
User avatar
elel
just joined
Posts: 7
Joined: Thu Jun 11, 2020 11:40 am

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

Mon May 24, 2021 12:00 pm

Can we say that MLAG is similar to stackable switches, or did I get it wrong?
 
EdPa
MikroTik Support
MikroTik Support
Posts: 274
Joined: Fri Sep 15, 2017 10:05 am
Location: Riga
Contact:

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

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
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

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

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
Long time Member
Long time Member
Posts: 586
Joined: Thu Nov 12, 2020 12:07 pm

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

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.
 
User avatar
doneware
Trainer
Trainer
Posts: 647
Joined: Mon Oct 08, 2012 8:39 pm
Location: Hungary

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

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
just joined
Posts: 2
Joined: Thu May 20, 2021 3:04 pm

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

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
Member
Member
Posts: 348
Joined: Thu Jun 21, 2018 9:29 pm

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

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
newbie
Posts: 34
Joined: Thu May 12, 2011 3:52 am

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

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
Forum Veteran
Forum Veteran
Posts: 794
Joined: Thu Jan 27, 2011 7:29 am

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3279
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

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

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
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1237
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

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

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
Member Candidate
Member Candidate
Posts: 113
Joined: Mon Oct 12, 2015 2:37 pm

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

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
Forum Veteran
Forum Veteran
Posts: 794
Joined: Thu Jan 27, 2011 7:29 am

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

Tue May 25, 2021 6:54 pm

@raimondsp thanks for the info. Do you guys expect this by year end? (HW IPv6)
 
pushdrt
just joined
Posts: 1
Joined: Tue May 25, 2021 7:28 pm

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

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
newbie
Posts: 34
Joined: Thu May 12, 2011 3:52 am

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

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.
You do not have the required permissions to view the files attached to this post.
 
evbocharov
newbie
Posts: 26
Joined: Tue May 25, 2021 11:06 pm

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

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
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Tue Aug 07, 2018 3:14 am

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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
Frequent Visitor
Frequent Visitor
Posts: 94
Joined: Sat May 29, 2004 7:47 pm

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

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
just joined
Posts: 5
Joined: Thu May 27, 2021 1:18 pm

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

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
just joined
Posts: 17
Joined: Fri Jul 20, 2018 5:39 pm

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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
Member Candidate
Member Candidate
Posts: 104
Joined: Mon Oct 10, 2011 8:41 am

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

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
Forum Veteran
Forum Veteran
Posts: 794
Joined: Thu Jan 27, 2011 7:29 am

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

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
newbie
Posts: 26
Joined: Tue May 25, 2021 11:06 pm

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

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
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

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
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

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
just joined
Posts: 5
Joined: Thu May 27, 2021 1:18 pm

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

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
just joined
Posts: 4
Joined: Fri May 28, 2021 4:11 pm

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

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?
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

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
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

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

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
just joined
Posts: 4
Joined: Fri May 28, 2021 4:11 pm

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

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
Forum Veteran
Forum Veteran
Posts: 794
Joined: Thu Jan 27, 2011 7:29 am

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

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
Frequent Visitor
Frequent Visitor
Posts: 58
Joined: Mon Oct 19, 2020 4:12 am
Location: Canada

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

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
Forum Veteran
Forum Veteran
Posts: 794
Joined: Thu Jan 27, 2011 7:29 am

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

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.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3279
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

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

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
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

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
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

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
Forum Veteran
Forum Veteran
Posts: 794
Joined: Thu Jan 27, 2011 7:29 am

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

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
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

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
newbie
Posts: 28
Joined: Sat Feb 05, 2011 7:22 am

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

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
just joined
Posts: 1
Joined: Sat Mar 13, 2021 4:37 pm

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

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?
Last edited by ihaveproblems on Sun May 30, 2021 1:26 am, edited 1 time in total.
 
guipoletto
Member Candidate
Member Candidate
Posts: 195
Joined: Mon Sep 19, 2011 5:31 am

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

Sun May 30, 2021 12:38 pm

Are there plans for IPV6 address delegation via DHCP?
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

Sun May 30, 2021 1:20 pm

They have removed IP accounting.
Fortunately I had migrated from IP accounting to netflow some time ago. I do not need an expensive netflow analyzer package, I just want to keep
some logs, but I wanted to include port numbers. So I wrote a simple netflow receiver in perl using the Net::Flow package from CPAN, that just receives
the netflow stream and writes it into a tab-separated file similar to IP accounting. The deamon starts writing a new file (with date in the filename)
every day and the previous ones are compressed and kept for some limited time. Normally they are never read, they are just kept in case some
abuse report arrives.
I expect this to work in v7 (not tested yet).
 
vfreex
just joined
Posts: 10
Joined: Sat Dec 05, 2020 8:49 pm

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

Mon May 31, 2021 8:01 am

Enabling L3 offloading on my CRS309 completely ignores switch ACL rules then all traffics are permitted, even those only for L2 switching.
Disable L3 offloading and reboot makes ACL rules working again.

Are ACL rules broken with L3 offloading enabled in v7.1beta6?
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

Mon May 31, 2021 9:26 am

Enabling L3 offloading on my CRS309 completely ignores switch ACL rules then all traffics are permitted, even those only for L2 switching.
Disable L3 offloading and reboot makes ACL rules working again.

Are ACL rules broken with L3 offloading enabled in v7.1beta6?

ACL rules should work with L3 HW offloading with exception of Fasttrack offloading. Offloaded Fasttrack connections have higher priority and bypass ACL rules. Other than that, hardware routing should obey ACL rules. Can you post your interface config please, so we try reproducing your issue on our side?
/interface export hide-sensitive
 
vfreex
just joined
Posts: 10
Joined: Sat Dec 05, 2020 8:49 pm

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

Mon May 31, 2021 12:19 pm

Enabling L3 offloading on my CRS309 completely ignores switch ACL rules then all traffics are permitted, even those only for L2 switching.
Disable L3 offloading and reboot makes ACL rules working again.

Are ACL rules broken with L3 offloading enabled in v7.1beta6?

ACL rules should work with L3 HW offloading with exception of Fasttrack offloading. Offloaded Fasttrack connections have higher priority and bypass ACL rules. Other than that, hardware routing should obey ACL rules. Can you post your interface config please, so we try reproducing your issue on our side?
/interface export hide-sensitive
Hi,

Sure.

In my following config, I added the 3rd switch rule to completely disable the sfpplus1 port. However, it has no effects when l3 offloading is on. If I turn off l3 offloading, that port will be completely blocked and cannot send out any packets, but if turn l3 offloading on again, the port is working again.

I don't have any stateful firewall configuration in /ip/firewall.
/interface bridge
add admin-mac=C4:AD:34:D5:C2:53 auto-mac=no comment=defconf igmp-snooping=yes name=bridge pvid=90 vlan-filtering=yes
/interface vlan
add interface=bridge name=uplink vlan-id=80
add interface=bridge name=vlan10 vlan-id=10
add interface=bridge name=vlan20 vlan-id=20
/interface ethernet switch
set 0 l3-hw-offloading=yes
/interface list
add name=WAN
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether1 pvid=90
add bridge=bridge comment=defconf interface=sfp-sfpplus1 pvid=20
add bridge=bridge comment=defconf interface=sfp-sfpplus2 pvid=20
add bridge=bridge comment=defconf interface=sfp-sfpplus3 pvid=20
add bridge=bridge comment=defconf interface=sfp-sfpplus4 pvid=20
add bridge=bridge comment=defconf interface=sfp-sfpplus5
add bridge=bridge comment=defconf interface=sfp-sfpplus6
add bridge=bridge comment=defconf interface=sfp-sfpplus7
add bridge=bridge comment=defconf interface=sfp-sfpplus8
/interface bridge vlan
add bridge=bridge comment=MGMT tagged=sfp-sfpplus7,sfp-sfpplus8,sfp-sfpplus6,sfp-sfpplus5 vlan-ids=90
add bridge=bridge comment="Uplink to Transit" tagged=sfp-sfpplus5,bridge vlan-ids=80
add bridge=bridge comment="User VLAN" tagged=sfp-sfpplus6,sfp-sfpplus7,sfp-sfpplus8,bridge,sfp-sfpplus5 vlan-ids=10
add bridge=bridge comment="Service VLAN" tagged=bridge,sfp-sfpplus5 vlan-ids=20
/interface ethernet switch rule
add comment="Accept MGMT" dst-address=100.100.16.0/24 ports=sfp-sfpplus8,sfp-sfpplus7,sfp-sfpplus6,sfp-sfpplus5 src-address=100.100.16.0/24 \
    switch=switch1
add comment="disallow non-MGMT" dst-address=100.100.16.0/24 new-dst-ports="" ports=sfp-sfpplus8,sfp-sfpplus7 src-address=0.0.0.0/0 switch=\
    switch1
add comment="completely disable sfpplus1" new-dst-ports="" ports=sfp-sfpplus1 switch=switch1
/interface list member
add interface=ether1 list=WAN
add interface=sfp-sfpplus1 list=LAN
add interface=sfp-sfpplus2 list=LAN
add interface=sfp-sfpplus3 list=LAN
add interface=sfp-sfpplus4 list=LAN
add interface=sfp-sfpplus5 list=LAN
add interface=sfp-sfpplus6 list=LAN
add interface=sfp-sfpplus7 list=LAN
add interface=sfp-sfpplus8 list=LAN
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

Tue Jun 01, 2021 12:13 pm

Enabling L3 offloading on my CRS309 completely ignores switch ACL rules then all traffics are permitted, even those only for L2 switching.
Disable L3 offloading and reboot makes ACL rules working again.

Are ACL rules broken with L3 offloading enabled in v7.1beta6?

ACL rules should work with L3 HW offloading with exception of Fasttrack offloading. Offloaded Fasttrack connections have higher priority and bypass ACL rules. Other than that, hardware routing should obey ACL rules. Can you post your interface config please, so we try reproducing your issue on our side?
/interface export hide-sensitive
Hi,

Sure.

In my following config, I added the 3rd switch rule to completely disable the sfpplus1 port. However, it has no effects when l3 offloading is on. If I turn off l3 offloading, that port will be completely blocked and cannot send out any packets, but if turn l3 offloading on again, the port is working again.

I don't have any stateful firewall configuration in /ip/firewall.
/interface bridge
add admin-mac=C4:AD:34:D5:C2:53 auto-mac=no comment=defconf igmp-snooping=yes name=bridge pvid=90 vlan-filtering=yes
/interface vlan
add interface=bridge name=uplink vlan-id=80
add interface=bridge name=vlan10 vlan-id=10
add interface=bridge name=vlan20 vlan-id=20
/interface ethernet switch
set 0 l3-hw-offloading=yes
/interface list
add name=WAN
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge comment=defconf frame-types=admit-only-untagged-and-priority-tagged interface=ether1 pvid=90
add bridge=bridge comment=defconf interface=sfp-sfpplus1 pvid=20
add bridge=bridge comment=defconf interface=sfp-sfpplus2 pvid=20
add bridge=bridge comment=defconf interface=sfp-sfpplus3 pvid=20
add bridge=bridge comment=defconf interface=sfp-sfpplus4 pvid=20
add bridge=bridge comment=defconf interface=sfp-sfpplus5
add bridge=bridge comment=defconf interface=sfp-sfpplus6
add bridge=bridge comment=defconf interface=sfp-sfpplus7
add bridge=bridge comment=defconf interface=sfp-sfpplus8
/interface bridge vlan
add bridge=bridge comment=MGMT tagged=sfp-sfpplus7,sfp-sfpplus8,sfp-sfpplus6,sfp-sfpplus5 vlan-ids=90
add bridge=bridge comment="Uplink to Transit" tagged=sfp-sfpplus5,bridge vlan-ids=80
add bridge=bridge comment="User VLAN" tagged=sfp-sfpplus6,sfp-sfpplus7,sfp-sfpplus8,bridge,sfp-sfpplus5 vlan-ids=10
add bridge=bridge comment="Service VLAN" tagged=bridge,sfp-sfpplus5 vlan-ids=20
/interface ethernet switch rule
add comment="Accept MGMT" dst-address=100.100.16.0/24 ports=sfp-sfpplus8,sfp-sfpplus7,sfp-sfpplus6,sfp-sfpplus5 src-address=100.100.16.0/24 \
    switch=switch1
add comment="disallow non-MGMT" dst-address=100.100.16.0/24 new-dst-ports="" ports=sfp-sfpplus8,sfp-sfpplus7 src-address=0.0.0.0/0 switch=\
    switch1
add comment="completely disable sfpplus1" new-dst-ports="" ports=sfp-sfpplus1 switch=switch1
/interface list member
add interface=ether1 list=WAN
add interface=sfp-sfpplus1 list=LAN
add interface=sfp-sfpplus2 list=LAN
add interface=sfp-sfpplus3 list=LAN
add interface=sfp-sfpplus4 list=LAN
add interface=sfp-sfpplus5 list=LAN
add interface=sfp-sfpplus6 list=LAN
add interface=sfp-sfpplus7 list=LAN
add interface=sfp-sfpplus8 list=LAN

We reproduced the issue and confirm that, unfortunately, ACL rules do not work with L3 HW in v7.1beta6. The bug report has been submitted to the developers. Hopefully, it will get resolved in the next beta.

Thank you for the feedback!
 
Reiney
newbie
Posts: 28
Joined: Sat Feb 05, 2011 7:22 am

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

Tue Jun 01, 2021 10:19 pm

Any news on whether route filters are working? Is there somewhere else that people who paid for a beta license can get support?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Wed Jun 02, 2021 1:03 am

Please be more specific, in general route filters are working.
 
User avatar
Paternot
Forum Veteran
Forum Veteran
Posts: 953
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

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

Wed Jun 02, 2021 1:30 am

Please be more specific, in general route filters are working.
I think he is talking about this link (not updated yet to 7.1v5)
https://help.mikrotik.com/docs/display/ ... col+Status

"Routing filter match prefix with address list"
"Routing filter add prefix to address list"

Is filtering working at v6? It would be great if Mikrotik updated this link.
 
stefanau
just joined
Posts: 2
Joined: Tue Dec 22, 2020 4:13 am

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

Wed Jun 02, 2021 2:43 am

Just rolled back from beta6 due to my crs328-24p-4s+rm becoming unresponsive after a couple of days after boot. It continues to pass packets, but no response to its internal IP.

Unfortunately, I didn't get a chance to grab logs or delve deeper, but rolling back has fixed it.

There's nothing funky in the config except a couple of 802.3ad bonds.
 
Reiney
newbie
Posts: 28
Joined: Sat Feb 05, 2011 7:22 am

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

Wed Jun 02, 2021 5:10 am

Hi ...

I was talking about my post a few days back. BGP out-bound route filters
don't seem to work; in-bound is ok.

Reiney
 
infabo
Long time Member
Long time Member
Posts: 586
Joined: Thu Nov 12, 2020 12:07 pm

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

Wed Jun 02, 2021 11:09 am

Well Cake QoS crashes routeros
Does it crashes this beta (beta6) as well?
Yes, mine (Chateau LTE12) crashes within minutes after enabling cake simple queue.
 
User avatar
anthonws
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Sat Jan 09, 2016 6:46 pm

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

Wed Jun 02, 2021 1:26 pm

Is there any known issue with Traffic Flow in beta6? It looks like I can't get any netflow info into logstash (and I have checked everything in terms of config, FW, etc.)

If no one has an idea, I will open a support case to check if it really is an issue in MT or not.

Cheers,
anthonws.
 
dria
just joined
Posts: 2
Joined: Wed Jun 02, 2021 7:59 pm

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

Wed Jun 02, 2021 8:07 pm

Hopefully Cake will be stable. Currently using it (on RB750gr3) and random reboot twice so far. First one was nearly a day after setting up and the second just about 1 hour after.

edit: gonna stick to fq_codel the meantime.
Last edited by dria on Wed Jun 02, 2021 9:41 pm, edited 5 times in total.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

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

Thu Jun 03, 2021 6:19 am

Got ECMP?

Upgraded from v6-longterm to v7.1beta6, on an older RB953 with two LTE modems (Sierra MC7354, Telit LE960), to check it out. The modem both seem to working fine (once reconfig'd for MBIM & a seemingly a few reboots initially to get the ports/fw/carrier aligned, certainly needs the init delay.

BUT my issue is actually I can't figure out how to do ECMP with the two LTE modems. I can't seem to add multiple interface (or IP-based) "gateway", in main or a specific table, using an interface nor another connected gateway IP. CLI or Winbox, all seem not want to take multiple gateways.

Basically is ECMP suppose to work? Maybe there some syntax for the /ip/route/add gateway=... butI tried a bunch of possible things for the two interface: "lte1,lte2" and "1.2.3.4,1.5.4.3", "lte1 lte2", etc., etc.


Here is something more specific:
 /ip/route/add routing-table=ecmptable dst-address=0.0.0.0/0 gateway="lte1,lte2"
 
which appear to work with out error, however, this the resulting entry:
 /ip/route/print detail
 
  2  IsH  dst-address=0.0.0.0/0 routing-table=ecmptable  pref-src="" gateway=0.0.0.0 immediate-gw="" distance=1 scope=30 target-scope=10 suppress-hw-offload=no 
 


Normally it the LTE chips sometimes fight...but that seems much improved! But now I'd like to use both of them in LTE mode ;) I can't figure out ECMP in v7.1beta6 however.
 
Reiney
newbie
Posts: 28
Joined: Sat Feb 05, 2011 7:22 am

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

Thu Jun 03, 2021 7:40 am

What happens if you add them one at a time? i.e. Your command line but with gateway=lte1
Then, same command with gateway=lte2. Do you get two entries? The conversion of "lte1, lte2"
to 0.0.0.0 seems odd. I'd try it here but I downgraded my test router back to v6, swapped it into
production, then forgot to remove the SATA drive that had the licensed v7 on it. :(
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Thu Jun 03, 2021 10:02 am

In v7 gateway can be only one "IP/interface", you need to add two route entries and that will form ECMP route.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

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

Thu Jun 03, 2021 9:13 pm

In v7 gateway can be only one "IP/interface", you need to add two route entries and that will form ECMP route.
Thanks MRZ - that worked - knew I was missing something... Pretty much as described, although avoiding doing anything winbox with ROS v7beta6 helped.

For completeness, this worked to create the routes.
/routing/table/add name=ecmp2 comment=ecmp2
/ip/route/add routing-table=ecmp2 gateway=lte1 comment=ecmp2
/ip/route/add routing-table=ecmp2 gateway=lte2 comment=ecmp2
which then show up in:
/routing/route/print detail 
As + ;;; ecmp2
    afi=ip4 
       contribution=active dst-address=0.0.0.0/0 routing-table=ecmp2 pref-src="" gateway=lte2 immediate-gw=lte2 distance=1 scope=30 target-scope=10 
       belongs-to="Static route" 
       debug.fwp-ptr=0x20202000 

 As + ;;; ecmp2
    afi=ip4 
       contribution=active dst-address=0.0.0.0/0 routing-table=ecmp2 pref-src="" gateway=lte1 immediate-gw=lte1 distance=1 scope=30 target-scope=10 
       belongs-to="Static route" 
       debug.fwp-ptr=0x20202060 
In my case the MBIM stuff just worked in v7beta6 -VERY COOL - why there is even a "lte1" and "lte2" interfaces to even be used by ECMP. The rest of the post is just documenting what I did in case it helps someone else.

I created a new VLAN/route table to test those in my lightly modified from quickset defaults RB953, using PBR for simplicity:
# vlan for ECMP route
/interface/vlan/add name=vlan-ecmp2 vlan-id=2 interface=bridge comment=ecmp2
/ip/address/add interface=vlan-ecmp2 address=203.0.113.1/24 comment=ecmp2
# dchp-server on ECMP route
/ip/dhcp-server/network/add address=203.0.113.0/24 gateway=203.0.113.1 comment=ecmp2
/ip/pool/add name=ecmp2 ranges=203.0.113.101-203.0.113.199 comment=ecmp2
/ip/dhcp-server/add address-pool=ecmp2 name=ecmp2 interface=vlan-ecmp2 disabled=no
# with default firewall, adding to LAN interface list will do NAT
/interface/list/member/add interface=vlan-ecmp2 list=LAN
# many ways to do this part, a policy rule seemed simple to show this working (NOTE: v6 had this under "/ip route rule")
/routing/rule/add src-address=203.0.113.0/24 table=ecmp2 comment=ecmp2
Skipping un-tagging the new VLAN 2 since that more config dependant... But using an access port from VLAN 2 above, a quick test using BitTorrent to download Ubuntu ISO goes out both MBIM-based LTE connections:
 /interface/lte> monitor lte1,lte2
              status: connected            connected
               model: LM960A18             MC7354
            revision: 32.00.144            SWI9X15C_05.05.58.01
    current-operator: AT&T                 Verizon
          data-class: LTE                  LTE
      session-uptime: 1h33m40s             1h28m28s
                imei: 356299100000000      359225050000000
                imsi: 310410000000000      311480000000000
                uicc: 89014100000000000000 89148000000000000000
                rssi: -93dBm               -75dBm

/interface/lte> /interface/monitor-traffic lte1,lte2
                         name:       lte1      lte2
        rx-packets-per-second:      2 409     4 440
           rx-bits-per-second:   13.0Mbps  25.2Mbps
     fp-rx-packets-per-second:      2 409     4 440
        fp-rx-bits-per-second:   13.0Mbps  25.2Mbps
          rx-drops-per-second:          0         0
         rx-errors-per-second:          0         0
        tx-packets-per-second:        547     1 083
           tx-bits-per-second:  285.6kbps 625.4kbps
     fp-tx-packets-per-second:          0         0
        fp-tx-bits-per-second:       0bps      0bps
          tx-drops-per-second:          0         0
    tx-queue-drops-per-second:          0         0
         tx-errors-per-second:          0         0


It was actually doing higher speeds, but just captured one. Anyway v7 seems to have come a long way, considering we have to use PPP with Sierra modems in production today.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

Thu Jun 03, 2021 9:27 pm

How does that actually work? I presume you rely on the ECMP only for the first packet of each connection to be routed to a random external connection, and then the connection tracking (NAT table) will force all the other traffic out of the chosen interface?
Otherwise it would only be useful for UDP traffic where a single UDP exchange constitutes the entire connection (DNS, NTP etc).

I would consider ECMP mostly to balance traffic over two links (e.g. VPN tunnels) where both ends are under my control and no NAT is involved.
Is there any advantage of using ECMP in your scenario, vs the "standard" solution of setting up route marking via some form of per-connection classification (based on IP+port or N'th matchers)?
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

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

Thu Jun 03, 2021 10:11 pm

v7 seems to have come a long way.
Like others, the Let's Encrypt worked (with port 80/firewall changes) - been waiting for that almost as long as MBIM: don't like the self-signed certs but too lazy to deal with a cert hierachy.

But did run into some oddities in v7beta6 so far (hardware is RB953 in this case)....

winbox/webfig static route issues
Tried a few v7 beta now, so kinda know to use the CLI for now. But I tried in the ECMP/PBR stuff in both winbox and webfig, seem like there were still issues, noticed at least the following:
  • In winbox, using "@" in the "Gateway" field in a listed IP>Routes crashes winbox
  • Similarly, using IP>Route>Rule in winbox causes random crashes and displays different things from CLI sometimes.
  • In webfig, the IP>Route display either shows empty or one route. Selecting the same item from webfig menu on left, then showed entire list.
Now that we have MBIM... some suggestions/issues
  • LTE interface only shows "rssi" several TelIt and Sierra modems in MBIM mode - think I've seen it show in other beta, but RSSI is helpful be good to know rest of stats.
  • Using ECM mode with TelIt LC960 in this v7.1beta6 shows the RSRQ etc (Sierra can't do ECM, so only RSSI for those RN)
  • While "at-chat" works - which is great - it strips "newlines" from some output... in particular ones that show CQI etc. See below. While remove newlines/"trimming" the AT output make sense most times, for the "big" AT commands with formated output, not as useful
Sierra's output from these commands has columns with newlines so you can tell which numbers go to what:
/interface/lte/at-chat lte2 input="AT!LTEINFO\?"      
  output: !LTEINFO: Serving: EARFCN MCC MNC TAC CID Bd D U SNR PCI RSRQ RSRP RSSI RXLV 2100 311 480 7939 007A230C 4 3 3 -10 390 -11.1 -70.9 -42.6 53 
          IntraFreq: PCI RSRQ RSRP RSSI RXLV 390 -11.1 -70.9 -42.6 53 374 -19.0 -79.2 -50.2 53 InterFreq: EARFCN ThresholdLow ThresholdHi Priority PCI RSRQ 
          RSRP RSSI RXLV GSM: ThreshL ThreshH Prio NCC ARFCN 1900 valid BSIC RSSI RXLV WCDMA: UARFCN ThreshL ThreshH Prio PSC RSCP ECN0 RXLV CDMA 1x: Chan BC 
          Offset Phase Str CDMA HRPD: Chan BC Offset Phase Str OK

 /interface/lte/at-chat lte2 input="AT!GSTATUS\?"                      
  output: !GSTATUS: Current Time: 5268 Temperature: 38 Bootup Time: 0 Mode: ONLINE System mode: LTE PS state: Attached LTE band: B4 LTE bw: 10 MHz LTE Rx 
          chan: 2100 LTE Tx chan: 20100 EMM state: Registered Normal Service RRC state: RRC Connected IMS reg state: No Srv IMS mode: Normal RSSI (dBm): -41 
          Tx Power: 0 RSRP (dBm): -71 TAC: 1F03 (7939) RSRQ (dB): -15 Cell ID: 00... (80...) SINR (dB): 15.0 OK
For example, with v6 in serial-console, it show something like this:
at!gstatus?
!GSTATUS:
Current Time:  7483                   Temperature: 64
Reset Counter: 1                       Mode:        ONLINE    
System mode:   LTE                  PS state:    Attached   
LTE band:      B7                       LTE bw:      20 MHz  
LTE Rx chan:   3148                  LTE Tx chan: 21148
LTE SSC1 state:INACTIVE         LTE SSC1 band: B7     
LTE SSC1 bw  : 20 MHz                        LTE SSC1 chan: 2950
LTE SSC2 state:INACTIVE         LTE SSC2 band: B3     
LTE SSC2 bw  : 15 MHz                        LTE SSC2 chan: 1275
LTE SSC3 state:NOT ASSIGNED
LTE SSC4 state:NOT ASSIGNED
EMM state:     Registered           Normal Service
RRC state:     RRC Connected  
IMS reg state: No Srv                
PCC RxM RSSI:  -62                 PCC RxM RSRP:  -100
PCC RxD RSSI:  -65                  PCC RxD RSRP:  -105
SCC1 RxM RSSI: -74                SCC1 RxM RSRP: -103
SCC1 RxD RSSI: -80                 SCC1 RxD RSRP: -108
SCC2 RxM RSSI: -70                SCC2 RxM RSRP: -93
SCC2 RxD RSSI: -75                 SCC2 RxD RSRP: -97
Tx Power:      3              TAC:         204c (8268)
RSRQ (dB):     -17.9                   Cell ID:     080ba821 (134981665)
SINR (dB):     -5.8

The TelIt seem to handle these status ones better:
/interface/lte>> at-chat lte1 input="AT#RFSTS" 
  output: #RFSTS: "310 410",800,-93,-59,-14,8B1E,255,-5,1280,19,2,A20...,"310410...","AT&T",3,2
OK

/interface/lte>> at-chat lte1 input="AT#moni"     
  output: #MONI: AT&T RSRP:-92 RSRQ:-17 TAC:8B1E Id:A204... EARFCN:800 PWR:-54dbm DRX:1280
But it too has output that the newlines/tab/etc are helpful:
at-chat lte1 input="AT#FIRMWARE"  
  output: HOST FIRMWARE : 32.00.005_1 MODEM FIRMWARE : 4 INDEX STATUS CARRIER VERSION TMCFG CNV LOC 1 Generic 32.00.115 1025 empty 1 2 Verizon 32.00.124 2020 
          empty 2 3 Activated ATT 32.00.144 4021 empty 3 4 TMUS 32.00.153 5004 empty 4 OK
In the above to switch firmware, it's not that easy to parse the numbers (I had to look in their manual to be sure).

Otherwise, we'll keep trying this one out. So far so good - great work!
 
mfrey
newbie
Posts: 36
Joined: Wed Jan 06, 2021 12:31 am

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

Thu Jun 03, 2021 11:39 pm

When scripting, I found that
/ip dns static;
:put [get [ find  type=A ]]
does not return the static DNS entries of type A. The attribute "type" seems to be nil for all entries of type A. Is this expected behaviour?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

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

Thu Jun 03, 2021 11:50 pm

try [find type="A"]
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11968
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

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

Fri Jun 04, 2021 12:05 am

On CACHE type can be:
A AAAA CNAME MX NS SRV TXT

ros code

:put [:len [/ip dns cache find where type=A]]         
:put [:len [/ip dns cache find where type=AA]]       
:put [:len [/ip dns cache find where type=AAA]]       
:put [:len [/ip dns cache find where type=AAAA]] 
type AAA and AA does not exist, right?
but are accepted....


On STATIC all type are set and searchable except for "A" (with or without quotes are useless)
unsearchables value are: A
valid searchable values are: AAAA CNAME FWD MX NS NXDOMAIN SRV TXT


the only way to find type A is exclude everything else:

ros code

:put [/ip dns static find where type!=AAAA and type!=CNAME and type!=FWD and type!=MX and type!=NS and type!=NXDOMAIN and type!=SRV and type!=TXT]
or exclude any item with type set:

ros code

:put [/ip dns static find where !type]
 
User avatar
anthonws
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Sat Jan 09, 2016 6:46 pm

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

Fri Jun 04, 2021 12:43 am

Is there any known issue with Traffic Flow in beta6? It looks like I can't get any netflow info into logstash (and I have checked everything in terms of config, FW, etc.)

If no one has an idea, I will open a support case to check if it really is an issue in MT or not.

Cheers,
anthonws.
Replying to myself for broader awareness and ask for hints :)

After adding another target to Traffic Flow (v9), I could confirm that indeed the issue is that date is showing up as 1970... Hence why I was seeing no data in Kibana... I just had to look into the Index Mapping to see why...
I confirmed with nfcapd and nfdump that date is showing up as 1970-01-01.

Can anyone confirm is they see the same with beta6?

Thanks,
anthonws.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

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

Fri Jun 04, 2021 12:49 am


How does that actually work? I presume you rely on the ECMP only for the first packet of each connection to be routed to a random external connection, and then the connection tracking (NAT table) will force all the other traffic out of the chosen interface?
Otherwise it would only be useful for UDP traffic where a single UDP exchange constitutes the entire connection (DNS, NTP etc).
AFAIK ECMP depends on connection tracking (and NAT too here). While not privy to the internals, I assume ECMP the same as unweighted PCC. So yeah ECMP works better with both a greater number and diversity of connections with different IP/ports, & ideally shorter in length - stuff like dozens of devices browsing the web generates a fair amount of connections to various different place, or BitTorrent of common file, will show the Mikrotik "sharing" connections in my experience.

For TCP/flow control, ECMP essentially relies on the each connected devices' TCP congestion control algorithm to limit the rate (which is may also not be necessarily fair to all), which works (although almost certainly want a queue on mikrotik side in practice). Obviously each connection is limited by the speed of the selected LTE interface for each individual connection. e.g. ECMP != bonding. Now the typical side-effect of ECMP selection is that for long lived connections, the Mikrotik connection tracking will continue to use the same, but say potentially "slower connection" until either the interface or connection drops.
I would consider ECMP mostly to balance traffic over two links (e.g. VPN tunnels) where both ends are under my control and no NAT is involved.
Is there any advantage of using ECMP in your scenario, vs the "standard" solution of setting up route marking via some form of per-connection classification (based on IP+port or N'th matchers)?
Since v7 is still beta was trying to just test ECMP using "regular LTE", In v6, we use ECMP with PBR a lot, but still use some firewall filters and marking stuff. I used a VLAN here for example only - since if you use ECMP in the main routing table, you'd almost certainly need to do at least connection and route marking, which add to a minimal example of it working & HOW a connection/packet found it's way to a route table is different thing. A VLAN-based subnet + PBR was easier than /ip/firewall/manage rules,....

Now, for disclaimer on my approach, for production use, since you can't always avoid masquerade since WAN IP of LTE isn't always deterministic, thus able to
 action=src-nat
, you have to use firewall marking to counter the side-effect of
action=masquerade
potentially "leaking" packets if an LTE interface goes up/down. If you take a look at page 23-27 of from '17 MUM titled "'holy war' against masquerade" https://mum.mikrotik.com/presentations/ ... 948376.pdf - it will clarify my summary).[/i]
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3279
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

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

Fri Jun 04, 2021 8:27 am

On STATIC all type are set and searchable except for "A" (with or without quotes are useless)
Not sure what you mean.
For me
 :put [/ip dns cache find where type="A"]
This only gets type "A" record, NOT "AAAA"
 :put [/ip dns cache find where type="AAAA"]
This only gets type "AAAA" records.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

Fri Jun 04, 2021 9:34 am

AFAIK ECMP depends on connection tracking (and NAT too here). While not privy to the internals, I assume ECMP the same as unweighted PCC. So yeah ECMP works better with both a greater number and diversity of connections with different IP/ports, & ideally shorter in length - stuff like dozens of devices browsing the web generates a fair amount of connections to various different place, or BitTorrent of common file, will show the Mikrotik "sharing" connections in my experience.
Ok, I do run a v6 load balancing configuration (unfortunately only IPv4 as v6 cannot do this for IPv6) but I have setup the PCC using only source address as the classifier, as I am not sure that every service on the internet is able to handle the changing source IP well. There are about 500 users on that network and I cannot rely on them reporting problems they have with certain sites or apps, and I do not want a buzz "the network is not working well" going around and coming back to me via management 3 months later.
Of course with 500 users it does not really matter that they are statically mapped to one connection each, that would be more important when you have a small number of users.
In fact I do a 1/4-3/4 mapping in PCC because (due to v6 limitations) all IPv6 traffic goes over one of the connections, that one gets 1/4 of the IPv4 users, and the other one gets 3/4 of the users. That about balances the traffic evenly.

Still, doing it via ECMP is an interesting approach. Do you ever see problems due to the random changeovers between the connections within a single user "session" with websites etc?
 
mfrey
newbie
Posts: 36
Joined: Wed Jan 06, 2021 12:31 am

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

Fri Jun 04, 2021 11:54 am

try [find type="A"]
Same result.

@Jotne: I think what rextended meant was that you can find cache entries with type="A" and type=A, but the same does not work for static entries.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11968
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

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

Fri Jun 04, 2021 12:02 pm

On STATIC all type are set and searchable except for "A" (with or without quotes are useless)
Not sure what you mean.
Exact, as yourself quoted, I mean STATIC, not cache...
 
vfreex
just joined
Posts: 10
Joined: Sat Dec 05, 2020 8:49 pm

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

Sun Jun 06, 2021 11:08 am

Hi,

Another minor issue with l3 hw I found is updating next-hop in an existing static route doesn’t take effect. A workaround could be turning that route off and on again.
 
gdanov
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

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

Sun Jun 06, 2021 1:07 pm

Is there any known issue with Traffic Flow in beta6? It looks like I can't get any netflow info into logstash (and I have checked everything in terms of config, FW, etc.)

If no one has an idea, I will open a support case to check if it really is an issue in MT or not.

Cheers,
anthonws.
Replying to myself for broader awareness and ask for hints :)

After adding another target to Traffic Flow (v9), I could confirm that indeed the issue is that date is showing up as 1970... Hence why I was seeing no data in Kibana... I just had to look into the Index Mapping to see why...
I confirmed with nfcapd and nfdump that date is showing up as 1970-01-01.

Can anyone confirm is they see the same with beta6?

Thanks,
anthonws.
I also had my date "reset" after the upgrade. But because the LTE interface wouldn't work (no other WAN for me) I don't know if this was interim issue or general one with NTP or whatever...anyhow I downgraded due to the LTE problem.
 
User avatar
anthonws
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Sat Jan 09, 2016 6:46 pm

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

Sun Jun 06, 2021 11:52 pm

I also had my date "reset" after the upgrade. But because the LTE interface wouldn't work (no other WAN for me) I don't know if this was interim issue or general one with NTP or whatever...anyhow I downgraded due to the LTE problem.
Thanks for sharing!
Reported bug (SUP-51582).

Cheers,
anthonws.
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

Mon Jun 07, 2021 11:41 am

Hi,

Another minor issue with l3 hw I found is updating next-hop in an existing static route doesn’t take effect. A workaround could be turning that route off and on again.

Hey there,

We reproduced the reported issue and are working on the fix. Thanks for the feedback!
 
sinisa
just joined
Posts: 22
Joined: Sun Apr 17, 2011 12:46 am

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

Mon Jun 07, 2021 2:29 pm

Hello Mikrotik,

can we expect UPS package for v7?

Thanks and Best Regards...
 
ivicask
Member
Member
Posts: 417
Joined: Tue Jul 07, 2015 2:40 pm
Location: Croatia, Zagreb

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

Mon Jun 07, 2021 2:31 pm

Anyone can tell me what is this?I only use this router (HEX) for wireguard and nothing else, first time i see this messages and thats only after beta 6
You do not have the required permissions to view the files attached to this post.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

Mon Jun 07, 2021 4:06 pm

Those messages are related to IPv6 on your local network. Unfortunately they do not include enough info to hunt down what device is causing them.
(there should be a MAC address or IPv6 address in those messages...)
 
ivicask
Member
Member
Posts: 417
Joined: Tue Jul 07, 2015 2:40 pm
Location: Croatia, Zagreb

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

Mon Jun 07, 2021 4:11 pm

Those messages are related to IPv6 on your local network. Unfortunately they do not include enough info to hunt down what device is causing them.
(there should be a MAC address or IPv6 address in those messages...)
Yeah i figured it already and disabled IPV6 as we dont use it at all.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3169
Joined: Sun May 01, 2016 7:12 pm
Location: California

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

Tue Jun 08, 2021 9:19 pm


LTE/MBIM with CHR on KVM/QEMU using v7.1beta6 issues...


I can get MBIM modems working with CHR v7 on KVM, however I have to use "USB Redirection" (via spicevmc). But I want to "passthrough" the USB device so it's there with CHR starts up. In v6 CHR with PPP mode same modem is passthrough just fine.

In fact, if is passthrough, it literally hangs CHR, no network, no console input is accepted - have to hard reset the VM. Removing the passthrough-ed MBIM modem from CHR's VM config fixes the hang. USB Redirection works fine however and seem stable (BUT that method doesn't survive a reboot, since the MBIM modem is for remote management, not ideal)

Curious if anyone else has tried CHR with MBIM on v7?

Related issues with CHR - haven't tried on other hypervisors, but v7.1beta6 doesn't seem to support the VM client tools scripts anymore - shutdown/restart from QEMU host seem to be ignored - which really slows down host restarts.
 
pavelion
just joined
Posts: 7
Joined: Tue Sep 22, 2015 6:00 pm

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

Wed Jun 09, 2021 4:40 pm

Does anyone else have had problem with upgrading Chateau LTE?

I am not able to upgrade brand new device shipped with 7.1beta4 (viewtopic.php?f=1&t=173567&p=852316#p852316).

Now 7.1beta6 cannot be installed neither using /system/package/update nor uploading the package to the device and rebooting.
 
infabo
Long time Member
Long time Member
Posts: 586
Joined: Thu Nov 12, 2020 12:07 pm

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

Thu Jun 10, 2021 12:46 am

 
pqatsi
just joined
Posts: 5
Joined: Thu Jun 18, 2015 3:03 pm

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

Thu Jun 10, 2021 2:25 am

Hello!

Using hAP ac^2 with this ROS Version apparently is only possible if using backup firmware. Normal boot goes into a boot loop since at least beta4.
 
comet48
newbie
Posts: 35
Joined: Fri Aug 23, 2019 4:39 am

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

Thu Jun 10, 2021 3:22 am

Tested L3 HW offload on CRS305 using Routeros 7.1beta6. Got just over 200 Mb/s. Yep, bits. Replicated this test run on the CRS317;
https://stubarea51.net/2020/10/12/mikro ... e-testing/

Here is the config.
/interface bridge
add mtu=9216 name=bridge1 vlan-filtering=yes
add name=lo0
/interface ethernet
set [ find default-name=sfp-sfpplus3 ] comment=”Proxmox – ens2f0″ l2mtu=10218 \
mtu=9216
set [ find default-name=sfp-sfpplus4 ] comment=”Proxmox – ens2f1″ l2mtu=10218 \
mtu=9216
/interface vlan
add interface=bridge1 mtu=9216 name=vlan103 vlan-id=103
add interface=bridge1 mtu=9216 name=vlan104 vlan-id=104
/interface ethernet switch
set 0 l3-hw-offloading=yes
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp_pool0 ranges=10.255.34.11-10.255.34.254
add name=dhcp_pool1 ranges=10.255.35.2-10.255.35.254
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=vlan103 name=dhcp1
add address-pool=dhcp_pool1 disabled=no interface=vlan104 name=dhcp2
/interface bridge port
add bridge=bridge1 interface=sfp-sfpplus3 pvid=103
add bridge=bridge1 interface=sfp-sfpplus4 pvid=104
/interface bridge vlan
add bridge=bridge1 tagged=bridge1 untagged=sfp-sfpplus3 vlan-ids=103
add bridge=bridge1 tagged=bridge1 untagged=sfp-sfpplus4 vlan-ids=104
/ip address
add address=10.255.34.1/24 interface=vlan103 network=10.255.34.0
add address=10.255.35.1/24 interface=vlan104 network=10.255.35.0
/ip dhcp-server network
add address=10.255.34.0/24 dns-server=9.9.9.9 gateway=10.255.34.1
add address=10.255.35.0/24 dns-server=9.9.9.9 gateway=10.255.35.1
/system routerboard settings
set boot-os=router-os
Any ideas welcome
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

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

Thu Jun 10, 2021 7:47 am

There was a thread about L3 HW performance (or rather lack of it) and it was said that L3 HW offload for jumbo frames was not there yet. I'm not sure if that limitation is already lifted. So you might try to test similar scenario but using standard MTU values ...
 
jeremy80
just joined
Posts: 1
Joined: Thu Jun 10, 2021 7:44 am

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

Thu Jun 10, 2021 7:49 am

Hi,

Does anyone know if the following protocol status page will be updated with information of beta 5 and beta 6 ?

https://help.mikrotik.com/docs/display/ ... col+Status

I found this page really useful to check everything before a migration from older OS
 
User avatar
raimondsp
MikroTik Support
MikroTik Support
Posts: 267
Joined: Mon Apr 27, 2020 10:14 am

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

Thu Jun 10, 2021 8:48 am

There was a thread about L3 HW performance (or rather lack of it) and it was said that L3 HW offload for jumbo frames was not there yet. I'm not sure if that limitation is already lifted. So you might try to test similar scenario but using standard MTU values ...

Currently, L3HW supports only MTU 1500. Jumbo frame support will be implemented later. Until then, please use the default MTU 1500 with L3HW.
 
comet48
newbie
Posts: 35
Joined: Fri Aug 23, 2019 4:39 am

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

Thu Jun 10, 2021 6:29 pm

Thanks for the response. Is that a constraint within the CRS configuration, the user equipment, or both.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

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

Thu Jun 10, 2021 6:33 pm

If you read what @raimondsp wrote it's clear that it's constraint in current L3 HW offload implementation. Not the configuration (because it's not something user can change) nor attached devices.
CRS can take jumbo frames, but they will pass CPU which offers severely low throughput ... which is what you see.
 
Gooogast
just joined
Posts: 12
Joined: Sun Sep 20, 2020 5:57 pm

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

Fri Jun 11, 2021 12:22 pm

Will MLAG work well with jumbo frames now, how does it depend on L3 hardware offload?
 
MarcSN
just joined
Posts: 15
Joined: Wed Jul 01, 2020 7:18 pm

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

Sat Jun 12, 2021 2:16 am

Does (or will) mlag work in combination with 802.1BR?
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

Sat Jun 12, 2021 8:56 am

Is MLAG planned to work with MSTP in the future? Or will it only work with STP/RSTP?
 
User avatar
frank333
Member
Member
Posts: 328
Joined: Mon Dec 18, 2017 12:17 pm
Location: S.Marino Router model: RB3011UiAS-RM+RBM11G

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

Sat Jun 12, 2021 5:41 pm

1.png
in routerboard RBM11G in IP routes and in nexthopes the % sign appears should be reported
You do not have the required permissions to view the files attached to this post.
 
mhugo
Member Candidate
Member Candidate
Posts: 179
Joined: Mon Sep 19, 2005 11:48 am

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

Sun Jun 13, 2021 12:36 am

Hi,

Does anyone know if the following protocol status page will be updated with information of beta 5 and beta 6 ?

https://help.mikrotik.com/docs/display/ ... col+Status

I found this page really useful to check everything before a migration from older OS
I find it very useful too - saves a lot of guesswork - so please update it.
 
mfrey
newbie
Posts: 36
Joined: Wed Jan 06, 2021 12:31 am

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

Sun Jun 13, 2021 4:25 pm

I have found a few other minor issues:
- VRF is a bit wonky: Sometimes when disabling/enabling or creating a VRF, no routing table is created (or at least visible in WinBox) and routing between the interfaces does not work
- /ip/firewall/mangle/export does not include the routing-mark for rules with action="mark-routing"
- When a RoMON secret set using command line contains the character "{", the secret is split into two separate ones using this character as delimiter (but only the first one!). This does not happen when setting the secret using WinBox. More interestingly, if the secret is properly set using WinBox and then exported/imported, the secret gets split into two ones again and therefore stops working.
 
User avatar
toast
just joined
Posts: 2
Joined: Sun Nov 22, 2020 4:08 am

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

Mon Jun 14, 2021 7:16 am

Anyone else having an issue here with v7.1beta6 and the hap ac^2, where on power loss all configuration is lost?
Thankyou
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

Mon Jun 14, 2021 10:47 am

Anyone else having an issue here with v7.1beta6 and the hap ac^2, where on power loss all configuration is lost?
Thankyou
This means the flash filesystem somehow got corrupted. Re-install with netinstall and use the format option.
 
EdPa
MikroTik Support
MikroTik Support
Posts: 274
Joined: Fri Sep 15, 2017 10:05 am
Location: Riga
Contact:

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

Mon Jun 14, 2021 2:24 pm

Will MLAG work well with jumbo frames now, how does it depend on L3 hardware offload?
Does (or will) mlag work in combination with 802.1BR?
Is MLAG planned to work with MSTP in the future? Or will it only work with STP/RSTP?
MLAG works with jumbo frames, but make sure to use the same L2MTU settings on both peers.
We are researching the ways to make MLAG compatible with 802.1BR, L3HW and MSTP.
 
MarcSN
just joined
Posts: 15
Joined: Wed Jul 01, 2020 7:18 pm

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

Mon Jun 14, 2021 5:22 pm

MLAG works with jumbo frames, but make sure to use the same L2MTU settings on both peers.
We are researching the ways to make MLAG compatible with 802.1BR, L3HW and MSTP.
Nice! You guys are f***ing awesome!
 
Easen
just joined
Posts: 22
Joined: Tue Mar 23, 2021 9:38 pm

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

Mon Jun 14, 2021 11:36 pm

Anyone else having an issue here with v7.1beta6 and the hap ac^2, where on power loss all configuration is lost?
Thankyou
Yes I had the same issue on my RB4011iGS+5HacQ2HnD.

How I 'solved it' was to flash using NetInstall and then slowly apply my config one block at a time. In my case, I believe it was due to some static DHCP leases, which was really odd.

Even now, I'm not 100% confident that it will come back up if I restart it.

I run a weekly backup of config (.rsc) file, just in case it happens again.
 
User avatar
toast
just joined
Posts: 2
Joined: Sun Nov 22, 2020 4:08 am

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

Tue Jun 15, 2021 2:16 am

Anyone else having an issue here with v7.1beta6 and the hap ac^2, where on power loss all configuration is lost?
Thankyou
This means the flash filesystem somehow got corrupted. Re-install with netinstall and use the format option.
Hi, so I reformatted using Netinstall at this dev version - same issue occurred. The issue does not occur now that I have downgraded to 6.48.3 stable.
 
Easen
just joined
Posts: 22
Joined: Tue Mar 23, 2021 9:38 pm

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

Tue Jun 15, 2021 11:38 am

Anyone else having an issue here with v7.1beta6 and the hap ac^2, where on power loss all configuration is lost?
Thankyou
This means the flash filesystem somehow got corrupted. Re-install with netinstall and use the format option.
Hi, so I reformatted using Netinstall at this dev version - same issue occurred. The issue does not occur now that I have downgraded to 6.48.3 stable.

I rebooted my RB4011 running 7.1beta6 and the configuration reset again, so from now I have rolled back to 7.1beta5 (which doesn't have this issue).
 
vfreex
just joined
Posts: 10
Joined: Sat Dec 05, 2020 8:49 pm

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

Wed Jun 16, 2021 12:51 am

In v7.1beta6, having the bridge with `igmp-snooping=yes` occasionally blocks IPv6 after running for a relatively long time. When the issue occurs, ping6 to an address in the same subnet doesn't work, but IIRC ping6 to a link-local address still works and if you do so it may unblock the IPv6 connectivity between your host and the another host you just ping6'd. Turning `igmp-snooping` to `no` will completely solve the IPv6 connectivity issue.

IPv4 always works.

Seems there's something wrong in RouterOS's MLD snooping implementation, but this is not easy to reproduce.
 
User avatar
osc86
Member Candidate
Member Candidate
Posts: 197
Joined: Wed Aug 09, 2017 1:15 pm

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

Wed Jun 16, 2021 5:44 pm

@vfreex this problem exists for many months now (v6), and has been reported to support. I hope they get this right with the stable release of v7.
viewtopic.php?f=2&t=161792#p797122
 
vfreex
just joined
Posts: 10
Joined: Sat Dec 05, 2020 8:49 pm

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

Wed Jun 16, 2021 8:42 pm

@vfreex this problem exists for many months now (v6), and has been reported to support. I hope they get this right with the stable release of v7.
viewtopic.php?f=2&t=161792#p797122
Is this issue solved in v6 yet? It seems to me the overall IPv6 support in current v7.1beta is still unstable, even for switching. Actually I have moved my main router from Mikrotik to Ubiquiti Edgerouter for IPv6 :(
 
User avatar
osc86
Member Candidate
Member Candidate
Posts: 197
Joined: Wed Aug 09, 2017 1:15 pm

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

Thu Jun 17, 2021 11:28 am

I didn't see anything specific in the recent changelogs regarding filtered RS/RA/NS/NA messages when igmp-snooping is being used, only general improvements to igmp-snooping.
Currently it's kind of working for me. Sometimes connected routes randomly disappear from the routing table, which is also a known problem. Support told me it will be fixed with the new ipv6 implementation in V7.
 
User avatar
StubArea51
Trainer
Trainer
Posts: 1739
Joined: Fri Aug 10, 2012 6:46 am
Location: stubarea51.net
Contact:

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

Thu Jun 17, 2021 2:54 pm

Is this issue solved in v6 yet? It seems to me the overall IPv6 support in current v7.1beta is still unstable, even for switching. Actually I have moved my main router from Mikrotik to Ubiquiti Edgerouter for IPv6 :(

I would def love to see IPv6 stabilize in ROSv7 but I've had even more issues with Ubnt for IPv6 support - you can't even set a specific prefix length or network types in OSPFv3 - have you tried ROSv6 for IPv6?
 
sinisa
just joined
Posts: 22
Joined: Sun Apr 17, 2011 12:46 am

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

Fri Jun 18, 2021 12:19 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??
It seems to me that names are resolved (or just tried) only once. If there is no answer from DNS (for example on boot-up, Wireguard is started before DHCP Client gets parameters), Wireguard won't start.
I have bypassed this by creating Netwatch rule(s) to watch for remote VPN address and restart wireguard interface if there is no reply.

Of course, it would be nice to retry resolving automaticaly (ala Openvpn), but this works too.
 
syadnom
Forum Veteran
Forum Veteran
Posts: 794
Joined: Thu Jan 27, 2011 7:29 am

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

Wed Jun 23, 2021 7:49 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.
One last question along these lines. Will existing CCR products get hardware/fasttrack/any accellerated IPv6 support or is this only happening in the new devices with the newer switch hardware?
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

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

Wed Jun 23, 2021 8:22 am

One last question along these lines. Will existing CCR products get hardware/fasttrack/any accellerated IPv6 support or is this only happening in the new devices with the newer switch hardware?

Fasttrack is software feature, so yes, when IPv6 fasttrack gets (finally) implemented, it will be on all devices.
Hardware acceleration of routing is Marvell Prestera chip-set specific feature and will be supported on CRS3xx devices (unless Mikrotik produces other devices featuring these chipsets). Not going to happen on current CCR line of products.
 
kickdown
just joined
Posts: 4
Joined: Wed Jun 23, 2021 1:57 pm

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

Wed Jun 23, 2021 2:08 pm

Please can you tell me if there is native support for Intel i211AT in RouterOS 7?
Last edited by kickdown on Wed Jun 23, 2021 4:15 pm, edited 1 time in total.
 
indy
newbie
Posts: 25
Joined: Sun Mar 22, 2020 10:17 pm

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

Wed Jun 23, 2021 10:29 pm

Is anyone else seeing high CPU usage on their RB3011 with v7?
Routing 100Mbit/s with the default configuration shows <5% CPU usage on v.6.48.3.
v7.1b6 with the default configuration and same load shows about 30%.
 
raymonvdm
Member Candidate
Member Candidate
Posts: 161
Joined: Mon Jan 31, 2005 7:47 pm

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

Wed Jun 23, 2021 11:44 pm

When running 7.1beta6 on a RB1200 the Eth1 - Eth8 are not working. The link state is correct but there is no traffic passing the ports (same when using 7.1beta4) the Eth9 and Eth10 seem to be working fine

Image

[admin@MikroTik] /interface/ethernet> print 
Flags: R - RUNNING; S - SLAVE
Columns: NAME, MTU, MAC-ADDRESS, ARP, SWITCH
  #      NAME      MTU  MAC-ADDRESS        ARP      SWITCH 
  0   S  ether1   1500  D4:CA:6D:41:78:C1  enabled  switch1
  1   S  ether2   1500  D4:CA:6D:41:78:C0  enabled  switch1
  2   S  ether3   1500  D4:CA:6D:41:78:BF  enabled  switch1
  3   S  ether4   1500  D4:CA:6D:41:78:BE  enabled  switch1
  4   S  ether5   1500  D4:CA:6D:41:78:BD  enabled  switch1
  5   S  ether6   1500  D4:CA:6D:41:78:BC  enabled         
  6   S  ether7   1500  D4:CA:6D:41:78:BB  enabled         
  7  RS  ether8   1500  D4:CA:6D:41:78:BA  enabled         
  8   S  ether9   1500  D4:CA:6D:41:78:B9  enabled         
  9   S  ether10  1500  D4:CA:6D:41:78:B8  enabled         
[admin@MikroTik] /interface/ethernet> 

The correct MAC is learned on the upstream switch. But there are now ARP entry on the Mikrotik
sw02#show mac address-table interface gigabitEthernet 1/0/1
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
 110    d4ca.6d41.78ba    STATIC      Gi1/0/1 
 111    0007.855c.8e3f    STATIC      Gi1/0/1 
Total Mac Addresses for this criterion: 2
sw02#

[admin@MikroTik] /ip/arp> print 
Flags: D - DYNAMIC, P - PUBLISHED
Columns: ADDRESS, INTERFACE
  #     ADDRESS          INTERFA
  0  D  192.168.110.123  bridge1
[admin@MikroTik] /ip/arp> 

NOTE: RB1100AHx2 is running fine with al ethernet ports https://i.mt.lv/cdn/product_files/Block ... 130548.pdf
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11968
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

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

Thu Jun 24, 2021 12:31 am

I have the same problem with ether1~ether5 on 6.46.8
I thought the RouterBOARD is broken,
but after what you wrote,
I want to try some previous versions.

Thanks for your hint.
 
nannou9
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Tue Nov 10, 2020 9:56 pm

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

Fri Jun 25, 2021 12:33 am

Just installed yesterday on RB4011 and using it now with NordVPN wireguard (not officially supported yet on MikroTik). Works really well, getting full 550MB internet speed.
Cpu jumps up 70%, but that is fine.
If anybody is interested can post instructions.
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Fri Jun 25, 2021 12:36 am

Yes, please! I think NordVPN uses something on top of wireguard and calls it "NordLynx"... Having the details here would much appreciated!
 
nannou9
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Tue Nov 10, 2020 9:56 pm

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

Fri Jun 25, 2021 1:09 am

Yes, please! I think NordVPN uses something on top of wireguard and calls it "NordLynx"... Having the details here would much appreciated!
See 1st post here: https://forum.openwrt.org/t/instruction ... nwrt/89976

Private key goes to the wireguard interface. Public key goes to the peer. Then you need to create routes and you are sorted. You also need to manually assign IP address to your wg interface same as done by nordlynx.

/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=wireguard-nordvpn-client1 pref-src=\
"" routing-table=via-wg suppress-hw-offload=no

/routing rule
add action=lookup-only-in-table disabled=no dst-address=10.0.0.0/24 src-address=\
10.0.0.0/24 table=main
add action=lookup-only-in-table disabled=no dst-address=0.0.0.0/0 src-address=\
10.0.0.0/24 table=via-wg

/ip address
add address=10.5.0.2 interface=wireguard-nordvpn-client1 network=10.5.0.2

Let me know if anything is unclear.
Last edited by nannou9 on Fri Jun 25, 2021 1:20 am, edited 1 time in total.
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Fri Jun 25, 2021 1:19 am

Well, you still need to run the nordvpn app to extract your private key... Though this can be done in a virtual machine I guess.
I will give it a try. Thanks!
 
nannou9
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Tue Nov 10, 2020 9:56 pm

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

Fri Jun 25, 2021 1:22 am

Well, you still need to run the nordvpn app to extract your private key... Though this can be done in a virtual machine I guess.
I will give it a try. Thanks!
Correct, this is exactly what I did as they require Debian or RHEL family while I am big fun of Funtoo (Gentoo).
You do t need X so minimal install will do. Unless you run it under windows, then you will need X and VM integration to be able to copy/paste between VM and host.
I did ssh from my Linux host to VM.
Unless you are big fun of docker, then you can do that from Linux container too with proper mounting of dev, sys, proc etc.
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Fri Jun 25, 2021 2:05 am

Running Arch Linux here... And did not succeed for now. :-/
Installed the app, connected successfully, but the network interface is of type "tun", not "wireguard". This "wg" can not read the private key.
Do recent versions of the app use the userspace implementation instead of upstream Linux support? What version of the app did you use?
root@vm ~ # nordvpn status         
Status: Connected
Current server: de971.nordvpn.com
Country: Germany
City: Frankfurt
Server IP: 5.180.62.69
Current technology: NordLynx
Current protocol: UDP
Transfer: 139.87 KiB received, 26.37 KiB sent
Uptime: 38 minutes 27 seconds
root@vm ~ # wg show nordlynx private-key
Unable to access interface: Operation not supported
 
User avatar
eworm
Forum Guru
Forum Guru
Posts: 1070
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

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

Fri Jun 25, 2021 2:12 am

Ah, got it. Looks like the app falls back to userspace implementation if the wireguard module is not loaded...
So this worked:
root@vm ~ # modprobe wireguard
root@vm ~ # nordvpn c de            
Connecting to Germany #931 (de931.nordvpn.com)
You are connected to Germany #931 (de931.nordvpn.com)!
root@vm ~ #  wg show nordlynx private-key
<private-key-here>
 
nannou9
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Tue Nov 10, 2020 9:56 pm

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

Fri Jun 25, 2021 10:02 am

Ah, got it. Looks like the app falls back to userspace implementation if the wireguard module is not loaded...
So this worked:
Well done mate
 
User avatar
frank333
Member
Member
Posts: 328
Joined: Mon Dec 18, 2017 12:17 pm
Location: S.Marino Router model: RB3011UiAS-RM+RBM11G

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

Sun Jun 27, 2021 5:43 pm

error.png
after a disconnection, the router reconnects 1 second later; but the indication connect failed remains in the interfaces lists menu. this should be reported as a bug. rbm11g modem em160
You do not have the required permissions to view the files attached to this post.
 
nannou9
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Tue Nov 10, 2020 9:56 pm

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

Sun Jun 27, 2021 10:44 pm

On my Audience I am still getting wifi1 (2.4GHz phy) dropouts.
The is happening consistently throughout beta 4,5,6.
All my clients are down and unable to reconnect.
In logs like 20 last messages for wifi1 are: "@wifi1 disconnected, group key timeout."

Nothing special in my config:
# jun/27/2021 20:41:19 by RouterOS 7.1beta6
# software id = FLQZ-RXUL
#
# model = RBD25G-5HPacQD2HPnD
# serial number = B6BE0A143FE7
/interface bridge
add name=bridge-trunk vlan-filtering=yes
/interface wifiwave2
add band=2ghz-n channel-width=20/40mhz-Ce configuration.country=Malaysia disabled=no mac-address=XXX mode=ap mtu=1500 name=wifi1 \
    security.authentication-types=wpa2-psk .disable-pmkid=yes ssid=X
add band=5ghz-ac channel-width=20/40/80mhz configuration.country=Malaysia disabled=yes mac-address=XXX mode=ap mtu=1500 name=wifi2 \
    security.authentication-types=wpa2-psk ssid="X"
# changed intended channel to 5500/ac/Ceee+5775
add band=5ghz-ac channel-width=20/40/80+80mhz configuration.country=Malaysia disabled=no mac-address=XXX mode=ap mtu=1500 name=wifi3 \
    security.authentication-types=wpa2-psk .disable-pmkid=yes ssid="X"
/interface vlan
add interface=bridge-trunk name=vlan1000 vlan-id=1000
Others were reporting similar issues.
This problem is present for at least half year consistently.
Only myself I am reporting this 2nd time.
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

Mon Jun 28, 2021 5:28 am

@nannou9 called attention to this problem:

Wireguard tunnels are selectable in the bridge->ports list. They should probably not appear there as they are layer-3-only tunnels like GRE, and I see that GRE interfaces do not appear in the bridge->ports list.
 
nannou9
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Tue Nov 10, 2020 9:56 pm

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

Mon Jun 28, 2021 9:04 pm

/ip/firewall/mangle/export doesn't work correctly for mark-routing action.
I have added rule
add action=mark-routing chain=prerouting comment="via WG" dst-address=0.0.0.0/0 passthrough=no src-address=10.0.0.0/16 new-routing-mark=via-gw
but it is exported as
add action=mark-routing chain=prerouting comment="via WG" dst-address=0.0.0.0/0 passthrough=no src-address=10.0.0.0/16
It is showing correctly however in webfig
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

Thu Jul 01, 2021 12:15 am

/ip/firewall/mangle/export doesn't work correctly for mark-routing action.
Did you add the routing table named "via-gw" first? It doesn't let you mark-routing for a routing mark unless that mark matches the name of a routing table defined on the router in v7.
 
nannou9
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Tue Nov 10, 2020 9:56 pm

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

Thu Jul 01, 2021 9:44 am

/ip/firewall/mangle/export doesn't work correctly for mark-routing action.
Did you add the routing table named "via-gw" first? It doesn't let you mark-routing for a routing mark unless that mark matches the name of a routing table defined on the router in v7.
Yes it is there and working correctly.
I noticed the export problem when I decided to archive my working config.
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 2855
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

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

Thu Jul 01, 2021 6:48 pm

@nannou9:

Please visit the link from my signature.
 
rplant
Member Candidate
Member Candidate
Posts: 282
Joined: Fri Sep 29, 2017 11:42 am

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

Fri Jul 02, 2021 2:30 am

/ip/firewall/mangle/export doesn't work correctly for mark-routing action.
Hi,
Try export verbose
 
nannou9
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Tue Nov 10, 2020 9:56 pm

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

Sat Jul 03, 2021 1:35 pm

Hi,
Try export verbose
nope, nothing.
Besides, my understanding of verbose is that it is printing defaults?
But my value is not default.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

Sat Jul 03, 2021 2:53 pm

Besides, my understanding of verbose is that it is printing defaults?
But my value is not default.
That is correct, what you observed is a bug (I think) but sometimes it is possible to gather more information by checking /export verbose and see what happens then.
When the value appears, the export function works but it incorrectly handles the non-default value.
When the value still does not appear, apparently it is never exported.
The developers should know what to do next...
 
nannou9
Frequent Visitor
Frequent Visitor
Posts: 65
Joined: Tue Nov 10, 2020 9:56 pm

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

Sat Jul 03, 2021 7:41 pm

My wifi1 phy is going down multiple times a day. It is very unpredictive.
There are days where everything is fine, others it is dropping all clients sometimes multiple times per hour.
Only reset helps and sometimes it is close to unusable.

This has been reported multiple times and is present in betas 4,5 and 6.
Can anybody from Mikrotik please comment?
 
indy
newbie
Posts: 25
Joined: Sun Mar 22, 2020 10:17 pm

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

Sun Jul 04, 2021 5:00 pm

Is anyone else seeing high CPU usage on their RB3011 with v7?
Routing 100Mbit/s with the default configuration shows <5% CPU usage on v.6.48.3.
v7.1b6 with the default configuration and same load shows about 30%.
L2 traffic between the 2 switching groups is slow as well.
I am getting a maximum of about 200Mbit/s between the 2 QCA8337,
This is the profile for that traffic
[admin@RB3011] /tool> profile
Columns: NAME, USAGE
  NAME          USAGE
  lcd           0.5% 
  ethernet      10.2%
  console       0%   
  firewall      0%   
  networking    21.5%
  management    0.2% 
  profiling     0%   
  bridging      2.2% 
  unclassified  12.2%
  total         46.8%
 
mazza
just joined
Posts: 17
Joined: Wed Feb 21, 2018 10:28 am

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

Fri Jul 09, 2021 6:45 pm

First of all, thanks to Mikrotik for bringing MLAG to the CRS3xx switches!

I tried the new MLAG feature with two CRS326-24S+2Q+RM and a Server running Linux as the Bonding partner. Unfortunately the Multi-chassis link aggregation group is not reliable for me. While it works after the initial configuration it stops working after some minutes of load on the interfaces. Sometimes it works 2 minutes, sometimes 20 minutes, before it stops forwarding traffic. Disconnecting one cable of the Bonding or rebooting one of the switches nearly always leads to a situation, where no packages are forwarded over the Bonding. In order to make sure that I did not have a problem on the Linux side, I created a normal 802.3ad Bonding on one of the CRS326-24S+2Q+RM with two other ports. Unexpectedly this also did not work reliable. Sometimes the single device Bond was able to forward traffic after disconnecting one cable sometimes it stops forwarding any traffic already after disconnection just one cable. Super interesting are the cases where the Bonding survived a cable disconnect (as it should), but stopped forwarding traffic if the cable has been reconnected. Interesting is also that a port is often shown as active in the status window after the cable is already disconnected.
Disabling and re-enabling the Bonding on the Switch seams to fix the problems with not forwarding any traffic, most of the time, at least for the single device LAG.

Since the MLAG and also a conventional LAG was very unreliable on RouterOS v7.1beta6, I configured a 802.3ad Bonding on a CRS 17-1G-16S+ running RouterOS v6.48.3. I connect the same Linux Server without any configuration changes to the CRS317-1G-16S+ and the Bonding works exactly as expected. I can disconnect and reconnect cables all day long and I loose maximal two pings, as long as at least one connection stays up.

My conclusion is that there is something broken with 802.3ad Bonding in RouterOS v7.1beta6. I hope, Mikrotik can find and fix that problem soon.

I'm exited about all the new hardware offloaded features Mikrotik is bringing the CRS3xx switches!
 
User avatar
junbr0
just joined
Posts: 10
Joined: Sat Jan 09, 2021 10:50 am

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

Sun Jul 11, 2021 9:51 am

guys, it is safe enough to update rb750 (mt v6.46.7) with gre_tunnel, ipsec and static routing ?
Last edited by junbr0 on Sun Jul 11, 2021 9:58 am, edited 1 time in total.
 
Cablenut9
Long time Member
Long time Member
Posts: 542
Joined: Fri Jan 08, 2021 5:30 am

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

Sun Jul 11, 2021 7:06 pm

It's July and we're due for beta7.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

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

Sun Jul 11, 2021 7:49 pm

It's July and we're due for beta7.
beta7 is apparently being sent to invited users at the moment, no idea why it is not distributed using the normal mechanism...
 
User avatar
memelchenkov
Member Candidate
Member Candidate
Posts: 202
Joined: Sun Oct 11, 2020 12:00 pm
Contact:

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

Sun Jul 11, 2021 8:07 pm

How to subscribe to updates for new versions of 7.0.x stable for Chateau? I downgraded to 7.0.3 from 7.1b4 and pretty happy with it. So I want to continue get updates for a stable channel.
 
infabo
Long time Member
Long time Member
Posts: 586
Joined: Thu Nov 12, 2020 12:07 pm

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

Mon Jul 12, 2021 12:45 am

Something for a dedicated thread/discussion?
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

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

Mon Jul 12, 2021 10:30 am

It's July and we're due for beta7.
I have no "insider information", but I personally suspect beta7 might take a bit longer rather than the usual two month window between releases, if only due to the fact that they have been redesigning and re-implementing the route filter system from the ground up from beta6. If they were able to do that in two months I would be very surprised as that is a big task.
 
User avatar
frank333
Member
Member
Posts: 328
Joined: Mon Dec 18, 2017 12:17 pm
Location: S.Marino Router model: RB3011UiAS-RM+RBM11G

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

Mon Jul 12, 2021 10:34 am

It depends on the staff, I think, if they are full they can do it.
https://help.mikrotik.com/docs/display/ ... col+Status
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 2095
Joined: Mon Jan 14, 2008 1:53 pm
Location: Over the Rainbow
Contact:

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

Mon Jul 12, 2021 11:41 am

I just noticed these four items:

* LDP IPv6 mapping
* Fast reroute
* MPLS ECMP
* One label per VRF

On the "Protocol Status" page.

They have been a long time coming, and I am very excited to see Mikrotik showing them on the closest thing we have to a "Roadmap"

Who is online

Users browsing this forum: No registered users and 22 guests