Page 1 of 1

v7.1beta5 [development] is released!

Posted: Wed Mar 17, 2021 1:46 pm
by emils
RouterOS version 7.1beta5 has been released in public "development" channel!

What's new in 7.1beta5 (2021-Mar-16 14:41):

!) added new "iot" package with initial Bluetooth (KNOT only) and MQTT publisher support;
!) ported features and fixes introduced in v6.48.1;
!) enabled initial MPLS support (CLI only);
*) export - fixed "export" command hanging;
*) wifiwave2 - improved interface stability with multiple WPA3 authenticated clients;
*) other minor fixes and improvements;

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

How to report RouterOS v7 bugs:
viewtopic.php?f=1&t=152006

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

Posted: Wed Mar 17, 2021 2:06 pm
by pe1chl
I had a test CHR on VMware ESXi 6.7 running 7.1beta4 with a quite simple config (1 interface, fixed address, a BGP session)
I used System->Packages upgrade to load 7.1beta5

It fails to boot now. On the console it says:
Load system

WARN: GPT: skip truncate
ERROR: could not mount disk!
Please attach it somewhere else.
Removed VM and re-created it from .ova template to fix it.

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

Posted: Wed Mar 17, 2021 2:32 pm
by StubArea51
I just uploaded it to EVE-NG and am working through adding some config I used with previous beta versions.

It looks like the routing filters have changed slightly. What string value is expected?

This is what I see in beta5....the only option is "rule=" that I can see, I can't add match-prfx-value

/routing filter rule add chain=ospf_out rule=

Rule -- string value

This is the syntax shown in help.mikrotik.com
/routing filter rule add chain=ospf_out match-prfx-value="dst<subsumes>182.168.0.0/16" action=accept

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

Posted: Wed Mar 17, 2021 3:20 pm
by Cablenut9
Still no wifiwave2 with cAPsMAN support...

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

Posted: Wed Mar 17, 2021 3:24 pm
by karlisi
I had a test CHR on VMware ESXi 6.7 running 7.1beta4 with a quite simple config (1 interface, fixed address, a BGP session)
I used System->Packages upgrade to load 7.1beta5

It fails to boot now. On the console it says:
Load system

WARN: GPT: skip truncate
ERROR: could not mount disk!
Please attach it somewhere else.
Removed VM and re-created it from .ova template to fix it.
The same here, CHR on XenServer 7. And the same was with upgrade to 7.1beta4. Something seems broken with CHR upgrades.

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

Posted: Wed Mar 17, 2021 3:32 pm
by emils
Can any one of you send us a RAW disk image from damaged CHR?

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

Posted: Wed Mar 17, 2021 3:39 pm
by mrz
I just uploaded it to EVE-NG and am working through adding some config I used with previous beta versions.

It looks like the routing filters have changed slightly. What string value is expected?
Now routing rule has script-like syntax. Try
routing filter rule add rule={ <tab>

to see possible parameters.
One basic example:
add rule={ if ([protocol static] || [protocol connected]) then={ num-value distance<assign>100; action accept}}

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

Posted: Wed Mar 17, 2021 4:03 pm
by mada3k
!) enabled initial MPLS support (CLI only);
Thanks! That a important one

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

Posted: Wed Mar 17, 2021 4:18 pm
by ivantirado
In routing filter, is set-type=blackhole supported? I noticed it wasn't supported in previous betas.

Like this:

chain=malware-in address-family=ip invert-match=no action=accept set-type=blackhole set-bgp-prepend-path=""

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

Posted: Wed Mar 17, 2021 5:34 pm
by infabo
The "Quick Set" of WebFig always resets to "WISP AP". I switch it to "LTE AP Dual" and logout. On next login it is "WISP AP" again. That was'nt the case in beta4.

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

Posted: Wed Mar 17, 2021 6:05 pm
by Cablenut9
The "Quick Set" of WebFig always resets to "WISP AP". I switch it to "LTE AP Dual" and logout. On next login it is "WISP AP" again. That was'nt the case in beta4.
This happens to me in v6 too

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

Posted: Wed Mar 17, 2021 6:25 pm
by pe1chl
Can any one of you send us a RAW disk image from damaged CHR?
I only have a copy of the machine as it was before I attempted the upgrade. I can send it when no others have a copy of the failed one.

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

Posted: Wed Mar 17, 2021 7:03 pm
by kenakapheus
I can confirm the issue even when upgrading an completely fresh v7.1beta4 CHR so most likely the problem is not caused by any specific configuration.
I will send the resulting non working file via email directly to mikrotik as it is to big to attach it to this post.

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

Posted: Wed Mar 17, 2021 7:34 pm
by tpedko
WifiWave2 in 2.4GHz wireless work on RB4011iGS+5HacQ2HnD?

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

Posted: Wed Mar 17, 2021 7:44 pm
by infabo
The "Quick Set" of WebFig always resets to "WISP AP". I switch it to "LTE AP Dual" and logout. On next login it is "WISP AP" again. That was'nt the case in beta4.
This happens to me in v6 too
maybe due to:
ported features and fixes introduced in v6.48.1;
:D

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

Posted: Wed Mar 17, 2021 8:31 pm
by sarada
I had a test CHR on VMware ESXi 6.7 running 7.1beta4 with a quite simple config (1 interface, fixed address, a BGP session)
I used System->Packages upgrade to load 7.1beta5

It fails to boot now. On the console it says:
Load system

WARN: GPT: skip truncate
ERROR: could not mount disk!
Please attach it somewhere else.
Removed VM and re-created it from .ova template to fix it.
The same here, CHR on XenServer 7. And the same was with upgrade to 7.1beta4. Something seems broken with CHR upgrades.
Same here, the difference is that I use Proxmox VE, with qcow2 disk, Virtio SCSI interface, simple SeaBIOS / i440fx combination and 3 VirtIO ethernet adapters.

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

Posted: Wed Mar 17, 2021 8:37 pm
by sid5632
Mine fails to boot too. My message is slightly different though:
Load system

Resizing disk(GPT)...
ERROR: could not mount disk!
Please attach it somewhere else.

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

Posted: Wed Mar 17, 2021 9:00 pm
by SirPrikol
Hello everyone, where are the promised BGP filters?
This is the only thing that stops me from moving to v7.

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

Posted: Wed Mar 17, 2021 9:22 pm
by Mikuser17
Capsman issue?
Using beta 5 I see packets from/to caps provisioned using slave configuration are not forwarded.
Clients get an IP from dhcp and arp tables looks ok
Upgraded from a working beta 4, using cap ac's
Anybody else having similar issues using capsman?
KR

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

Posted: Wed Mar 17, 2021 9:23 pm
by NeoPhyTex360
Cake reboots seems to be fixed in beta5, will report if any random reboot



Edit: Not fixed. Shitty random reboots with cake still happening. Usable beta in year 2030


RB4011

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

Posted: Wed Mar 17, 2021 9:36 pm
by pe1chl
Hello everyone, where are the promised BGP filters?
This is the only thing that stops me from moving to v7.
See reply #7 above.

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

Posted: Wed Mar 17, 2021 9:37 pm
by mafiosa
Hello everyone, where are the promised BGP filters?
This is the only thing that stops me from moving to v7.
same here buddy, would request mikrotik to update the v7 routing protocol status page in help.mikrotik.com ASAP

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

Posted: Wed Mar 17, 2021 9:45 pm
by pe1chl
When I use BGP and check the "Peer Cache" tab I see an active connection and I receive the routes, but "number of prefixes" in the table is 0.

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

Posted: Wed Mar 17, 2021 10:12 pm
by infabo
kernel panic reboot only after a few hours with beta5
kernel failure in previous boot

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

Posted: Wed Mar 17, 2021 10:32 pm
by nannou9
kernel panic reboot only after a few hours with beta5
kernel failure in previous boot
Mate your post is useless. You provide no info at all.
Give some model details, post config export etc.

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

Posted: Wed Mar 17, 2021 10:44 pm
by anuser
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.

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

Posted: Wed Mar 17, 2021 11:28 pm
by gtj0
RB750Gr2: Install from Webfig hangs at "calculating download size". Upload via Files resulted in boot loop. Reinstall 7.1beta5 via netinstall works but WebFig is completely broken. It returns a single response when accessed for teh first time after a reboot, then returns no responses to any further requests. Winbox is also completely broken when the device is accessed via IP address. OK if you connect via MAC address.

922UAGS-5HPacT: NetMetal 5: Install from Webfig failed with same hang at "calculating download size". Upload via Files worked OK. Same problem with WebFig and Winbox.

Not bothering to try any other devices in the lab. No WebFig is a deal breaker.

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

Posted: Wed Mar 17, 2021 11:59 pm
by Paternot
CHR RoS v7.1beta4 upgrade to 7.1beta5 -> no boot.
No configuration done. Just created a new VM with 7.1beta4 and upgraded it to beta5 via webfig.

Using OpenSuse Leap 15.2 and KVM.
VM with 1GiB RAM and 2 vCPUs.

A new vm with beta5 boots up ok. There is a problem only when I upgrade from beta4 to beta5.
Screenshot below.

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

Posted: Thu Mar 18, 2021 12:12 am
by infabo
kernel panic reboot only after a few hours with beta5
kernel failure in previous boot
Mate your post is useless. You provide no info at all.
Give some model details, post config export etc.
Indeed. It's useless ranting. I provided like 12 autosupout.rif files to Mikrotik support over the time of about 2 weeks. I assume these autosuport.rif files generated by the watchdog include all the info they need about my device and its config. But no response.

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

Posted: Thu Mar 18, 2021 12:13 am
by infabo
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.
I agree with this. I would test that package too.

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

Posted: Thu Mar 18, 2021 12:55 am
by lcohen999
My audience is updated

We will see if/when we kernel panic

Still getting this error

error while running customized default configuration script: interrupted

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

Posted: Thu Mar 18, 2021 1:18 am
by krzysztof
The same error continues.

In X86 v7.1 beta 5 doesn't boot directly from CD Image

After a few tries, I started OS 7.1beta5 on X86
But it cannot be done directly from CD Image.
OS will not start.
You need to upgrade from OS 6.48.1 to 7.1beta5.
Then OS 7.1beta5 on X86 will start
The OS has finally started and I am starting tests

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

Posted: Thu Mar 18, 2021 1:32 am
by mducharme
/tool torch is still excluding all IPv6 traffic.

For those having issues with reboots, make sure you upgrade the RouterBOOT firmware. I forgot to do that when going from beta3 to beta4 and my beta4 was spontaneously rebooting once every several hours. Upgrading the RouterBOOT firmware fixed it and my 4011 was completely stable on Beta4.

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

Posted: Thu Mar 18, 2021 2:04 am
by infabo
Thanks for the hint. But I have routerboard "auto-upgrade" set to "yes" for quite some time now - for the exact same reason.

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

Posted: Thu Mar 18, 2021 2:14 am
by NickOlsen
Can any one of you send us a RAW disk image from damaged CHR?
I have emailed a link to the disk to support.

I was running 7.1 Beta 4. Upgraded to Beta 5 via Packages>Check for update

The CHR never returned from a reboot. At first it said the previously mentioned disk error. So I hard reset the VM. Now on every boot it kernel panics and reboots (Before fully booting). Config was extremely basic. Just a DHCP client on ether1 for the most part.

Ticket 44747

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

Posted: Thu Mar 18, 2021 3:04 am
by jeremy8810
Does anyone know what you can send trough MQTT yet?

Can we send e.g. interface up / interface down and publish it to an mqtt server? If so, how to do that?

I see you can add an mqtt broker, and do something in the publish screen...? But what...?

Maybe you can lateron choose the logging to set via mqtt?? Anyone played with it already?

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

Posted: Thu Mar 18, 2021 3:12 am
by fflo
!) enabled initial MPLS support (CLI only);
Thanks! That a important one
Yes. Does it already work in combination with BGP4 VRF?

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

Posted: Thu Mar 18, 2021 3:57 am
by timoid
Mine fails to boot too. My message is slightly different though:
Load system

Resizing disk(GPT)...
ERROR: could not mount disk!
Please attach it somewhere else.
For those seeing these GPT errors - you have to give the VM more HDD space.

For me I had mine set to the default? 64MB. I increased to 256MB and it resolved my issue without loss of configuration.

Looks like its converting from MBR to GPT, so you need extra space for the FAT32 UEFI partition I'm guessing.

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

Posted: Thu Mar 18, 2021 4:09 am
by mhugo

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

Posted: Thu Mar 18, 2021 4:32 am
by Paternot
For those seeing these GPT errors - you have to give the VM more HDD space.

For me I had mine set to the default? 64MB. I increased to 256MB and it resolved my issue without loss of configuration.

Looks like its converting from MBR to GPT, so you need extra space for the FAT32 UEFI partition I'm guessing.
Yes, it did the trick for me.

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

Posted: Thu Mar 18, 2021 7:41 am
by FToms
WifiWave2 in 2.4GHz wireless work on RB4011iGS+5HacQ2HnD?
There are no plans to add support for AR9300 interfaces to the wifiwave2 package.

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

Posted: Thu Mar 18, 2021 7:52 am
by Jotne
Hello everyone, where are the promised BGP filters?
This is the only thing that stops me from moving to v7.
same here buddy, would request mikrotik to update the v7 routing protocol status page in help.mikrotik.com ASAP
So that this is an unstable beta release is not importante and if it has this function, you will use it in production???

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

Posted: Thu Mar 18, 2021 9:20 am
by ib254254
95% of the existing wireless equipment, which is 2.4GHz, will not receive WiFiWave2 support.

This means that we cannot currently use the 2.4GHz wireless card of any of them, except for almost 2.3 MikroTik using WiFiWave2.

In the future, MikroTik may consider running a 5GHz driver bundle for 2.4GHz for 1st generation equipment.

But do not rely too much on the MikroTik team on this issue.

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

Posted: Thu Mar 18, 2021 9:58 am
by emils
Unfortunately looks like CHR upgrade from beta4 to beta5 may break the image. Upgrading straight from version 6 to the latest v7 beta should not cause such issues if previous v7 betas were never installed on the system. You may attempt to fix already broken image like this:
dd if=/dev/zero of=your-disk-image.raw bs=512 seek=1 count=2 conv=notrunc

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

Posted: Thu Mar 18, 2021 10:34 am
by mhugo

So that this is an unstable beta release is not importante and if it has this function, you will use it in production???
Try running 2004s. They have issues not existing in ROS7 like reboots and package loss that neither are fully fixed even in latest testing, so I can see that it's tempting.

/M

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

Posted: Thu Mar 18, 2021 10:56 am
by lav31
OVPN does not work - version 7.1beta5
Mar/18/2021 10:52:20 ovpn,info zaborona: initializing...
Mar/18/2021 10:52:20 ovpn,info zaborona: connecting...
Mar/18/2021 10:52:21 ovpn,info zaborona: using encoding - AES-128-CBC/SHA1
Mar/18/2021 10:52:22 ovpn,info zaborona: terminating... - wrong OVPN data
Mar/18/2021 10:52:22 ovpn,info zaborona: disconnected
Mar/18/2021 10:52:22 ovpn,info zaborona: initializing...
Mar/18/2021 10:52:22 ovpn,info zaborona: connecting...
Mar/18/2021 10:52:23 ovpn,info zaborona: using encoding - AES-128-CBC/SHA1
Mar/18/2021 10:52:23 ovpn,info zaborona: terminating... - wrong OVPN data
Mar/18/2021 10:52:23 ovpn,info zaborona: disconnected
Mar/18/2021 10:52:23 ovpn,info zaborona: initializing...
Mar/18/2021 10:52:23 ovpn,info zaborona: connecting...
Mar/18/2021 10:52:23 ovpn,info zaborona: terminating... - could not connect
Mar/18/2021 10:52:23 ovpn,info zaborona: disconnected
Mar/18/2021 10:52:24 ovpn,info zaborona: initializing...
Mar/18/2021 10:52:24 ovpn,info zaborona: connecting...
Mar/18/2021 10:52:25 ovpn,info zaborona: using encoding - AES-128-CBC/SHA1
Mar/18/2021 10:52:25 ovpn,info zaborona: terminating... - wrong OVPN data
Mar/18/2021 10:52:25 ovpn,info zaborona: disconnected
In version 6.48.1 OVPN it works

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

Posted: Thu Mar 18, 2021 12:27 pm
by sarada
Mine fails to boot too. My message is slightly different though:
Load system

Resizing disk(GPT)...
ERROR: could not mount disk!
Please attach it somewhere else.
For those seeing these GPT errors - you have to give the VM more HDD space.

For me I had mine set to the default? 64MB. I increased to 256MB and it resolved my issue without loss of configuration.

Looks like its converting from MBR to GPT, so you need extra space for the FAT32 UEFI partition I'm guessing.
I can confirm if you add extra space, the upgrade from beta 4 to beta5 will be successful.

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

Posted: Thu Mar 18, 2021 12:40 pm
by pe1chl
I can confirm if you add extra space, the upgrade from beta 4 to beta5 will be successful.
Interestingly, the beta5 fresh install I made still has a 64MB disk. Would it be recommended to increase that already?
(this is of course a very small file on a VM host... no idea why they do not take 128 or 256MB)

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

Posted: Thu Mar 18, 2021 12:59 pm
by eworm
There has been a discussion before that images should be 128 MB at least.
I had this issue long time ago with a CHR.

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

Posted: Thu Mar 18, 2021 1:15 pm
by infabo
95% of the existing wireless equipment, which is 2.4GHz, will not receive WiFiWave2 support.
I don't get your point. wave2 is a 802.11ac extension AFAIK.

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

Posted: Thu Mar 18, 2021 1:38 pm
by Chupaka
Unfortunately looks like CHR upgrade from beta4 to beta5 may break the image.
Is it a problem with beta4 or beta5?

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

Posted: Thu Mar 18, 2021 1:57 pm
by dksoft
Using remote logging, eg.
/system logging action
set 3 bsd-syslog=yes remote=10.0.0.2 syslog-severity=info
leads to only \00 characters on the syslog server.
This worked well on 6.48.1

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

Posted: Thu Mar 18, 2021 2:09 pm
by dksoft
May someone please give me a hint what might cause this problem:
[admin@router] > ping 2a00:1450:4001:801::2003
  SEQ HOST                                     SIZE TTL TIME       STATUS                                                                                                                    
    0                                                              22 (Invalid argument)   
 
After upgrading to 7.1b5 my router does no longer ping to global addresses nor forward IPv6.
Local addresses like fd00::2 work fine.

Here is some configuration. I am happy to provide more.
[admin@router] /ipv6/address> print
Flags: D - DYNAMIC; G - GLOBAL, L - LINK-LOCAL
Columns: ADDRESS, FROM-POOL, INTERFACE, ADVERTISE
   #      ADDRESS                       FROM-POOL  INTERFACE             ADV
;;; IPv6 ULA address
   0   G  fd00::1/64                               LAN                   yes
;;; IPv6 GUA address (Telekom)
   1   G  2003:f4:770c:3000::1/64       GUA-pool6  LAN                   yes
   
   [admin@router] /ipv6/route> print
Flags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; c - CONNECT, d - DHCP, v - VPN, y - COPY; H - HW-OFFLOADED; + - ECMP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
         DST-ADDRESS                     GATEWAY                            D
  DAd +  ::/0                            fe80::9ecc:83ff:fecb:fd7f%TELEKOM  1
  DAv +  ::/0                            TELEKOM                            1
  DAd    2003:f4:770c:3000::/56                                             1
  DAc    2003:f4:770c:3000::/64          LAN                                0

[admin@router] /ipv6/settings> print
                  disable-ipv6: no
                       forward: yes
              accept-redirects: no
  accept-router-advertisements: yes-if-forwarding-disabled
          max-neighbor-entries: 8192
          
          [admin@router] /ipv6/pool> print
Flags: D - DYNAMIC
Columns: NAME, PREFIX, PREFIX-LENGTH, EXPIRES-AFTER
  #     NAME       PREFIX                  PR  EXPIRES-
  0     ULA-pool6  fd00::/64               64          
  1  D  GUA-pool6  2003:f4:770c:3000::/56  64  3h50m23s


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

Posted: Thu Mar 18, 2021 2:10 pm
by pe1chl
There has been a discussion before that images should be 128 MB at least.
I had this issue long time ago with a CHR.
Then maybe MikroTik should put that in their .ova files and/or make the disk images that size?

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

Posted: Thu Mar 18, 2021 2:11 pm
by pe1chl
Unfortunately looks like CHR upgrade from beta4 to beta5 may break the image.
Is it a problem with beta4 or beta5?
I think the problem was in beta4 as well, when I upgraded to beta4 I also had problems but I do not exactly remember what. I started from scratch then as well.

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

Posted: Thu Mar 18, 2021 2:13 pm
by emils
Is it a problem with beta4 or beta5?
It is a problem with all previous v7 versions and related to the partition table. In short, v6 used MBR, after upgrading to v7 (before beta5), it created incorrect GPT, but still used MBR (so everything actually seemed to work). In beta5 GPT is now preferred, but as it is already incorrectly created in previous betas, the issue occurs. Upgrade from v6 to v7beta5 creates correct GPT table.

I do not remember seeing any issues with 64MB disk sizes explicitly. It should work just fine. Have you reported your issues to support?

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

Posted: Thu Mar 18, 2021 2:20 pm
by mducharme
Thanks for the hint. But I have routerboard "auto-upgrade" set to "yes" for quite some time now - for the exact same reason.
The other thing I did was I did not just upgrade - I exported my config to an rsc, upgraded, reset to no default configuration, and pasted it back in. Without doing that, beta4 was unusable for me. The issue is that the config syntax is not properly auto converted from earlier betas so if there is wrong syntax that has changed in the new version and the config does not convert, there can be unpredictable behavior as a result.

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

Posted: Thu Mar 18, 2021 2:21 pm
by mducharme
OSPFv3 is still broken in beta5 - getting "wrong checksum" from everything, same as in beta4.

Is there any chance of getting RDNSS search list option added? https://tools.ietf.org/html/rfc8106#section-5.2

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

Posted: Thu Mar 18, 2021 2:27 pm
by eworm
I do not remember seeing any issues with 64MB disk sizes explicitly. It should work just fine. Have you reported your issues to support?
I reported in the v6.42rc release thread.

Fixed it with larger image, guess I did not contact the support.

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

Posted: Thu Mar 18, 2021 6:08 pm
by Paternot
Unfortunately looks like CHR upgrade from beta4 to beta5 may break the image.
Is it a problem with beta4 or beta5?
I think beta5 - it wants to extend the disk's size. If one downloads the disk image to beta5 it just works. When someone upgrades from beta4 to beta5 the problem appears. If before the upgrade You extend your virtual disk, then it works.

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

Posted: Thu Mar 18, 2021 6:42 pm
by BelWaveNOC
RB4011:

VPLS interface - router crashes once interface goes into an up state.

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

Posted: Thu Mar 18, 2021 6:50 pm
by pe1chl
Extending the disk size (the filesystem on the available disk space) is done on every reboot. When you extend the disk size "live" in the VM environment and look in System->Resources, nothing has happened (so it does not trigger this merely when the disk size changes), but when you then reboot and check again, it has been extended.
So this normally works OK but it probably is conflicting with something that happens during upgrade.
It looks like the problem has already been studied by MikroTik and will likely be resolved or we will get some recommendation like 'please extend your disk to 128M before upgrade' when that is the disk size required in the future.

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

Posted: Thu Mar 18, 2021 6:54 pm
by Paternot
Extending the disk size (the filesystem on the available disk space) is done on every reboot. When you extend the disk size "live" in the VM environment and look in System->Resources, nothing has happened (so it does not trigger this merely when the disk size changes), but when you then reboot and check again, it has been extended.
So this normally works OK but it probably is conflicting with something that happens during upgrade.
Yes. We have an official answer, some posts above. Looks like RoS7.1 created the GPT table incorrectly. It kinda worked, as it was using MBR. 7.1beta5 changed that - hence the problem. Looks like it's problem solved, and beta5 -> beta6 will not have the same issue.

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

Posted: Thu Mar 18, 2021 7:43 pm
by Chupaka
Yeah, so as I installed v7 initially (not upgrading from MBR's v6), looks like it created GPT from the beginning, so the upgrade from beta4 to beta5 went smoothly.

P.S. My disk size is 50G (Oracle Cloud), and 16G is shown in System -> Resources.

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

Posted: Thu Mar 18, 2021 8:08 pm
by rb9999
My CHR upgrade of 7.1beta4 to beta5 failed due to the same "Resizing disk" as other users'. I would like to note that I expanded qcow2 image to 1GB when prior first run of beta4 months ago, so disk size shouldn't have been an issue...
[root@virtual-1 3Timages]# qemu-img info chr-7.1beta4.qcow2
image: chr-7.1beta4.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 45M
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

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

Posted: Thu Mar 18, 2021 8:16 pm
by lcohen999
24 hours in, no random kernel panics or WiFi randomly dropping out on my Audience

just these log entries on reboot

DefConf gen: Unable to find wireless interface(s)
error while running customized default configuration script: interrupted

and one blank one

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

Posted: Thu Mar 18, 2021 9:10 pm
by Raffi
Bildschirmfoto 2021-03-18 um 20.08.01.png
PPPoE interfaces no longer counting outbound traffic in beta5 (on a rb4011).

Raffi

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

Posted: Thu Mar 18, 2021 9:27 pm
by Raffi
After upgrading to 7.1b5 my router does no longer ping to global addresses nor forward IPv6.
Local addresses like fd00::2 work fine.

Confirmed. Same problem here.

Raffi

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

Posted: Thu Mar 18, 2021 11:15 pm
by gtj0
RB750Gr2: Install from Webfig hangs at "calculating download size". Upload via Files resulted in boot loop. Reinstall 7.1beta5 via netinstall works but WebFig is completely broken. It returns a single response when accessed for teh first time after a reboot, then returns no responses to any further requests. Winbox is also completely broken when the device is accessed via IP address. OK if you connect via MAC address.

922UAGS-5HPacT: NetMetal 5: Install from Webfig failed with same hang at "calculating download size". Upload via Files worked OK. Same problem with WebFig and Winbox.

Not bothering to try any other devices in the lab. No WebFig is a deal breaker.
Am I the only one with broken WebFig?

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

Posted: Fri Mar 19, 2021 12:35 am
by pe1chl
Am I the only one with broken WebFig?
Maybe... Webfig works fine here.

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

Posted: Fri Mar 19, 2021 12:48 am
by nemoforum
Mikrotik!
I kindly ask you to release wave2 extra packages separately for each CPU in order to fit 16MB Flash.
It is possible to run wave2 driver on 16MB Flash and 128 RAM.

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

Posted: Fri Mar 19, 2021 1:49 am
by Cablenut9
Mikrotik!
I kindly ask you to release wave2 extra packages separately for each CPU in order to fit 16MB Flash.
It is possible to run wave2 driver on 16MB Flash and 128 RAM.
Other vendors can make wave2 work with 16MB, so why not the Big Mik too?

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

Posted: Fri Mar 19, 2021 1:24 pm
by infabo
Mikrotik!
I kindly ask you to release wave2 extra packages separately for each CPU in order to fit 16MB Flash.
It is possible to run wave2 driver on 16MB Flash and 128 RAM.
Other vendors can make wave2 work with 16MB, so why not the Big Mik too?
TP-Link home-equipment devices can do in 16MB flash and less RAM than 256MB.

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

Posted: Fri Mar 19, 2021 2:16 pm
by pe1chl
Other vendors can make wave2 work with 16MB, so why not the Big Mik too?
I have WiFi Wave2 APs from a wellknown competitor but their firmware image is 14 MB and this is only for an AP managed by a separate controller.
And it is a compressed image, the unpacked files on the flash require 39 MB. Of course MikroTik can unpack it in RAM when they want.
The flash size on this device is 256 MB so lots of free space.

For a device with full UI and other functions like a MikroTik device has (router) probably some 8 MB more is required.
Maybe it can all be crunched down but is it worth the effort? Sure it is for the consumer with a 16MB flash device...

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

Posted: Fri Mar 19, 2021 4:31 pm
by gtj0
Am I the only one with broken WebFig?
Maybe... Webfig works fine here.
Which platform?

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

Posted: Fri Mar 19, 2021 4:52 pm
by infabo
Other vendors can make wave2 work with 16MB, so why not the Big Mik too?
I have WiFi Wave2 APs from a wellknown competitor but their firmware image is 14 MB and this is only for an AP managed by a separate controller.
And it is a compressed image, the unpacked files on the flash require 39 MB. Of course MikroTik can unpack it in RAM when they want.
The flash size on this device is 256 MB so lots of free space.

For a device with full UI and other functions like a MikroTik device has (router) probably some 8 MB more is required.
Maybe it can all be crunched down but is it worth the effort? Sure it is for the consumer with a 16MB flash device...
Worth the effort? wave2 package is compatible with 4 devices. Is it worth the effort, to develop a wave2 package for just 4 devices?

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

Posted: Fri Mar 19, 2021 5:00 pm
by infabo
I guess I made it around the kernel panics as I have uptime of 1d and 4h right now already.

What did I change?

I configured a simple queue with cake since 7.1beta3.
I noticed a property in the cake queue type that I did not set by myself and according to wiki (https://help.mikrotik.com/docs/display/ ... ueues-CAKE) should be empty/0 by default:
cake-memlimit=32.0MiB kind=cake name=cake
I deleted and recreated that queue-type and now the cake-memlimit=0 seems to have positive impact on the device-stability.

EDIT:

kernel panic is back in the game!
router was rebooted without proper shutdown, probably kernel failure

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

Posted: Fri Mar 19, 2021 5:08 pm
by pe1chl
Am I the only one with broken WebFig?
Maybe... Webfig works fine here.
Which platform?
CHR. I only run v7 as a test right now.

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

Posted: Fri Mar 19, 2021 5:11 pm
by pe1chl
Worth the effort? wave2 package is compatible with 4 devices. Is it worth the effort, to develop a wave2 package for just 4 devices?
I think developing wave2 now is a way to break out of the "we have no software for wave2 - we have no devices that can do wave2 - why should we sell devices that can do wave2 when we don't have software for it anyway" cycle.
Once wave2 is working, no doubt new devices will appear that do support it.
And hopefully devices with only 16MB flash can do it then as well, as that seems to be the normal thing for MikroTik to sell these days.
(devices with more flash are few and far between)

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

Posted: Fri Mar 19, 2021 6:19 pm
by infabo
Worth the effort? wave2 package is compatible with 4 devices. Is it worth the effort, to develop a wave2 package for just 4 devices?
I think developing wave2 now is a way to break out of the "we have no software for wave2 - we have no devices that can do wave2 - why should we sell devices that can do wave2 when we don't have software for it anyway" cycle.
Once wave2 is working, no doubt new devices will appear that do support it.
And hopefully devices with only 16MB flash can do it then as well, as that seems to be the normal thing for MikroTik to sell these days.
(devices with more flash are few and far between)
It would make no sense not releasing wave2 for 16MB devices at some point. At least customers would not understand such a decision. MikroTik just launched a Chateau 5G device for 500$ with just 16MB - but with IPQ4019 and plenty of RAM.

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

Posted: Fri Mar 19, 2021 6:55 pm
by mada3k
It's indeed strange. They tend to rely on SPI NOR-flash on cheaper devices or switches, witch is sufficient for the most cases. But limited to 16MB (exists 32MB as well, not always supported by the SoC). Raw NAND flash is cheap but has much higher pin-count (adds PCB complexity)

But today eMMC prices has dropped significantly, and for a powerfull and multi-functional device as a a Chateau, it should be obvious choise.

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

Posted: Fri Mar 19, 2021 7:35 pm
by haedertowfeq
I guess I made it around the kernel panics as I have uptime of 1d and 4h right now already.

What did I change?

I configured a simple queue with cake since 7.1beta3.
I noticed a property in the cake queue type that I did not set by myself and according to wiki (https://help.mikrotik.com/docs/display/ ... ueues-CAKE) should be empty/0 by default:
cake-memlimit=32.0MiB kind=cake name=cake
I deleted and recreated that queue-type and now the cake-memlimit=0 seems to have positive impact on the device-stability.

EDIT:

kernel panic is back in the game!
router was rebooted without proper shutdown, probably kernel failure
I have same reboot ..
HexS
Simple queue with cake as queue type
With any configuration to this type


تم الإرسال من Redmi Note 8 Pro باستخدام Tapatalk


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

Posted: Fri Mar 19, 2021 8:33 pm
by timoid
My CHR upgrade of 7.1beta4 to beta5 failed due to the same "Resizing disk" as other users'. I would like to note that I expanded qcow2 image to 1GB when prior first run of beta4 months ago, so disk size shouldn't have been an issue...
[root@virtual-1 3Timages]# qemu-img info chr-7.1beta4.qcow2
image: chr-7.1beta4.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 45M
might need to take it up with support, they were chasing disk images.

I don't understand the relationship with virtual size and disk size on qcow2 format.

otherwise you could use a partition resizer - take a backup/snapshot first.

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

Posted: Fri Mar 19, 2021 10:24 pm
by infabo
Cake reboots seems to be fixed in beta5, will report if any random reboot



Edit: Not fixed. Shitty random reboots with cake still happening. Usable beta in year 2030


RB4011

I guess I made it around the kernel panics as I have uptime of 1d and 4h right now already.

What did I change?

I configured a simple queue with cake since 7.1beta3.
I noticed a property in the cake queue type that I did not set by myself and according to wiki (https://help.mikrotik.com/docs/display/ ... ueues-CAKE) should be empty/0 by default:
cake-memlimit=32.0MiB kind=cake name=cake
I deleted and recreated that queue-type and now the cake-memlimit=0 seems to have positive impact on the device-stability.

EDIT:

kernel panic is back in the game!
router was rebooted without proper shutdown, probably kernel failure
I have same reboot ..
HexS
Simple queue with cake as queue type
With any configuration to this type


تم الإرسال من Redmi Note 8 Pro باستخدام Tapatalk
I now disabled cake simple queue. See if that helps.

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

Posted: Sat Mar 20, 2021 6:41 am
by blurrybird
Anyone else having issues with IPv6 on v7?

Specs:
Device: hAP ac2
OS: 7.1beta5
Purpose: DHCP, DNS, Simple FQ_CODEL Queue, Basic Firewall, IPv6 RA of ISP provided subnet

On v6.48.1 my devices would successfully load sites such as ipv6.google.com.
On v7.1beta4 and v7.1beta5 my devices receive an IPv6 address and can ping IPv6 endpoints such as ipv6.google.com but they cannot browse to them over HTTP/HTTPS. Curl also fails.

Happy to gather any info required to assist debugging.

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

Posted: Sat Mar 20, 2021 10:58 am
by Raffi
Anyone else having issues with IPv6 on v7?

See above. IPv6 seems to be broken in beta5, no problems in beta4 so far.

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

Posted: Sat Mar 20, 2021 11:00 am
by pe1chl
Such issues can be caused by incorrect MTU somewhere in the path. E.g. when you have PPPoE to internet and the MTU there is 1492, but on LAN you incorrectly advertise 1500 byte MTU.
It would be nice when RouterOS could copy actual MTU from one interface into advertised MTU of another, but for now you need to do that manually (IPv6->ND).

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

Posted: Sat Mar 20, 2021 11:22 am
by osc86
This is usually not needed, because of path mtu discovery (RFC8201). ICMPv6 just needs to be allowed on all routers between Host A and B.
I still see people blocking icmp for "security reasons"...

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

Posted: Sat Mar 20, 2021 2:07 pm
by pe1chl
Path MTU discovery is inefficient, and indeed it often fails due to overzealous firewall operators.
Explicit MTU setting information is much better.
The AVM routers deployed by my ISP have automatic copy of the WAN MTU to the MTU advertised on LAN by ND.
So when the WAN MTU is 1492 (PPPoE without RFC4638) the LAN advertises MTU 1492 instead of 1500, and everything operates smoothly without a PMTU discovery kick all the time.
Unfortunately MikroTik cannot do that unless you use some script. It should be possible to enter an interface name in the MTU field in an IPv6 ND entry and then it would copy the effective MTU of that interface into the ND announcement. When PPPoE is configured as a WAN, this entry should be set to the PPPoE interface name by default.
That would help a lot of non-expert IPv6 users!

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

Posted: Sat Mar 20, 2021 2:58 pm
by dksoft
Such issues can be caused by incorrect MTU somewhere in the path. E.g. when you have PPPoE to internet and the MTU there is 1492, but on LAN you incorrectly advertise 1500 byte MTU.
It would be nice when RouterOS could copy actual MTU from one interface into advertised MTU of another, but for now you need to do that manually (IPv6->ND).
Can you please explain what might solve the problem?
Here is a RADV dump which looks the same on 6.48.1, b4 and b5.
#
# radvd configuration generated by radvdump 2.18
# based on Router Advertisement from fe80::600:ff:fe00:1
# received by interface eth0
#

interface eth0
{
	AdvSendAdvert on;
	# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
	AdvManagedFlag off;
	AdvOtherConfigFlag on;
	AdvReachableTime 0;
	AdvRetransTimer 0;
	AdvCurHopLimit 0;
	AdvDefaultLifetime 1800;
	AdvHomeAgentFlag off;
	AdvDefaultPreference medium;
	AdvSourceLLAddress on;

	prefix 2003:f4:7710:2e00::/64
	{
		AdvValidLifetime 600;
		AdvPreferredLifetime 300;
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr off;
	}; # End of prefix definition


	prefix fd00::/64
	{
		AdvValidLifetime 600;
		AdvPreferredLifetime 300;
		AdvOnLink on;
		AdvAutonomous on;
		AdvRouterAddr off;
	}; # End of prefix definition

}; # End of interface definition
Works fine on 6.48.1 and 7.1b4. Ugrading the router from 7.1b4 to 7.1b5 brings up the problem that IPv6 does no longer work.
Also I change the MTU on ND to 1492. I can see RADV advertising it, but it does not fix the problem.

Any suggestions what I could try to fix the IPv6 problem reported by other forum members as well?

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

Posted: Sat Mar 20, 2021 3:12 pm
by pe1chl
Maybe this time there is another problem. I recognize the problem reported above ("ping works fine but cannot visit websites") and in my case it was related to upstream MTU.
But that was with v6.xx and not with this beta, my test setup does not have IPv6 at the moment.

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

Posted: Sat Mar 20, 2021 3:14 pm
by Znevna
This is usually not needed, because of path mtu discovery (RFC8201). ICMPv6 just needs to be allowed on all routers between Host A and B.
I still see people blocking icmp for "security reasons"...
People also keep saying what you're saying, without testing.
With MTU 1500 packets leave the interface with a wrong initial MSS. After PMTU kicks in and the correct MTU will be saved in the destination cache, yes, the correct MSS will be used, but for HTTPS this requires hitting a refresh on that website, else it would get stuck.

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

Posted: Sat Mar 20, 2021 3:22 pm
by Znevna
[...]
Works fine on 6.48.1 and 7.1b4. Ugrading the router from 7.1b4 to 7.1b5 brings up the problem that IPv6 does no longer work.
Also I change the MTU on ND to 1492. I can see RADV advertising it, but it does not fix the problem.

Any suggestions what I could try to fix the IPv6 problem reported by other forum members as well?

MTU 1492 is not an universal valid value when using PPPoE, you have to test what your ISP handles properly.

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

Posted: Sat Mar 20, 2021 6:30 pm
by StubArea51
OSPFv3 is still broken in beta5 - getting "wrong checksum" from everything, same as in beta4.

Is there any chance of getting RDNSS search list option added? https://tools.ietf.org/html/rfc8106#section-5.2

What configuration are you using for OSPFv3 ? Whenever I try to add the interface-template, I get a hang on the export similar to the export bug that was just fixed.

[admin@PE-1] > routing/ospf/interface-template/add network=2001:db8:126:1::/126 area=area-0
[admin@PE-1] >
[admin@PE-1] > export
# mar/20/2021 16:26:01 by RouterOS 7.1beta5
# software id =
#
/interface bridge
add name=lo-bgp
add name=lo-ospf
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/routing bgp template
add address-families=ipv6 as=8675309 name=ASN-8675309 router-id=100.127.0.11

!!!! Export hangs here and never completes !!!!!

It happens as soon as I add an entry for routing/ospf/interface-template

it doesn't matter whether I use the prefix or the interface name - have also tried setting a network type of ptp....it all causes export to hang

This is as far as I can get with the config before having issues with OSPFv3:
/interface bridge
add name=lo-bgp
add name=lo-ospf

/routing bgp template
add address-families=ipv6 as=8675309 name=ASN-8675309 router-id=100.127.0.11

/routing ospf instance
add name=IPv6 out-filter-chain=OSPF-permit-only-configured router-id=100.127.0.11 version=3

/routing ospf area
add instance=IPv6 name=area-0

/ipv6 address
add address=2001:db8:126:1::2/126 advertise=no interface=ether1
add address=2001:db8:127::11/128 advertise=no interface=lo-ospf
add address=2001:db8:101::11/128 advertise=no interface=lo-bgp
add address=2001:db8:126:3::2/126 advertise=no interface=ether2
add address=2001:db8:a1a::1 interface=ether4

/routing bgp connection
add local.address=2001:db8:127::11 .role=ibgp-rr-client name=\
    IPv6-peer-to-core remote.address=2001:db8:127::1 .as=8675309 templates=\
    ASN-8675309

/routing filter rule
add chain=OSPF-permit-only-configured rule="action do=accept"
/routing filter select-rule
add chain=OSPF-permit-only-configured_select do-where=\
    OSPF-permit-only-configured

/system identity
set name=PE-1

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

Posted: Sat Mar 20, 2021 6:50 pm
by NeoPhyTex360
Cake reboots seems to be fixed in beta5, will report if any random reboot



Edit: Not fixed. Shitty random reboots with cake still happening. Usable beta in year 2030


RB4011


I guess I made it around the kernel panics as I have uptime of 1d and 4h right now already.

What did I change?

I configured a simple queue with cake since 7.1beta3.
I noticed a property in the cake queue type that I did not set by myself and according to wiki (https://help.mikrotik.com/docs/display/ ... ueues-CAKE) should be empty/0 by default:
cake-memlimit=32.0MiB kind=cake name=cake
I deleted and recreated that queue-type and now the cake-memlimit=0 seems to have positive impact on the device-stability.

EDIT:

kernel panic is back in the game!
router was rebooted without proper shutdown, probably kernel failure
I have same reboot ..
HexS
Simple queue with cake as queue type
With any configuration to this type


تم الإرسال من Redmi Note 8 Pro باستخدام Tapatalk
I now disabled cake simple queue. See if that helps.
Changed to SFQ, no way to work with cake or fq_codel, ramdom reboots with all configs

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

Posted: Sat Mar 20, 2021 11:16 pm
by haedertowfeq
Cake reboots seems to be fixed in beta5, will report if any random reboot



Edit: Not fixed. Shitty random reboots with cake still happening. Usable beta in year 2030


RB4011
I guess I made it around the kernel panics as I have uptime of 1d and 4h right now already.

What did I change?

I configured a simple queue with cake since 7.1beta3.
I noticed a property in the cake queue type that I did not set by myself and according to wiki (https://help.mikrotik.com/docs/display/ ... ueues-CAKE) should be empty/0 by default:
cake-memlimit=32.0MiB kind=cake name=cake
I deleted and recreated that queue-type and now the cake-memlimit=0 seems to have positive impact on the device-stability.

EDIT:

kernel panic is back in the game!
router was rebooted without proper shutdown, probably kernel failure
I have same reboot ..
HexS
Simple queue with cake as queue type
With any configuration to this type


تم الإرسال من Redmi Note 8 Pro باستخدام Tapatalk
I now disabled cake simple queue. See if that helps.
Changed to SFQ, no way to work with cake or fq_codel, ramdom reboots with all configs[/quote]I am using FQ_CoDel
HexS
Is stable wher i but it
Waiting for CAKE to be working later

تم الإرسال من Redmi Note 8 Pro باستخدام Tapatalk


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

Posted: Sun Mar 21, 2021 12:25 am
by pe1chl
Can the cake lovers please stop quoting entire articles in their reply?

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

Posted: Sun Mar 21, 2021 1:35 am
by mducharme
What configuration are you using for OSPFv3 ? Whenever I try to add the interface-template, I get a hang on the export similar to the export bug that was just fixed.
They have changed the syntax again. router-id for OSPF is now expecting the name of one of the ID's in /routing/id instead of an IP address. That might be your issue.

Here is my config:
/routing id
add disabled=no id=172.20.195.129 name=michael select-dynamic-id=""
/routing ospf instance
add name=OSPFv2 router-id=michael
add name=OSPFv3 router-id=michael version=3
/routing ospf area
add instance=OSPFv2 name=backbonev2
add instance=OSPFv3 name=backbonev3
/routing ospf interface-template
add area=backbonev2 network=192.168.88.0/24
add area=backbonev2 network=192.168.89.0/24
add area=backbonev2 network=192.168.201.0/30
add area=backbonev2 network=192.168.201.4/30
add area=backbonev2 network=172.16.50.6/32
add area=backbonev2 network=192.168.77.1/32 type=ptp
add area=backbonev3 interface=moseley type=ptp
add area=backbonev3 interface=tun-to-dad type=ptp
add area=backbonev2 network=192.168.78.1/32 type=ptp
add area=backbonev2 network=192.168.66.0/30 type=ptp

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

Posted: Sun Mar 21, 2021 3:47 am
by SrConfluente
I'm using FQ CODEL in HAP AC2 with no problems. I'll try cake today. My config is as follows:
/queue simple
add max-limit=230M/30M name="anti bufferbloat" queue="fq codel/fq codel" target=ether1 total-queue="fq codel"
I'm using default FQ CODEL queue type and, yes, my upload and download values are flipped but that works for my 230/34 line.

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

Posted: Sun Mar 21, 2021 4:28 am
by SrConfluente
Kernel panic after 20 minutes. Opened a ticket to help fix this issue. In the meantime just use FQ CODEL guys.

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

Posted: Sun Mar 21, 2021 11:09 am
by rpingar
how to convert a very simple bgp out filter rule like this?
add chain=test set-out-nexthop=1.2.3.4

little bit lost about it
thanks
ros

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

Posted: Sun Mar 21, 2021 12:38 pm
by mrz
Option to set gateway will be added in next beta.

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

Posted: Sun Mar 21, 2021 12:47 pm
by rpingar
Option to set gateway will be added in next beta.
thanks,
please push also the fix about x86 winbox ip route crash describe in SUP-37732 (7.1beta3) and still not fixed.

regards
ros

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

Posted: Sun Mar 21, 2021 12:49 pm
by maxpage
Hello,
I've installed on RB411. As below:
[admin@MikroTik] /system/resource> print
                   uptime: 7m39s
                  version: 7.1beta5 (development)
               build-time: Mar/16/2021 14:41:12
              free-memory: 8.6MiB
             total-memory: 32.0MiB
                      cpu: MIPS 24Kc V7.4
                cpu-count: 1
            cpu-frequency: 300MHz
                 cpu-load: 100%
           free-hdd-space: 48.6MiB
          total-hdd-space: 63.8MiB
  write-sect-since-reboot: 64
         write-sect-total: 159641
               bad-blocks: 0%
        architecture-name: mipsbe
               board-name: RB411
                 platform: MikroTik
The first issue:
There is an error in login screen:
RouterBOOT booter 2.20

RouterBoard 411

CPU frequency: 300 MHz
  Memory size:  32 MB

Press any key within 2 seconds to enter setup..
loading kernel from nand... OK
setting up elf image... OK
jumping to kernel code
Starting...
Starting services...
MikroTik 7.1beta5 (development)
MikroTik Login: SCRIPT ERROR: interrupted
The second issue. There are none network interfaces (access via only serial console):
[admin@MikroTik] > /interface ethernet print stats

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

Posted: Sun Mar 21, 2021 1:42 pm
by pe1chl
Did you start with empty config or did you upgrade from an installed v6 or earlier v7?
Probably the script to migrate config failed, try to start fresh without config (netinstall or reset to defaults).
But it could also be there is something that fails on this model of router (not foreseen in the defaults setup?)

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

Posted: Sun Mar 21, 2021 4:19 pm
by StubArea51
[They have changed the syntax again. router-id for OSPF is now expecting the name of one of the ID's in /routing/id instead of an IP address. That might be your issue.

I tried it using the /routing/id syntax and got the same result. Just to see if it was an issue specific to CHR on Qemu in EVE-NG, I tried the exact same syntax on an RB3011 in my lab and got the same result. Export hangs and i can't export any section of the OSPF config after I add anything to /routing/ospf/interface-template

[admin@PE-1] > routing/ospf/interface-template/add area=backbonev3 interface=ether1
[admin@PE-1] > export 
# mar/21/2021 09:14:56 by RouterOS 7.1beta5
# software id = 4UC3-xxxx
#
# model = RouterBOARD 3011UiAS
# serial number = xxxxxxxxxxxx
/interface bridge
add name=lo-bgp
add name=lo-ospf
/interface lte apn
set [ find default=yes ] ip-type=ipv4
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/routing bgp template
set default as=65530 disabled=no name=default output.network=bgp-networks
add address-families=ipv6 as=8675309 name=ASN-8675309 router-id=100.127.0.11
/routing id
add disabled=no id=100.127.0.11 name=rid select-dynamic-id=""

!!! Export hangs here !!!

Here is the config I applied
/interface bridge
add name=lo-bgp
add name=lo-ospf

/routing bgp template
add address-families=ipv6 as=8675309 name=ASN-8675309 router-id=100.127.0.11

/routing id
add disabled=no id=100.127.0.11 name=rid select-dynamic-id=""

/routing ospf instance
add name=IPv6 out-filter-chain=OSPF-permit-only-configured router-id=rid version=3

/routing ospf area
add instance=IPv6 name=backbonev3

/ipv6 address
add address=2001:db8:126:1::2/126 advertise=no interface=ether1
add address=2001:db8:127::11/128 advertise=no interface=lo-ospf
add address=2001:db8:101::11/128 advertise=no interface=lo-bgp
add address=2001:db8:126:3::2/126 advertise=no interface=ether2
add address=2001:db8:a1a::1 interface=ether4

/routing bgp connection
add local.address=2001:db8:127::11 .role=ibgp-rr-client name=\
    IPv6-peer-to-core remote.address=2001:db8:127::1 .as=8675309 templates=\
    ASN-8675309

/routing filter rule
add chain=OSPF-permit-only-configured rule="action do=accept"
/routing filter select-rule
add chain=OSPF-permit-only-configured_select do-where=\
    OSPF-permit-only-configured

/system identity
set name=PE-1

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

Posted: Sun Mar 21, 2021 5:22 pm
by infabo
Kernel panic after 20 minutes. Opened a ticket to help fix this issue. In the meantime just use FQ CODEL guys.
Yep, with disabled cake queue I now reached 2d uptime. Wow, did not see this in month.

It isnt that I havent already created a support ticket. Already over a month ago. Provided like 14 supouts and a config export. And now some guy appears in the forum and can confirm the issue with cake on another device within 20mins. Awesome in some way.

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

Posted: Sun Mar 21, 2021 7:20 pm
by YO3HDU
Hi,

So far I had success with policy routing, bgp, lte.

The only issue I have is that for the life of me I cannot figure out how to setup bgp outbound rules.

Specificly I am unable to set a community with out rules.

Can a kind soul help me out with the propper sintax for this ?

I looked over the manual for ROS 7, however I can't get it to work.

Thanks

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

Posted: Sun Mar 21, 2021 9:17 pm
by doneware
Hello,
I've installed on RB411. As below:
the 411 has only 32M RAM. i see the output shows still 8MB is free, but also shows 100% CPU load. this doesn't look healthy.
i'd suggest to look at the M11G instead - roughly the same interfaces, same price range, but way more powerful cpu and 256M ram.

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

Posted: Sun Mar 21, 2021 10:06 pm
by mducharme
I tried it using the /routing/id syntax and got the same result. Just to see if it was an issue specific to CHR on Qemu in EVE-NG, I tried the exact same syntax on an RB3011 in my lab and got the same result. Export hangs and i can't export any section of the OSPF config after I add anything to /routing/ospf/interface-template
I tried putting most of your config into my hap ac at home (except a few of the interfaces that would conflict with mine) and I am able to export, so I'm not sure what is going on. I tried installing EVE-NG and imported the CHR image so that I could test in the same sort of environment you are, but the CHR doesn't want to boot - I start it and it stops right away.

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

Posted: Sun Mar 21, 2021 10:48 pm
by maxpage
Hello,
I've installed on RB411. As below:
the 411 has only 32M RAM. i see the output shows still 8MB is free, but also shows 100% CPU load. this doesn't look healthy.
i'd suggest to look at the M11G instead - roughly the same interfaces, same price range, but way more powerful cpu and 256M ram.
Thank you for your reply. I'ts high time to replace firmware.
BTW it's a good idea to make list compatible devices with ROS7

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

Posted: Mon Mar 22, 2021 12:54 am
by doneware
Thank you for your reply. I'ts high time to replace firmware.
BTW it's a good idea to make list compatible devices with ROS7
knot is a new box, and its IoT package depends on 7.1b5.
the device itself has the same CPU (QCA9531) as many 'relatively recent' mips-be routers, like the ltAP mini.
i just tested it, seems to be just fine.
[me@ltap5] > /sys reso print 
                   uptime: 3h2m47s
                  version: 7.1beta5 (development)
               build-time: Mar/16/2021 14:41:12
         factory-software: 6.42
              free-memory: 22.4MiB
             total-memory: 64.0MiB
                      cpu: MIPS 24Kc V7.4
                cpu-count: 1
            cpu-frequency: 650MHz
                 cpu-load: 2%
           free-hdd-space: 2220.0KiB
          total-hdd-space: 16.0MiB
  write-sect-since-reboot: 1344
         write-sect-total: 32484
               bad-blocks: 0%
        architecture-name: mipsbe
               board-name: LtAP mini
                 platform: MikroTik
as you see, i have just a single extra package installed, but the flash is quite full.
                
[me@ltap5] > /file/print 
Columns: NAME, TYPE, SIZE, CREATION-TIME
  #  NAME                                  TYPE       SIZE     CREATION-TIME       
  0  flash                                 disk                jan/01/1970 01:00:05
  1  flash/skins                           directory           jan/01/1970 01:00:05
  2  flash/ltap5-20200424-1251.backup      backup     36.6KiB  apr/24/2020 11:51:32
  3  flash/config_20200425.backup          backup     36.6KiB  apr/24/2020 11:54:32
  4  flash/lte_router_config_20200425.rsc  script     5.0KiB   apr/24/2020 11:54:39
  5  flash/pub                             directory           oct/10/2018 19:47:48
[me@ltap5] > /sys package/print 
Columns: NAME, VERSION
  #  NAME      VERSION 
  0  lte       7.1beta5
  1  routeros  7.1beta5

the same specs apply to hex poe lite, hap ac lite. so i assume these would be also fine. will test a hap ac lite soon. i wouldn't think that QCA9533 based boards would be any different.
as the base rule of thumb i'd say: 64M RAM and a ~600MHz cpu.
mmips boards (hex, m11g, m33g) have a lot of RAM, and quite beefy cpu, so they're cool. albeit i just tested 7.1b5 on two m33g boards, upgrade went smoothly - but upon restarting them after routerboot upgrade, both ended up stuck during boot and i had to power cycle them. so far i don't have many CCRs lying around to play sw upgrade/downgrade

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

Posted: Mon Mar 22, 2021 1:02 am
by mducharme
Beta5 doesn't work on my hAP mini - after upgrading the router won't boot. Had to netinstall back to beta4 (netinstall for beta5 did not work, the device would not appear). It works fine on my other devices (mipsbe and arm based).

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

Posted: Mon Mar 22, 2021 8:24 am
by gumilev
I use mikrotik chateau 12, updated from 7.1beta4 to 7.1beta5, then added several rules to the firewall, rebooted - the router was reset to factory settings, and the wifi points were disabled. Restored, changed the firewall again, rebooted - reset to factory settings again. I set everything up again, I do not climb into the firewall, I reboot 5 times to check - everything is fine, it is not reset. I disconnect it from the network and carry it under the roof of the house where he lives. I turn it on - and it reset to factory settings again 🤬 What should I do to fix this?

Оригинальный текст:
Использую mikrotik chateau 12, обновился с 7.1beta4 на 7.1beta5, после чего добавил несколько правил в фаервол, перезагрузил - роутер самостоятельно сбросился на заводские настройки, причем wifi точки отключены. Восстановил, снова меняю фаервол, перезагружаю - опять сам сбросился на заводские настройки. Снова все настраиваю, не лезу в фаервол, для проверки перезагружаю 5 раз - все впорядке, не сбрасывается. Отключаю от сети и несу роутер под крышу дома, где он живет. Включаю - а он снова сбросился на заводские настройки 🤬 Что делать что бы исправить это?

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

Posted: Mon Mar 22, 2021 9:12 am
by doneware
Does anyone know what you can send trough MQTT yet?

Can we send e.g. interface up / interface down and publish it to an mqtt server? If so, how to do that?

I see you can add an mqtt broker, and do something in the publish screen...? But what...?

Maybe you can lateron choose the logging to set via mqtt?? Anyone played with it already?
So far MQTT is like tool sms or tool email.
You can call it from scripts. The syntax is as follows:
/iot mqtt publish broker=name_of_the_broker topic=topic message=your_string_or_variable
Multiple brokers can be defined under
/tool iot mqtt broker
, it has also selectable ssl support with Cerificate validation. The client supports user/pass and client cert auth as well.
With regards to using it as log destination, I haven’t tried it but I doubt this is possible now.
Also, subscription to topics is not supported.

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

Posted: Mon Mar 22, 2021 11:54 am
by icedogm
lte interface says that there is newer firmware available but the latest already installed
/interface lte
# A newer version of modem firmware is available!
set [ find ] allow-roaming=no name=lte1 network-mode=lte
/interface lte apn
set [ find default=yes ] ip-type=ipv4

[admin@tiskre] /interface/lte> firmware-upgrade number=0
  installed: R11e-LTE6_V027
     latest: R11e-LTE6_V027
[admin@tiskre] /interface/lte>

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

Posted: Mon Mar 22, 2021 11:58 am
by eworm
This command always shows two versions. If these two match you are up to date.

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

Posted: Mon Mar 22, 2021 12:40 pm
by doneware
This command always shows two versions. If these two match you are up to date.
i guess the complaint was about the message in red. that one shouldn't be there. i mean, those lines above are from the output of export command.

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

Posted: Mon Mar 22, 2021 12:54 pm
by eworm
Ah, did not even notice that line. 🤪
So ignore my answer...

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

Posted: Mon Mar 22, 2021 8:07 pm
by timnis
!) added new "iot" package with initial Bluetooth (KNOT only) and MQTT publisher support;
It says only publisher, but will there be subscriber support also? Possible to control gpio output/relay?

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

Posted: Mon Mar 22, 2021 8:39 pm
by syadnom
Any idea when the Wave2 package will support DFS channels or WDS? I have a few Audience units here I'd love to play with WDS meshing on these.

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

Posted: Mon Mar 22, 2021 11:20 pm
by doneware
!) added new "iot" package with initial Bluetooth (KNOT only) and MQTT publisher support;
It says only publisher, but will there be subscriber support also? Possible to control gpio output/relay?
i already opened a support request about this (subscriber support) - or better put, i updated my old one - and Mikrotik Guys said they will consider it.
i first opened the request back in september last year, and the MQTT client was already being worked on. initially it was planned to be also available in v6, which would be kinda good. and in general, this is still totally possible.

back in may 2019 i created a poll about routerOS MQTT support: viewtopic.php?f=9&t=148558
the syntax i envisioned turned out to be quite similar. i imagined subscriber functionality linked to routerOS scripts with context-linked variables, just like the lease scripts with DHCP.

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

Posted: Tue Mar 23, 2021 3:10 am
by rooted
Anyone have any wave2 performance numbers between the releases? I was just wondering if the performance is gaining or staying relatively the same.

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

Posted: Tue Mar 23, 2021 6:12 am
by nannou9
Anyone have any wave2 performance numbers between the releases? I was just wondering if the performance is gaining or staying relatively the same.
It is not getting any better on audience. On beta 5 I am getting max 550mb with iperf3. I was actually getting ~620 spikes on beta 4 which I cannot reproduce anymore.
Tested on 3chain MacBook Pro. Was testing using 4 chain radio.

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

Posted: Tue Mar 23, 2021 1:16 pm
by b0n3v
For the first time on betas released RB3011 doesn't have kernel panic :) I always use same config, btw - Installed via net install.
Image

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

Posted: Tue Mar 23, 2021 5:48 pm
by mafiosa
OSPFv3 is still broken in beta5 - getting "wrong checksum" from everything, same as in beta4.
Yes as soon as I add interface for ospfv3 the other routers stop receiving routes (6..48.1). The router keeps receiving ipv4 routes from other routers but ospfv2 stops sending out routes but not receiving.

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

Posted: Tue Mar 23, 2021 6:20 pm
by mfrey
Could it be that running VLAN Interfaces on top of a bridge is currently broken? I've got my new hAP ac3 today and directly installed beta5 because of its features.

I created a bridge over all except one Ethernet port and created a few VLAN interfaces on top of that bridge (no VLAN filtering enabled).
I could see incoming traffic, but outgoing traffic (e.g. DHCP and ICMP) did not reach clients. After replacing the bridge for a Ethernet port,
everything worked as expected.

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

Posted: Tue Mar 23, 2021 7:11 pm
by infabo
Now having reached 4d uptime I can definitely say: cake simple queue caused the kernel panics. system (Chateau12) working stable with fq_codel right now.

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

Posted: Tue Mar 23, 2021 9:44 pm
by mikrotikedoff
@infabo

Thats why we told you to post your export. The community would immediately have been able to comment on cake being a brand new and not yet successfully implemented feature. I'm surprised you never tried reducing the complexity of your configurations to try and resolve the kernal panics before considering the length of time you were experiencing issues. Just a heads up its not uncommon for updates to break the ability to successfully reapply a /export. If you find yourself with a broken router after an update blow out all your configurations and reapply them one line at a time. A lot of times something changed with how a setting functions/is presented/is configured and needs to be redone to work with the new way of doing things.

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

Posted: Tue Mar 23, 2021 9:46 pm
by Easen
Device: RB750Gr3
Revsion: r4
Action: Upgrade from 7.1beta4 --> 7.1beta5


I tried to upgrade form the packages section and it bricked my hEX, it would boot but none of my devices were getting an IP address. I had todo a hard reset & connect to it via MAC Winbox. Once connected I ran the "Upgrade" in the RouterBOARD section and the restored from my previous backup.
This was my first time upgrading from a beta version to another beta version. Is this to be expected? If not, what did I do wrong?

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

Posted: Tue Mar 23, 2021 10:22 pm
by doneware
Anyone have any wave2 performance numbers between the releases? I was just wondering if the performance is gaining or staying relatively the same.
It is not getting any better on audience. On beta 5 I am getting max 550mb with iperf3. I was actually getting ~620 spikes on beta 4 which I cannot reproduce anymore.
Tested on 3chain MacBook Pro. Was testing using 4 chain radio.
wave2 is limited on CPU side on audience. just check your per-core usage, and you'll see that a single core will run on 100%, while the others idle between 0-10% while you run your test.
basically all network traffic from a single device is handled by a single core. with 7.1b4 i measured up to 650Mbps with iperf3 on an iPhone 12 pro (2x2 ax) and 550mbps with an iMac (3x3 ac)
will retest it today with 7.1b5

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

Posted: Wed Mar 24, 2021 1:20 am
by rooted
Thanks for the numbers.

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

Posted: Wed Mar 24, 2021 2:26 am
by doneware
Thanks for the numbers.
just finished the testing, but only with the iPhone.

test setup:

iMac (running iperf3 server) - CRS125 (switching) - audience (4x4 wifi enabled, 7.1b5) - iPhone 12 pro (iOS 14.5b4)
crowley:~ me$ iperf3 -v
iperf 3.9 (cJSON 1.7.13)
Darwin crowley.local 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:07:06 PST 2021; root:xnu-7195.81.3~1/RELEASE_X86_64 x86_64
Optional features available: sendfile / zerocopy, authentication
i tested both upload and download with 5 streams each time. the iPhone was running "perf 3 wifi speed test" v3.6.11. https://apps.apple.com/hu/app/iperf-3-w ... 1462260546

iperf3 server download results:
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-30.01  sec   339 MBytes  94.7 Mbits/sec                  sender
[  8]   0.00-30.01  sec   530 MBytes   148 Mbits/sec                  sender
[ 10]   0.00-30.01  sec   399 MBytes   112 Mbits/sec                  sender
[ 12]   0.00-30.01  sec   499 MBytes   140 Mbits/sec                  sender
[ 14]   0.00-30.01  sec   388 MBytes   108 Mbits/sec                  sender
[SUM]   0.00-30.01  sec  2.10 GBytes   602 Mbits/sec                  sender
cpu monitor on audience while download test:
[me@audience] > /system/resource/monitor 
          cpu-used: 58%
  cpu-used-per-cpu: 96%,91%,46%,1%
       free-memory: 126724KiB
-- [Q quit|D dump|C-z pause]

upload figures:
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-30.01  sec   456 MBytes   127 Mbits/sec                  receiver
[  8]   0.00-30.01  sec   429 MBytes   120 Mbits/sec                  receiver
[ 10]   0.00-30.01  sec   228 MBytes  63.8 Mbits/sec                  receiver
[ 12]   0.00-30.01  sec   471 MBytes   132 Mbits/sec                  receiver
[ 14]   0.00-30.01  sec   391 MBytes   109 Mbits/sec                  receiver
[SUM]   0.00-30.01  sec  1.93 GBytes   552 Mbits/sec                  receiver

cpu measurement while testing upload:
[bat@audience] > /system/resource/monitor 
          cpu-used: 29%
  cpu-used-per-cpu: 10%,8%,100%,1%
       free-memory: 126088KiB
-- [Q quit|D dump|C-z pause]

something is changed, now I see 2 cores running at 100% while downloading, with 7.1b4 it was just a single core, just as i observer now with upload testing.
the results for me are on par with the ones from 7.1b4. to be honest i did not repeat the tests. i will do a longer one with another 3x3 ac client later.
upload.PNG
download.PNG

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

Posted: Wed Mar 24, 2021 10:57 am
by mikegleasonjr
@infabo

The community would immediately have been able to comment on cake being a brand new and not yet successfully implemented feature.

I think CODEL has been implemented and came out exactly at the same time as CAKE. They both appeared in 7.1beta3. So I don't think someone could have known that CAKE wasn't ready but CODEL was.

At least I can't. Do you have other information that we overlooked?

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

Posted: Wed Mar 24, 2021 2:23 pm
by mfrey
I can confirm the IPv6 issues others had on my hap ac3 too. In my case it looks like the connection state is not properly detected by the firewall (or the rules in Winbox are not properly applied to the kernel), because my "Allow forward established" rule does not match the traffic it is supposed to. The established traffic is then dropped by the "drop all" rule at the end.

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

Posted: Wed Mar 24, 2021 4:05 pm
by Pudel
7.1 beta5
OpenVPN Server
Configuration: by TCP

Server with OpenVPN can accept one client and actively refused any other connections from other host. In logs I dont have anything.
Ovpn client on another PC have in logs "connection refused"

On 7.1 beta4 this problem not occur.

Any idea whats wrong? :)

UPDATE:

PPP utilize one core by 100% on RB750Gr3

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

Posted: Wed Mar 24, 2021 5:28 pm
by infabo
@infabo

The community would immediately have been able to comment on cake being a brand new and not yet successfully implemented feature.

I think CODEL has been implemented and came out exactly at the same time as CAKE. They both appeared in 7.1beta3. So I don't think someone could have known that CAKE wasn't ready but CODEL was.

At least I can't. Do you have other information that we overlooked?
I can't remember exactly, but I guess I first configured cake in beta4 first time. But since I had been suffering devices-freezes or wifi-disconnects in betas before, I did not see any relation to the cake queue.

Since the kernel panic in some cases happend as late as 1day uptime, I would have ended up in year 2022 until I finally may found the issue by replaying my config-export line by line....

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

Posted: Wed Mar 24, 2021 6:05 pm
by mikrotikedoff
I don't have any special information I just would have, upon seeing CAKE in the configurations and recognizing it as newish beta feature, suggested to try removing it and observing the results. Especially upon the revelation that ISPs are already offering this product to users, which I did not know I assumed ISPs were still just labing with them at this point, had me confident that surely some configuration was possible with these that could have some reasonable level of stability.

Infabo please update your most recent ticket if you haven't already so they look deeper into the relation of CAKE to your kernal panics.

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

Posted: Wed Mar 24, 2021 6:46 pm
by infabo
I already updated my support-ticket and confirmed they can reproduce the issue and it will be fixed in the next betas.
I don't have any special information I just would have, upon seeing CAKE in the configurations and recognizing it as newish beta feature, suggested to try removing it and observing the results
Since I started with this device in 7.1beta2, the device was instable from beginning. So regarding "newish features" - the whole v7 is a "beta feature" itself from my point of view. I never experienced something like "stable" or "long uptime without issues". This is something new for me. Basically, yes - in this case the community may have pointed me torwards cake if I posted my config somewhere. It's a blackbox in the end.

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

Posted: Thu Mar 25, 2021 6:10 am
by rooted
@doneware Excellent, it's comparable to my current 3x3 AP which is definite progress as wireless has always been a weakness for these devices. Perhaps in the not to distant future I can replace what I'm using and be all mikrotik.

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

Posted: Thu Mar 25, 2021 2:05 pm
by Chupaka
Is it only me who can't find how to change OSPF Interface Cost in beta4/beta5?..

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

Posted: Thu Mar 25, 2021 3:29 pm
by mrz
We will add cost back in next beta.

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

Posted: Thu Mar 25, 2021 5:43 pm
by pe1chl
@mrz
Do you know if there is any work done or planned to be done to enable transfer of path quality parameters from e.g. a WiFi link into a routing protocol?
(or even to develop a new routing protocol that is able to handle auto routing in a network consisting of a partial mesh of WiFi links which have limited and varying quality)
All the standard routing protocols assume that a link is either perfect or down, which often is not true for WiFi links. You may want to avoid routing over WiFi links that are not always operating 100%, but keep them available as a backup path when something else fails.
It seems that this is closely related to the core business of MikroTik.

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

Posted: Thu Mar 25, 2021 9:37 pm
by infabo
What to do, when my Chateau12 hangs up / freezes after 5d of uptime without problems? What can I report to support? No unusual usage, suddenly wifi disconnects. No connection via cable either. LEDs still blinking on the device. Had to power-cycle the device. This leaves me clueless.

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

Posted: Thu Mar 25, 2021 10:17 pm
by nannou9
What to do, when my Chateau12 hangs up / freezes after 5d of uptime without problems? What can I report to support? No unusual usage, suddenly wifi disconnects. No connection via cable either. LEDs still blinking on the device. Had to power-cycle the device. This leaves me clueless.
Consider using watchdog to do restarts for you.
You can add ip address to ping in watchdog also.
I was using it with beta4. Beta5 however is perfectly stable for me on audience so far. No reboots nor single wifi problem.

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

Posted: Thu Mar 25, 2021 11:58 pm
by doneware
Do you know if there is any work done or planned to be done to enable transfer of path quality parameters from e.g. a WiFi link into a routing protocol?
(or even to develop a new routing protocol that is able to handle auto routing in a network consisting of a partial mesh of WiFi links which have limited and varying quality)
i worked with openR running in terragraph mesh, and they supported 'metrics' based on MCS and link quality.
long story short, to build a stable routing protocol, one must find the balance between reacting to changes and introducing constant convergence in the network. so their approach was gentle enough, but don't think of something overly complicated. the key was to find the pace how changes in link quality and capacity should be propagated to the network.

some years ago we had some discussions about getting openR support into routerOS - albeit nothing was committed, that might still come later.

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

Posted: Fri Mar 26, 2021 12:14 am
by syadnom

i worked with openR running in terragraph mesh, and they supported 'metrics' based on MCS and link quality.
long story short, to build a stable routing protocol, one must find the balance between reacting to changes and introducing constant convergence in the network. so their approach was gentle enough, but don't think of something overly complicated. the key was to find the pace how changes in link quality and capacity should be propagated to the network.
I've also beet working with terragraph. It uses a central controller (E2E) to adjust metrics but the basics are that a pessimistic sliding window of MCS values and availability metrics are used to set metrics. In terragraph that's per DN, so a DN one hop down might have a completely different set of metrics in order to change the routing behavior. A full MCS12 modulation on a terragraph link might have a great metric for the directly connected DN, but if that link is saturated then the next hops might end up showing a worse metric. In short, it's really setting the metric based on hop count (lower priority that OSPF), latency, and available capacity (Which is derived from MCSs values) on a sliding window to keep from ocilating.

it's very slick for sure. primary benefits are the ~50ms failover times and the ability to route for load balancing from the PoP.

As a tangent, I think OpenR is very complex due to all the moving parts and though it seems well put together, it's more than I need. I would much rather see SRv6 implemented and ISIS w/ MCS & throughput metric modification. I think that a layer3 backbone w/ ISIS (or OSPFv3...) and SRv6 does what a service provider probably wants w/o the reliance on an E2E or facebook tech etc. Could also be done with vxlan/eoip6/etc+OSPFv3+BGP using hybrid mesh w/ route reflectors on each ingress to your core. OSPFv3 builds the fabric, BGP+BFD handles rapid rerouting (in the ms, not seconds), and then the dmarc port can be bridged to vxlan, eoip6, etc back to your core. Seamless layer2 network for your field techs, traditional routed layer3 for your engineering staff with really no surprises. Only thing missing is vxlan over udp. You can do everything else in routeros6 today. Missing component is the >1Gbps 60Ghz links.

Man I got off topic. The point is that pulling link quality off interfaces and using them to influence route metrics would be really really welcome. figure out if it's wired and full duplex or wireless full or half duplex, MCS rate, retry rate, remaining capacty, etc.

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

Posted: Fri Mar 26, 2021 12:45 am
by fbl
I'm having issues adding a simple output filter chain + selection rule.

When trying even a simple configuration as follows, RouterOS marks the selection-rule invalid:
/routing bgp template
add address-families=ip as=1234 input.filter=testrule name=test output.filter=test
/routing filter rule
add chain=testrule rule="action accept;"
/routing filter select-rule
add chain=test do-where=testrule
which results in:
[admin@test] > routing/filter/select-rule/print 
Flags: X - disabled, I - invalid 
 0 I chain=test do-where=testrule 

[admin@test] > routing/filter/select-chain/print 
Flags: I - inactive; D - dynamic 
 0 ID ;;; chain has invalid rules
      name="test" 

[admin@test] > routing/filter/chain/print 
Flags: I - inactive; D - dynamic 
 0 ID ;;; chain is empty
      name="" 

 1  D name="testrule" 
The empty filter rule chain with
name=""
only appears if the selection-rule is added.

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

Posted: Fri Mar 26, 2021 1:02 am
by doneware
As a tangent, I think OpenR is very complex due to all the moving parts and though it seems well put together, it's more than I need. I would much rather see SRv6 implemented and ISIS w/ MCS & throughput metric modification. I think that a layer3 backbone w/ ISIS (or OSPFv3...) and SRv6 does what a service provider probably wants w/o the reliance on an E2E or facebook tech etc. Could also be done with vxlan/eoip6/etc+OSPFv3+BGP using hybrid mesh w/ route reflectors on each ingress to your core. OSPFv3 builds the fabric, BGP+BFD handles rapid rerouting (in the ms, not seconds), and then the dmarc port can be bridged to vxlan, eoip6, etc back to your core. Seamless layer2 network for your field techs, traditional routed layer3 for your engineering staff with really no surprises. Only thing missing is vxlan over udp. You can do everything else in routeros6 today. Missing component is the >1Gbps 60Ghz links.
in general current routerOS devices can deliver over 1Gbps on the 60gig links even with MCS8. i measured with bwtest between two wap60Gs and it did actually reach about 1.1Gbps unidirectional throughput, but it had to stay "inside" as you can't get it out through the 1Gig interface. i also did bidirectional testing - this time it was actually forwarding over the gigE ports, and i was able to reach ~1.9Gbps aggregated throughput. again, running routers 6.46.

i also built an ipv6 only mesh network with ~200 nodes - from wap60Gs and Gx3s, the routing protocol was OSPFv3 and i dynamically built EoIPv6 tunnels to carry the customer "PPPoE broadband traffic and IPv4 multicast" over the 60Gig mesh, where each wAP60G was a router.
routerOS7 supports vxlan, but it's still done in CPU, and therefore has no real advantage. in addition it only works on IPv4 underlay, which is quite annoying.
i might not resonate with the SRv6 story, as I tend to look at networks as simple as possible, but definitely vouch for OTT service delivery instead of MPLS and all those early 2000s stuff. i'd love routeros7 to take full advantage of the marvell SoCs, giving us hw assisted vxlan support, and maybe also PTP support for wireless synchronisation. plus i want to have the major tunnelling solutions to be v6 ready.

getting the device up and running in IPv6 only environment is no joke, most mechanisms just don't work - for example boxes can't generate unique router IDs. so there are a lot of things to fix. i opened service requests for these missing bits and pieces, but these things are still a minority compared to the mainstream.
the RA/DHCPv6 interaction with lease times is still buggy, but routerOS does remarkably well with IPv6, compared to the others in its league.
so there's still hope, and v6 is a beast when unleashed - it can solve so many issues with traditional networking, it can make session management as it is now totally obsolete... we just see the tip of the iceberg, really.

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

Posted: Fri Mar 26, 2021 1:51 am
by nz_monkey
I hope that adding a RADIUS VSA to set the VRF for a PPPoE connection is still on the roadmap...

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

Posted: Fri Mar 26, 2021 2:21 am
by syadnom
getting the device up and running in IPv6 only environment is no joke, most mechanisms just don't work - for example boxes can't generate unique router IDs. so there are a lot of things to fix. i opened service requests for these missing bits and pieces, but these things are still a minority compared to the mainstream.
the RA/DHCPv6 interaction with lease times is still buggy, but routerOS does remarkably well with IPv6, compared to the others in its league.
so there's still hope, and v6 is a beast when unleashed - it can solve so many issues with traditional networking, it can make session management as it is now totally obsolete... we just see the tip of the iceberg, really.
SRv6 should be very simple to implement. Just as easy as building an EoIP tunnel, except you can more easily describe the path you'd prefer it to take (optional) and if you want a central controller to monitor each link on the network and adjust SRv6 paths (again, optional). Basically, it's as easy as an EoIP tunnel but has a bunch of extras if you want to use them. It also has a very simple header format so it's pretty straight forward to hardware accelerate encapsulation, and since it's 'plain' IPv6 after encapsulation it's much easier to implement on a network than layer2 vxlan or standard vlan, mpls, etc.

For me it's only minorly annoying that routeros doesn't auto generate routable ipv6 addresses etc. OSPFv3 works like a champ on the local addresses and building an EoIP6 tunnel is cake.

What did you mean by "Dynamically build EOIP". Am I over-reading this? Are you just manually creating an EoIP6 tunnel and bridging the LAN port in so you can transport PPPoE? I'm considering something similar but with radius backed DHCP instead of PPPoE.

I'm working on a new deployment and kind of on the fence if I should do cambium's terragraph or an IPv6 mesh design. I've used ignitenet's terragraph in beta and wasn't impressed. With tik and an IPv6 underlay and EoIP6 on top, I get a LOT of what I want.

IPv6 underlay on the link local addresses with a routable private address on a loopback for OSPFv3. BGP RR on each 1st HOP off the main fiber, full mesh for those. Each site with 2 peers, a primary path and a secondary path to the RR peers. BFD on the peers to get me really fast failover. My big hold-up is that roof access at the fiber pop is really expensive so having a single cambium v5k is a substantial 'single radio' backhaul to the next rooftops, but then comes with the rest of the terragraph kit, while nothing in ubiquiti or mikrotik's 60Ghz arsenal will get me over 1G. Heck, none of them even have dual 1G ethernet ports so I can't even LACP them. Ignitenet has 2.5G gear so that's an option but I don't really like their gear much. Even considering cambium for the first hop off the building to keep at 1 radio and then switch over to mikrotik for the rest. This is a metro deployment building-to-building and everything is an MDU. I should also add that ubiquiti's gigabeam gear can't do a jumbo MTU at this point so for them, only their AF60(&LR) is all that interesting. Mikrotik gives you fat frames so that would be the bread and butter of an 'ad based network. At least I could use up 4 channels on an 8 radio ptp 'set' and get 4Gbps one-way via ECMP. Look pretty ugly though. And now UI has dropped the bomb that they have 60Ghz PtMP in alpha and plan to reveal it in April. Hope Mikrotik has something really soon. I hope they aren't waiting for routeros7 to launch since it's still pretty unpolished.

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

Posted: Fri Mar 26, 2021 10:49 am
by doneware
For me it's only minorly annoying that routeros doesn't auto generate routable ipv6 addresses etc. OSPFv3 works like a champ on the local addresses and building an EoIP6 tunnel is cake.
hold up. i'm not talking about using LL addresses with OSPFv3. that works fine.
but you need to have unique OSPF routerIDs, so 32 bit integers. those are displayed in routerOS as IPv4 addresses.
now usually, if you have *any* ipv4 address configured anywhere, this value can be automatically chosen, unless you decide to configure it manually.
but with IPv6 addresses only, routerOS can't pick a random 32 bit number from the available list of IPv4 addresses, as there are none.
same goes with BGP routerID.

we had these issues in our terragraph pilot with facebook 3 years ago, and ultimately i decided to put together a small routerOS script that does the trick based on the serial number.
the goal was to have a ZTP environment with 0 manual configuration. having LL support in IGPs is great, as you can truly build a self organising network.

and you will need ULA or GUA to build an EoIPv6 tunnel to an indirectly connected device.

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

Posted: Sat Mar 27, 2021 5:08 am
by syadnom
True. If your goal is truly zero touch, then you need some method to get these 'legacy' IP addresses in there. Be nice to have mikrotik have the ability to automatically generate that and the local IPv6 addresses. A lot of pieces are missing there so basically relying on initialization scripts unless mikrotik presents a *complete* software stack that suits your particular needs. Along those lines you'd need to automatically build your EOIP6 tunnels to your core, which need tunnel ids limited to 999 etc. I'd say L2TP for simplicity but mikrotik doesn't have an L2TP6 interface option. VxLAN over UDP would be great but that's gotta wait til routeros7 *and* like someone said before, is only hardware accelleratable on certain platforms.

What's keeping cambium's cnwave product on the table for me is that I can get GRETAP/L2GRE tunnels auto-built on the DN/CN from the controller and there is just *one* device on the building. Everything else can be handled by Radius/DHCP or PPPoE etc. They even allow for a 3rd party GRETAP concentrator so you can host a linux box and build those interfaces by hitting their API for a list of DN/CNs that are configured for a L2GRE tunnel. That's just one piece of equipment on the roof, no CPE router or other gear etc is really interesting and it's all zero touch. A nice managed switch as the dmarc and it's a very simple setup.

With tik, we can do this with scripts and bridge EOIP6 tunnels to the LAN port and get all this done with a light touch, but it's definitely a multi-device solution right now with existing 'ad gear and requires switching to handle those multiple devices and something to handle encapsulation and likely a third device for customer facing ports. A much more complex system and really isn't going to beat the cnwave price because of all the discreet parts and labor etc.

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

Posted: Sun Mar 28, 2021 2:31 pm
by NAB
Upgrading an x86 beta4 VM under ESX, I got...
Capture.PNG

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

Posted: Sun Mar 28, 2021 3:04 pm
by NAB
New install from x86 ISO under ESX. Drive detected and system package installed - on reboot there's just a flashing cursor top left and nothing else happens.

It's fair to say that beta5 is well and truly borked. More annoying is that I hadn't been backing up the 7betaX machines as they were just there for testing. Now I realise I've lost a licence and am kicking myself :-(

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

Posted: Sun Mar 28, 2021 3:17 pm
by raffav
New install from x86 ISO under ESX. Drive detected and system package installed - on reboot there's just a flashing cursor top left and nothing else happens.

It's fair to say that beta5 is well and truly borked. More annoying is that I hadn't been backing up the 7betaX machines as they were just there for testing. Now I realise I've lost a licence and am kicking myself :-(
You are using the x86 (iso version) on a hypervisor ? Or you are using CHR version?
The chr version you can easily transfer the license...
In the iso version... You can still recovery if you didn't delete the virtual HD... You can netinstall and format from there..


Sent from my Moto Z3 Play using Tapatalk


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

Posted: Sun Mar 28, 2021 4:01 pm
by NAB
In the iso version... You can still recovery if you didn't delete the virtual HD...
HD's gone! Managed to delete it when I meant to take a copy of it. It's all going wrong today!

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

Posted: Sun Mar 28, 2021 4:10 pm
by raffav
Use the chr version is better optimize for virtualization and you can transfer license

Sent from my Moto Z3 Play using Tapatalk


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

Posted: Sun Mar 28, 2021 4:15 pm
by NAB
Use the chr version is better optimize for virtualization and you can transfer license
Indeed. This was a machine I brought up years ago to do various testing with when I had plenty of normal spare licences.

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

Posted: Sun Mar 28, 2021 4:29 pm
by raffav
Use the chr version is better optimize for virtualization and you can transfer license
Indeed. This was a machine I brought up years ago to do various testing with when I had plenty of normal spare licences.
Try to see support can help you with that


Sent from my Moto Z3 Play using Tapatalk


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

Posted: Sun Mar 28, 2021 4:55 pm
by StubArea51
@mrz
Do you know if there is any work done or planned to be done to enable transfer of path quality parameters from e.g. a WiFi link into a routing protocol?
(or even to develop a new routing protocol that is able to handle auto routing in a network consisting of a partial mesh of WiFi links which have limited and varying quality)
All the standard routing protocols assume that a link is either perfect or down, which often is not true for WiFi links. You may want to avoid routing over WiFi links that are not always operating 100%, but keep them available as a backup path when something else fails.
It seems that this is closely related to the core business of MikroTik.
There is already a protocol for this:


Babel - which is used on a number of wireless networks through various Linux routing engines like FRR. But if I had to choose, i'd want SR-MPLS + IS-IS

https://en.wikipedia.org/wiki/Babel_(protocol)

Segment routing would also be helpful here as you could use a PCEP to analyze the network and implement policy when RF links are having issues with link quality or capacity.

I started a thread a while back to push for support of SR-MPLS with IS-IS as I believe it's one of the best additions that MIkroTik could make to the routing stack. SRv6 is great but does have some limitations and I think it would be wise to let that protocol mature a little more before implementation.

viewtopic.php?f=1&t=171278&p=837339#p837339

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

Posted: Mon Mar 29, 2021 2:23 am
by doneware
True. If your goal is truly zero touch, then you need some method to get these 'legacy' IP addresses in there. Be nice to have mikrotik have the ability to automatically generate that and the local IPv6 addresses.
there is an RFC about this.
https://tools.ietf.org/html/rfc6286
A lot of pieces are missing there so basically relying on initialization scripts unless mikrotik presents a *complete* software stack that suits your particular needs.
this is what i did. fortunately routerOS is quite versatile to get this things done by scripts.
Along those lines you'd need to automatically build your EOIP6 tunnels to your core, which need tunnel ids limited to 999 etc. I'd say L2TP for simplicity but mikrotik doesn't have an L2TP6 interface option. VxLAN over UDP would be great but that's gotta wait til routeros7 *and* like someone said before, is only hardware accelleratable on certain platforms.
i wanted to use L2TP, as it has a lot of things, eogre/eoip doesn't have: session negotiation, authentication.
unless VXLAN in routerOS gets hw acceleration _and_ ipv6 underlay support, there's not much more it can deliver over EoIPv6. (ok, being interoperable with other implementations is a big plus)

in general i think all this extra acrobatics with tunnelling is unnecessary. the sole reason i did this came from the service environment i needed to fit in. if you have already several hundreds of thousands customers using PPPoE, and all the processes rely on this, you *have to* fit in. the best solution would have been pure IPv6, forwarding along the packet dst address, DHCPv6 PD towards the CPE, and NAT64/DNS64.

sadly, some of these elements are non-existing in the current ROS7 ecosystem, at least not yet. what i'd like
- IPv6 fasttrack/HW offloading
- DNS resolver default behaviour setting (A or AAAA)
- NAT64 with IPFix logging
- some client-server tunnelling (l2tp, sstp) with IPv6 underlay
- VXLAN with IPv6 underlay
- DHCPv6 PD -> RA interworking (on pool expiration)
- RFC 6286 unique as wide BGP ID
- full IPv6 addr/network manipulation in routerOS scripts (at least on par with IPv4)
- IPv6 redirect in IPv6 firewall (not crucial, but would be nice)

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

Posted: Tue Mar 30, 2021 9:57 am
by timnis
!) added new "iot" package with initial Bluetooth (KNOT only) and MQTT publisher support;
It says only publisher, but will there be subscriber support also? Possible to control gpio output/relay?
i already opened a support request about this (subscriber support) - or better put, i updated my old one - and Mikrotik Guys said they will consider it.
i first opened the request back in september last year, and the MQTT client was already being worked on. initially it was planned to be also available in v6, which would be kinda good. and in general, this is still totally possible.

back in may 2019 i created a poll about routerOS MQTT support: viewtopic.php?f=9&t=148558
the syntax i envisioned turned out to be quite similar. i imagined subscriber functionality linked to routerOS scripts with context-linked variables, just like the lease scripts with DHCP.
Hopefully they add subscriber support.

Then KNOT could be used to control eletric gates
- read rfid tag from reader on rs485 bus and publish it to mqtt topic
- subscribed to topic to and wait open command, if command arrives to open gate then open gate via gpio/relay

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

Posted: Thu Apr 01, 2021 5:24 pm
by andru
I have some bug with my RB1100AHx4 (routeros7.1 beta5;current firmware 7.1beta5)
When i use snmp v3 with authorization (md5 or sha1) and(or) cipher - cpu utilization becomes to level 60%-70% and free memory start slowly decrease.
With snmp v2 - all is ok.

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

Posted: Thu Apr 01, 2021 11:44 pm
by casus
960PGS
/system/health/print - nothing print, no temperatures, no voltage..
[admin@MikroTik] > /system/health/print 

[admin@MikroTik] 

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

Posted: Fri Apr 02, 2021 4:36 pm
by mrz
sadly, some of these elements are non-existing in the current ROS7 ecosystem, at least not yet. what i'd like
...
- RFC 6286 unique as wide BGP ID
RFC 6286 is implemented in ROS v7

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

Posted: Fri Apr 02, 2021 5:06 pm
by fbl
I'm having issues adding a simple output filter chain + selection rule.

When trying even a simple configuration as follows, RouterOS marks the selection-rule invalid:
/routing bgp template
add address-families=ip as=1234 input.filter=testrule name=test output.filter=test
/routing filter rule
add chain=testrule rule="action accept;"
/routing filter select-rule
add chain=test do-where=testrule
which results in:
[admin@test] > routing/filter/select-rule/print 
Flags: X - disabled, I - invalid 
 0 I chain=test do-where=testrule 

[admin@test] > routing/filter/select-chain/print 
Flags: I - inactive; D - dynamic 
 0 ID ;;; chain has invalid rules
      name="test" 

[admin@test] > routing/filter/chain/print 
Flags: I - inactive; D - dynamic 
 0 ID ;;; chain is empty
      name="" 

 1  D name="testrule" 
The empty filter rule chain with
name=""
only appears if the selection-rule is added.

I haven't been able to figure out how output filter chain + selection rules work with versions after 7.1beta2 yet.
For some reason the selection rule is marked as invalid. Any idea?

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

Posted: Fri Apr 02, 2021 6:03 pm
by mrz
Selection does not work in current beta. For filtering you can set testrule directly in bgp configuration.

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

Posted: Sat Apr 03, 2021 12:13 am
by doneware
RFC 6286 is implemented in ROS v7
that's good to hear. thx mrz.

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

Posted: Sat Apr 03, 2021 2:31 am
by fbl
Selection does not work in current beta. For filtering you can set testrule directly in bgp configuration.

Okay, thanks. So it previously only worked because my selection-chain and filter-chains had identical names. The examples in help.mikrotik.com already make use of the selection-rules, which might be misleading.

However, I still wasn't able to get RouterOS 7.1beta5 to announce anything to its neighbours.
Someone else seems to have the same issue here: viewtopic.php?f=1&t=173787&p=851566#p851566

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

Posted: Sat Apr 03, 2021 1:28 pm
by indy
My HAP Lite got hard bricked updating via Winbox from v7.1b4 to v7.1b5.
The router does not boot any more - the the Power-LED and Ether2 are lit, while Ether1 and Ether4 glow faintly.
I tried to install various versions via Netinstall, but even after successfully flashing, the router will not boot.

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

Posted: Sun Apr 04, 2021 12:06 am
by ib254254
VLAN opened on the bonding interface, including 6.47.9, 6.48.1 and 6.49beta27, switch to runing = false every time the bonding hash policy is changed. Runnig = true does not work unless you manually turn the interface off and on or change the hash policy again.

When I tested it with RouterOS 7.1beta5, I see that this problem does not occur. There are multiple developments regarding 7.1beta5 with regard to bonding. Does MikroTik plan to fix this problem with routerOS6?

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

Posted: Sun Apr 04, 2021 10:11 am
by elbob2002
My HAP Lite got hard bricked updating via Winbox from v7.1b4 to v7.1b5.
The router does not boot any more - the the Power-LED and Ether2 are lit, while Ether1 and Ether4 glow faintly.
I tried to install various versions via Netinstall, but even after successfully flashing, the router will not boot.
Flashing with 7.1beta5 again or an earlier version? Try the last know working version on it.

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

Posted: Sun Apr 04, 2021 12:42 pm
by indy
My HAP Lite got hard bricked updating via Winbox from v7.1b4 to v7.1b5.
The router does not boot any more - the the Power-LED and Ether2 are lit, while Ether1 and Ether4 glow faintly.
I tried to install various versions via Netinstall, but even after successfully flashing, the router will not boot.
Flashing with 7.1beta5 again or an earlier version? Try the last know working version on it.
For 6.47.9, 6.48.1, 7.1b4 the end result is the same.
Netinstall will format the flash and transfer the image - afterwards it will not boot and show the faint glowing LED behaviour.

Netinstall 7.1b5 will not find the router and the device will show the faint glowing LEDs during Etherboot (or maybe after aborting Etherboot).

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

Posted: Sun Apr 04, 2021 6:43 pm
by AllexRo
Anyone with an ok-running Audience willing to share their wireless settings? Mine, after setup, works ok a while (ranging from 10 minutes to 1-2 hours) then something crashes the internet connectivity and I can't find any relevant information in the log. Problem is solved only with a unit restart .

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

Posted: Mon Apr 05, 2021 12:54 am
by mducharme
My HAP Lite got hard bricked updating via Winbox from v7.1b4 to v7.1b5.
The router does not boot any more - the the Power-LED and Ether2 are lit, while Ether1 and Ether4 glow faintly.
I tried to install various versions via Netinstall, but even after successfully flashing, the router will not boot.
I had this problem with my hAP mini and resolved it by doing netinstall to beta 4. You may have to reset the configuration as part of the netinstall to get it to come back up.

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

Posted: Mon Apr 05, 2021 3:04 pm
by indy
My HAP Lite got hard bricked updating via Winbox from v7.1b4 to v7.1b5.
The router does not boot any more - the the Power-LED and Ether2 are lit, while Ether1 and Ether4 glow faintly.
I tried to install various versions via Netinstall, but even after successfully flashing, the router will not boot.
I had this problem with my hAP mini and resolved it by doing netinstall to beta 4. You may have to reset the configuration as part of the netinstall to get it to come back up.
Thanks for the tip - I had all but given up.
What brought the device back to life was flashing v7.1b4 with Netinstall, booting the backup bootloader (holding the reset button while booting), and then upgrading (or repairing) the main bootloader from Winbox.

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

Posted: Mon Apr 05, 2021 7:39 pm
by doneware
Anyone with an ok-running Audience willing to share their wireless settings?.
sure, here you go, i use it as a single AP, the 2x2 5Gig radio is disabled. it replaced a wAP ac (1st gen) a cap-ac, and a mAP. and i get ~500-600Mbps throughput with it. runs rock stable
[me@audience] /interface/wifiwave2> /system/resource/print 
             uptime: 2w2d5h39m15s
            version: 7.1beta5 (development)
         build-time: Mar/16/2021 14:41:12
   factory-software: 6.45.8
        free-memory: 65.2MiB
       total-memory: 256.0MiB
                cpu: ARMv7
          cpu-count: 4
      cpu-frequency: 448MHz
           cpu-load: 1%
     free-hdd-space: 79.9MiB
    total-hdd-space: 128.2MiB
  architecture-name: arm
         board-name: Audience
           platform: MikroTik
here's the export
/interface wifiwave2
add arp-timeout=auto band=2ghz-n disabled=no mac-address=48:8F:5A:F9:23:4F mode=ap name=wifi1 security.authentication-types=wpa2-psk \
    .passphrase=dummy123 ssid=homewlan
add arp-timeout=auto band=5ghz-ac channel-width=20/40/80mhz configuration.tx-chains=0,1 disabled=yes mac-address=48:8F:5A:F9:23:51 mode=ap \
    name=wifi2 security.authentication-types=wpa2-psk .passphrase=dummy123 .wps=disable ssid=test
# changed intended channel to 5500/ac/Ce
add arp-timeout=auto band=5ghz-ac channel-width=20/40/80mhz configuration.country=Hungary .tx-chains=0,1,2,3 disabled=no mac-address=\
    48:8F:5A:F9:23:51 mode=ap name=wifi3 security.authentication-types=wpa2-psk .passphrase=dummy123 .wps=disable ssid=\
    homewlan
the thing is that export is unusable here. obviously you can't "add" the hw radios. but in general i didn't do any magic here. see print command below (also looks screwed up)
[bat@audience] /interface/wifiwave2> print 
Flags: M - MASTER; B - BOUND; X - DISABLED, I - INACTIVE, R - RUNNING
Columns: NAME, MODE, SSID, BAND, CHANNEL-WIDTH
  #       NAME   MO  SSID      BAND     CHANNEL-WID
  0  MBR  wifi1  ap  homewlan  2ghz-n              
  1  MBX  wifi2  ap  test      5ghz-ac  20/40/80mhz
;;; changed intended channel to 5500/ac/Ce
  2  MBR  wifi3  ap  homewlan  5ghz-ac  20/40/80mhz
edit: albeit it looks i have 5ghz-ac only on the active 4x4 radio, but that's because wifiwave2 has different band settings. but it must be n/ac, as there is an old 1st gen Omnitik connected to it, and that device is a/n only. the 2.4gig radio seems to operate in g/n mode.
usually there are 12-20 clients connected, roughly the 2/3 of them to the 5Gig radio. sadly registration-table has also shortcomings compared to the 'old' wifi driver.
[me@audience] /interface/wifiwave2> monitor 0
             state: running
           channel: 2427/gn/Ce
  registered-peers: 6
  authorized-peers: 6
          tx-power: 29

[me@audience] /interface/wifiwave2> monitor 2
                ;;; changed intended channel to 5500/ac/Ce
             state: running
           channel: 5500/ac/Ce
  registered-peers: 9
  authorized-peers: 9
          tx-power: 30

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

Posted: Tue Apr 06, 2021 8:47 am
by andryan
with regards to the GPT issue, will there be a fix in beta6 to allow beta4 or older to beta6 or do we need to rebuild our CHR instances manually to beta5?

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

Posted: Tue Apr 06, 2021 10:17 am
by AllexRo
Anyone with an ok-running Audience willing to share their wireless settings?.
sure, here you go, i use it as a single AP, the 2x2 5Gig radio is disabled. it replaced a wAP ac (1st gen) a cap-ac, and a mAP. and i get ~500-600Mbps throughput with it. runs rock stable
Thank you, doneware!

Apparently, there are very few differences - I use all 3 radios, the 3rd one with 20/40/80/160 Mhz, I've enabled WPA3 and I've not declared the TX/RX chains (however Wireless/Radios shows them declared correctly). I have no vlans, no complicated configs..
/interface wifiwave2
add band=2ghz-n channel-width=20/40mhz-Ce configuration.country=Romania disabled=no frequency=2412:0 mac-address=\
    48:8F:5A:F9:32:10 mode=ap name=wifi1 security.authentication-types=wpa2-psk,wpa3-psk .encryption="" .passphrase=\
    ****** ssid=Alfa
add band=5ghz-ac channel-width=20/40/80mhz configuration.country=Romania disabled=no frequency=5180:0 mac-address=\
    48:8F:5A:F9:32:11 mode=ap name=wifi2 security.authentication-types=wpa2-psk,wpa3-psk .encryption="" .passphrase=\
    ****** ssid=Alfa_5G
# changed intended channel to 5500/ac/Ceeeeeee
add band=5ghz-ac channel-width=20/40/80/160mhz configuration.country=Romania disabled=no frequency=5500:0 mac-address=\
    48:8F:5A:F9:32:12 mode=ap name=wifi3 security.authentication-types=wpa2-psk,wpa3-psk .passphrase=****** ssid=\
    Alfa_6G
The only weird thing I found in log was:
error while running customized default configuration script: interrupted

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

Posted: Tue Apr 06, 2021 11:05 am
by doneware
The only weird thing I found in log was:
error while running customized default configuration script: interrupted
don't worry, that's "normal" for now. i also see you are using 160MHz on wifi3 - i just use 80MHz there.

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

Posted: Tue Apr 06, 2021 12:33 pm
by nannou9
My Audience 2.4GHz network is crashing frequently every few hours to every few days- this is consistent behaviour for beta 3/4/5 for me.
No idea what is causing it as there is nothing special happening- not adding any new devices, nor removing anything. So not sure why it sometimes crashes after few hours and sometimes after few days.
When it happens, there is no way to recover it and full reboot is needed. Simple stop/start of wifi1 interface doesn't work.
Logs are flooded with group key timeout errors when this happens.
I have 25 devices connected to 2.4GHz radio.
Never seen this happening to wifi3 on Beta5, but on wifi3 I have only 7 devices.
/interface bridge
add name=bridge-vlan1000 vlan-filtering=yes
/interface wifiwave2
add band=2ghz-n channel-width=20/40mhz-eC disabled=no mac-address=XXX mode=ap mtu=1500 name=wifi1 security.authentication-types=wpa-psk,wpa2-psk ssid=X2
add band=5ghz-ac channel-width=20/40/80mhz configuration.country="United Kingdom" disabled=yes mac-address=XXXXXX mode=ap mtu=1500 name=wifi2 security.authentication-types=wpa2-psk ssid="X5"
add band=5ghz-ac channel-width=20/40/80+80mhz configuration.country=Malaysia disabled=no mac-address=XXXX mode=ap mtu=1500 name=wifi3 security.authentication-types=wpa2-psk,wpa3-psk .disable-pmkid=yes \
    .encryption="" ssid="X6"
/interface vlan
add interface=bridge-vlan1000 name=vlan1000 vlan-id=1000
/interface bridge port
add bridge=bridge-vlan1000 frame-types=admit-only-vlan-tagged interface=ether1
add bridge=bridge-vlan1000 interface=ether2 pvid=1000
add bridge=bridge-vlan1000 interface=wifi3 pvid=1000
add bridge=bridge-vlan1000 interface=wifi1 pvid=1000
add bridge=bridge-vlan1000 interface=wifi2 pvid=1000
add bridge=bridge-vlan1000 interface=*8 pvid=1000
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/interface bridge vlan
add bridge=bridge-vlan1000 tagged=bridge-vlan1000,ether1 untagged=ether2,wifi3,wifi2,wifi1,*8 vlan-ids=1000
/ip dhcp-client
add disabled=no interface=vlan1000

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

Posted: Tue Apr 06, 2021 2:25 pm
by AllexRo
Yeah, I too noticed that my Audience's weird behavior has something to do with the 2.4 radio.
And the "solution" is the same: rebooting the router. I guess we have to wait for beta 6, maybe it solves this issue.

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

Posted: Wed Apr 07, 2021 12:34 am
by walterav1984
The RB751U-2HnD (discontinued) won't boot this 7.1b5 version in anyway. No matter if upgraded via packages web-update, nor via files upload followed by a reboot nor via winbox and finnally not even via netinstall. The leds of the connected interfaces won't come up after upgrade&reboot and device stays unavailable. Recovering via netinstall and reverting to 7.1b4 works.

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

Posted: Wed Apr 07, 2021 9:07 pm
by depach
For anyone struggling with IPv6 on beta5 and connection tracking not working (and the firewall dropping the packets as invalid)

After a few hours I discovered that if I disabled all ipv6 queue's then it worked perfectly.

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

Posted: Thu Apr 08, 2021 11:40 am
by pe1chl
The RB751U-2HnD (discontinued) won't boot this 7.1b5 version in anyway.
It would not surprise me at all when at some point in the v7 release process the support for some old devices with little memory and maybe uncommon chip will have to be dropped...
This is an unusual device in that it has only 32MB RAM but still has 64MB flash. The still-current "hAP lite" and "hAP mini" have only 32MB RAM and 16MB flash and will likely be even more difficult to support...

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

Posted: Thu Apr 08, 2021 12:19 pm
by pavelion
Brand new Chateau (RBD53G-5HacD2HnD) shipped with 7.1beta4 cannot be updated:
system,error: installation of system-7.1beta5 failed: broken package

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

Posted: Thu Apr 08, 2021 2:23 pm
by walterav1984
The RB751U-2HnD (discontinued) won't boot this 7.1b5 version in anyway.
It would not surprise me at all when at some point in the v7 release process the support for some old devices with little memory and maybe uncommon chip will have to be dropped...
This is an unusual device in that it has only 32MB RAM but still has 64MB flash. The still-current "hAP lite" and "hAP mini" have only 32MB RAM and 16MB flash and will likely be even more difficult to support...
Offcourse this have to be taken in account, but I would assume that further updates that are not compatible should not even be advertised in the packages update channel which is not the case. Reading on the number of current beta5 issues relating to boot even on supported hardware I guess the problem is something else.

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

Posted: Thu Apr 08, 2021 4:19 pm
by pe1chl
Offcourse this have to be taken in account, but I would assume that further updates that are not compatible should not even be advertised in the packages update channel which is not the case. Reading on the number of current beta5 issues relating to boot even on supported hardware I guess the problem is something else.
Sure... I did not test v7 yet on any real hardware, only on CHR. And even there I experienced update issues (see above) but I could fix them by starting from scratch (new VM).
But that is something that was identified and scheduled to be fixed, I don't think it will be the same problem on the RB751 router.

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

Posted: Fri Apr 09, 2021 2:02 am
by Rfulton
on my 4011, it's stuck "calculating download size"

Image

https://imgur.com/a/uO2Oaju

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

Posted: Fri Apr 09, 2021 4:52 pm
by pe1chl
You cannot update to v7 beta that way! You need to read the installation instructions, make your backups, download the software from the website, upload to your router.

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

Posted: Fri Apr 09, 2021 5:10 pm
by norpan
(!) enabled initial MPLS support (CLI only);
How initial is 'initial MPLS support'?
VRF seems to be implemented but I cannot successfully forward traffic over a L3VPN.

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

Posted: Sat Apr 10, 2021 4:59 am
by Rfulton
Is there no way to redistribute default route 0.0.0.0/0 to WAN using new OSPF? my other routers aren't getting it.

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

Posted: Mon Apr 12, 2021 11:15 am
by nos1609
Do not try to flash this on crs326 Q version, won't boot.

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

Posted: Mon Apr 12, 2021 11:30 am
by itforeverru
Hi, i'm using RBD52G-5HacD2HnD, firmware 7.1beta5 (development).
lte modem E3372h-320 after rebooting the modem, the router does not detect this device and you have to reboot the router. The same thing, if I pull it out and insert it back, nothing happens, you only need to reboot the router, otherwise there is no way.

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

Posted: Mon Apr 12, 2021 10:40 pm
by ntsecrets
ok, been using the 7.1 betas for a few months on a CRS309-1G-8S+. I realize that this is really intended to be a switch and not a router, but when it IS working as a router with hw offloading it works great. Here is what I've found with 7.1beta5:
  • HW Offloading for L3 only seems to work for a day or two after a reboot.
  • After being up for a few days, (may be related to the above) if you reboot from the GUI, it crashes with a kernel panic to the console instead of rebooting.
  • I've noticed that if I do a traceroute through it, it does not respond whereas other devices I've used for L3 routing in the past did. I don't have any firewall rules or anything else configured, just a few L3 interfaces with static ips and a couple of routes.
  • MINOR - if I use a DEC vt420 terminal on the console, whenever it sends the prompt, the terminal crashes and reboots, I realize its 30 years old but still kinda odd that it does that.
My wishlist would be solid L3 hardware offloading for both ipv4 and ipv6. Thanks.

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

Posted: Tue Apr 13, 2021 8:56 am
by rz3dvp
Image

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

Posted: Tue Apr 13, 2021 12:56 pm
by tkorves
Maybe this is somehow a bug-report:

Equipment: CCR1009-7G-1C-1S+ with a Draytek Vigor DSL-Modem on ETH7 and a SFP+ module (DA cabling from Mikrotik) connected to a CRS
Issue: After updating from 6.48.1 to 7.1beta5 it constantly bootloops until the SFP+ module is pulled from it's slot. After pulling the module, the CCR is working fine. When re-plugging the module, the router instantly reboots itself. I have not yet taken a look into our syslog server, but I doubt that there's any log message in regard to this issue (but will look into it in a couple of minutes).

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

Posted: Tue Apr 13, 2021 6:29 pm
by raimondsp
ok, been using the 7.1 betas for a few months on a CRS309-1G-8S+. I realize that this is really intended to be a switch and not a router, but when it IS working as a router with hw offloading it works great. Here is what I've found with 7.1beta5:
  • HW Offloading for L3 only seems to work for a day or two after a reboot.
  • After being up for a few days, (may be related to the above) if you reboot from the GUI, it crashes with a kernel panic to the console instead of rebooting.
  • I've noticed that if I do a traceroute through it, it does not respond whereas other devices I've used for L3 routing in the past did. I don't have any firewall rules or anything else configured, just a few L3 interfaces with static ips and a couple of routes.
  • MINOR - if I use a DEC vt420 terminal on the console, whenever it sends the prompt, the terminal crashes and reboots, I realize its 30 years old but still kinda odd that it does that.
My wishlist would be solid L3 hardware offloading for both ipv4 and ipv6. Thanks.

Hi and thank you for the feedback!
  • While CRS (Cloud Router Switch) is "more switch than a router", the device still can operate as a router, especially with L3 HW Offloading enabled.
  • We have found and fixed some issues that, under some circumstances, could lead to a crash on reboot. The fixes will present in the next Beta.
  • You don't see traceroute responses because ICMP replies are disabled in the case of L3HW to prevent potential DDoS attacks. The hardware is incapable of sending ICMP messages, so in order to get an ICMP reply (in the case of traceroute - TTL Exceeded), the packet would have to travel to the CPU. However, I agree that having ICMP rellies might be useful, especially during the network setup or testing. I have created a development task to introduce a configuration option to enable/disable ICMP replies during L3HW.
  • IPv6 support for L3 HW Offloading is on the roadmap. Should be implemented later this year.

Regarding "HW Offloading for L3 only seems to work for a day or two after a reboot", can you provide more details, please?
  1. Do switch ports have l3-hw-offloading enabled? You can check it from the console:
    /interface/ethernet/switch/port print
  2. How does L3 Offloading stop working? Do packets get dropped, or the routing falls back to CPU?
  3. Can you still connect to the CRS after L3HW stops working?

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

Posted: Tue Apr 13, 2021 9:11 pm
by ntsecrets
ok, been using the 7.1 betas for a few months on a CRS309-1G-8S+. I realize that this is really intended to be a switch and not a router, but when it IS working as a router with hw offloading it works great. Here is what I've found with 7.1beta5:
  • HW Offloading for L3 only seems to work for a day or two after a reboot.
  • After being up for a few days, (may be related to the above) if you reboot from the GUI, it crashes with a kernel panic to the console instead of rebooting.
  • I've noticed that if I do a traceroute through it, it does not respond whereas other devices I've used for L3 routing in the past did. I don't have any firewall rules or anything else configured, just a few L3 interfaces with static ips and a couple of routes.
  • MINOR - if I use a DEC vt420 terminal on the console, whenever it sends the prompt, the terminal crashes and reboots, I realize its 30 years old but still kinda odd that it does that.
My wishlist would be solid L3 hardware offloading for both ipv4 and ipv6. Thanks.

Hi and thank you for the feedback!
  • While CRS (Cloud Router Switch) is "more switch than a router", the device still can operate as a router, especially with L3 HW Offloading enabled.
  • We have found and fixed some issues that, under some circumstances, could lead to a crash on reboot. The fixes will present in the next Beta.
  • You don't see traceroute responses because ICMP replies are disabled in the case of L3HW to prevent potential DDoS attacks. The hardware is incapable of sending ICMP messages, so in order to get an ICMP reply (in the case of traceroute - TTL Exceeded), the packet would have to travel to the CPU. However, I agree that having ICMP rellies might be useful, especially during the network setup or testing. I have created a development task to introduce a configuration option to enable/disable ICMP replies during L3HW.
  • IPv6 support for L3 HW Offloading is on the roadmap. Should be implemented later this year.

Regarding "HW Offloading for L3 only seems to work for a day or two after a reboot", can you provide more details, please?
  1. Do switch ports have l3-hw-offloading enabled? You can check it from the console:
    /interface/ethernet/switch/port print
  2. How does L3 Offloading stop working? Do packets get dropped, or the routing falls back to CPU?
  3. Can you still connect to the CRS after L3HW stops working?
I believe they do have L3 enabled, it is currently in that state where it seems to fall back to CPU.

Columns: NAME, SWITCH, L3-HW-OFFLOADING, STORM-RATE
  #  NAME              SWITCH   L3-  STO
  0  1-xxxxx            switch1  yes  100
  1  2-xxxxx            switch1  yes  100
  2  3-xxxxx            switch1  yes  100
  3  sfp-sfpplus4      switch1  yes  100
  4  sfp-sfpplus5      switch1  yes  100
  5  sfp-sfpplus6      switch1  yes  100
  6  sfp-sfpplus7      switch1  yes  100
  7  sfp-sfpplus8      switch1  yes  100
  8  ether1            switch1  yes  100
  9  switch1-cpu       switch1       100
  
interface ethernet switch
set 0 l3-hw-offloading=yes
and
/interface/ethernet/switch> print
Columns: NAME, TYPE, L3-HW-OFFLOADING
  #  NAME     TYPE              L3-
  0  switch1  Marvell-98DX8208  yes
  
  
Yes, when it stops using hw offloading (from what I observe) it falls back to CPU. I test it by generating a lot of traffic locally between two vlans - a server on one and a client on another, running a speedtest page like https://github.com/librespeed/speedtest
After a reboot, running this will yield good results, and observing the CPU on the resource page will show 0-1% cpu during the test. After a day or two, running the same test will show slower results, usually inbound to the client and the cpu will go to 99%. I made sure it is using ipv4 for the test.
As for the ipv6 and icmp replies, that is GREAT news I am very excited to hear that. Thank you!
If you need one, I may be able to get a copy of the kernel panic on reboot if that helps.

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

Posted: Thu Apr 15, 2021 9:01 pm
by Rfulton
Fix GRE keepalive please.

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

Posted: Fri Apr 16, 2021 11:20 am
by raimondsp
I believe they do have L3 enabled, it is currently in that state where it seems to fall back to CPU.

Columns: NAME, SWITCH, L3-HW-OFFLOADING, STORM-RATE
  #  NAME              SWITCH   L3-  STO
  0  1-xxxxx            switch1  yes  100
  1  2-xxxxx            switch1  yes  100
  2  3-xxxxx            switch1  yes  100
  3  sfp-sfpplus4      switch1  yes  100
  4  sfp-sfpplus5      switch1  yes  100
  5  sfp-sfpplus6      switch1  yes  100
  6  sfp-sfpplus7      switch1  yes  100
  7  sfp-sfpplus8      switch1  yes  100
  8  ether1            switch1  yes  100
  9  switch1-cpu       switch1       100
  
interface ethernet switch
set 0 l3-hw-offloading=yes
and
/interface/ethernet/switch> print
Columns: NAME, TYPE, L3-HW-OFFLOADING
  #  NAME     TYPE              L3-
  0  switch1  Marvell-98DX8208  yes
  
  
Yes, when it stops using hw offloading (from what I observe) it falls back to CPU. I test it by generating a lot of traffic locally between two vlans - a server on one and a client on another, running a speedtest page like https://github.com/librespeed/speedtest
After a reboot, running this will yield good results, and observing the CPU on the resource page will show 0-1% cpu during the test. After a day or two, running the same test will show slower results, usually inbound to the client and the cpu will go to 99%. I made sure it is using ipv4 for the test.
As for the ipv6 and icmp replies, that is GREAT news I am very excited to hear that. Thank you!
If you need one, I may be able to get a copy of the kernel panic on reboot if that helps.
I suggest waiting for 7.1beta6 - there will be a lot of changes regarding L3 HW Offloading. Then, if the problems will still remain, create a support ticket.

P.S. The latest news from the development frontline: ICMP replies have been implemented and moved to QA. Traceroute correctly shows all routers with L3 HW enabled.

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

Posted: Fri Apr 16, 2021 1:44 pm
by VitohA
Found issue regarding graphing: it doesn't work through https, always shows 404 error. Through http all ok, seems www-ssl service has some issues with it. Tested on hAP ac² and CCR2004-1G-12S+2XS.

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

Posted: Fri Apr 16, 2021 8:47 pm
by nannou9
My Audience 2.4GHz network is crashing frequently every few hours to every few days- this is consistent behaviour for beta 3/4/5 for me.
No idea what is causing it as there is nothing special happening- not adding any new devices, nor removing anything. So not sure why it sometimes crashes after few hours and sometimes after few days.
When it happens, there is no way to recover it and full reboot is needed. Simple stop/start of wifi1 interface doesn't work.
Logs are flooded with group key timeout errors when this happens.
I have 25 devices connected to 2.4GHz radio.
Never seen this happening to wifi3 on Beta5, but on wifi3 I have only 7 devices.
/interface bridge
add name=bridge-vlan1000 vlan-filtering=yes
/interface wifiwave2
add band=2ghz-n channel-width=20/40mhz-eC disabled=no mac-address=XXX mode=ap mtu=1500 name=wifi1 security.authentication-types=wpa-psk,wpa2-psk ssid=X2
add band=5ghz-ac channel-width=20/40/80mhz configuration.country="United Kingdom" disabled=yes mac-address=XXXXXX mode=ap mtu=1500 name=wifi2 security.authentication-types=wpa2-psk ssid="X5"
add band=5ghz-ac channel-width=20/40/80+80mhz configuration.country=Malaysia disabled=no mac-address=XXXX mode=ap mtu=1500 name=wifi3 security.authentication-types=wpa2-psk,wpa3-psk .disable-pmkid=yes \
    .encryption="" ssid="X6"
/interface vlan
add interface=bridge-vlan1000 name=vlan1000 vlan-id=1000
/interface bridge port
add bridge=bridge-vlan1000 frame-types=admit-only-vlan-tagged interface=ether1
add bridge=bridge-vlan1000 interface=ether2 pvid=1000
add bridge=bridge-vlan1000 interface=wifi3 pvid=1000
add bridge=bridge-vlan1000 interface=wifi1 pvid=1000
add bridge=bridge-vlan1000 interface=wifi2 pvid=1000
add bridge=bridge-vlan1000 interface=*8 pvid=1000
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/interface bridge vlan
add bridge=bridge-vlan1000 tagged=bridge-vlan1000,ether1 untagged=ether2,wifi3,wifi2,wifi1,*8 vlan-ids=1000
/ip dhcp-client
add disabled=no interface=vlan1000
Would be thankful if support could comment if any fix is coming for 2.4ghz radios.
My audience 2.4ghz radio is sometimes crashing multiple times a day, with random devices unable to join again and needing restarting.

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

Posted: Fri Apr 16, 2021 9:05 pm
by erlinden
Would be thankful if support could comment if any fix is coming for 2.4ghz radios.
My audience 2.4ghz radio is sometimes crashing multiple times a day, with random devices unable to join again and needing restarting.
Use 20MHz bandwidth (unless there are no interference sources at all) and only WPA2-AES only. Hope this makes a difference.

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

Posted: Fri Apr 16, 2021 9:34 pm
by infabo

Would be thankful if support could comment if any fix is coming for 2.4ghz radios.
My audience 2.4ghz radio is sometimes crashing multiple times a day, with random devices unable to join again and needing restarting.
try netinstall

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

Posted: Fri Apr 16, 2021 9:59 pm
by nannou9

try netinstall
Sorry for noob question, but how netinstall is different from factory reset?
I mean I know what netinstall is, but just not sure why it would make a difference vs factory reset.

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

Posted: Fri Apr 16, 2021 10:00 pm
by mkx
Factory reset resets configuration, SW install remains intact. Netinstall wipes non-volatile storage and installs everything anew.

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

Posted: Sat Apr 17, 2021 12:16 pm
by pe1chl
Can you please add the "rpfilter" matcher to the firewall matching rule options?
See viewtopic.php?f=2&t=120863 and viewtopic.php?f=14&t=56572

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

Posted: Sun Apr 18, 2021 12:02 pm
by mafiosa
I believe they do have L3 enabled, it is currently in that state where it seems to fall back to CPU.

Columns: NAME, SWITCH, L3-HW-OFFLOADING, STORM-RATE
  #  NAME              SWITCH   L3-  STO
  0  1-xxxxx            switch1  yes  100
  1  2-xxxxx            switch1  yes  100
  2  3-xxxxx            switch1  yes  100
  3  sfp-sfpplus4      switch1  yes  100
  4  sfp-sfpplus5      switch1  yes  100
  5  sfp-sfpplus6      switch1  yes  100
  6  sfp-sfpplus7      switch1  yes  100
  7  sfp-sfpplus8      switch1  yes  100
  8  ether1            switch1  yes  100
  9  switch1-cpu       switch1       100
  
interface ethernet switch
set 0 l3-hw-offloading=yes
and
/interface/ethernet/switch> print
Columns: NAME, TYPE, L3-HW-OFFLOADING
  #  NAME     TYPE              L3-
  0  switch1  Marvell-98DX8208  yes
  
  
Yes, when it stops using hw offloading (from what I observe) it falls back to CPU. I test it by generating a lot of traffic locally between two vlans - a server on one and a client on another, running a speedtest page like https://github.com/librespeed/speedtest
After a reboot, running this will yield good results, and observing the CPU on the resource page will show 0-1% cpu during the test. After a day or two, running the same test will show slower results, usually inbound to the client and the cpu will go to 99%. I made sure it is using ipv4 for the test.
As for the ipv6 and icmp replies, that is GREAT news I am very excited to hear that. Thank you!
If you need one, I may be able to get a copy of the kernel panic on reboot if that helps.
I suggest waiting for 7.1beta6 - there will be a lot of changes regarding L3 HW Offloading. Then, if the problems will still remain, create a support ticket.

P.S. The latest news from the development frontline: ICMP replies have been implemented and moved to QA. Traceroute correctly shows all routers with L3 HW enabled.
PLEASE PLEASE PLEASE IMPLEMENT PROPER ROUTE FILTERING AND OSPFV3 SO THAT WE CAN DO EXTENSIVE TESTING OF ROUTING FEATURES.

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

Posted: Tue Apr 20, 2021 8:16 am
by nostromog
Have "unreachable" routes disappeared in beta5 (or even before)?

I use to set up unreachable routes like
/ip route
add distance=5 dst-address=10.0.0.0/8 type=unreachable
add distance=5 dst-address=172.16.0.0/12 type=unreachable
add distance=5 dst-address=192.168.0.0/16 type=unreachable
but those have been changed in beta5 to
/ip route
add blackhole distance=5 dst-address=10.0.0.0/8
add blackhole distance=5 dst-address=172.16.0.0/12
add blackhole distance=5 dst-address=192.168.0.0/16
A blackhole is not the same as a route that will return a "network unreachable" icmp packet.

Have unreachable routes been removed? They are still there in the underlying linux...

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

Posted: Tue Apr 20, 2021 11:09 am
by pe1chl
Have "unreachable" routes disappeared in beta5 (or even before)?
It looks like it. That sure is not good! Similar to you, I always add routes like that and they should not simply drop the packets.

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

Posted: Tue Apr 20, 2021 1:38 pm
by mrz
v7 uses new Linux ip-nexthop which supports only "blackhole" nexthop.
But there is still an option to add firewall rule to send ICMP unreachable for specific destinations.

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

Posted: Tue Apr 20, 2021 2:11 pm
by pe1chl
v7 uses new Linux ip-nexthop which supports only "blackhole" nexthop.
But there is still an option to add firewall rule to send ICMP unreachable for specific destinations.
Are you sure that would work? Normally when you have unreachable or blackhole destinations in the routing table, the "forward" rules in the firewall are not processed for those destinations.
Is that different for ip-nexthop?

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

Posted: Tue Apr 20, 2021 2:19 pm
by mrz
As far as I understood you were thinking to add blackhole route and filrewall rule and expect that ICMP replies for blackholed traffic would be sent? That of course would not work.
If you do not add blackhole route, but just add firewall rule for specific destiantion then it will work.

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

Posted: Tue Apr 20, 2021 2:58 pm
by pe1chl
If you do not add blackhole route, but just add firewall rule for specific destiantion then it will work.
That would mean you have to add rules to catch it in the firewall.
But it is not easy, as the solution of course has to work with most-specific-subnet-first handling like a routing table does.
You see, in the example that @nostromog gave and that I also use, of course there may be (and likely will be) subnets inside those networks that are reachable.
So a simple "put those ranges in an address list and filter on that" is not going to work.

A workaround could be to create some dummy interface (empty bridge), set the routes to there, and firewall traffic sent to that interface.
However, the original solution was much easier and much cleaner. Why was it dropped?

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

Posted: Tue Apr 20, 2021 3:06 pm
by raimondsp
The problem with "unreachable" and "prohibited" routes is that the decision to send an ICMP reply gets taken on Layer 3 before reaching the firewall. Therefore, those routes are vulnerable to DDoS attacks. Moreover, with Layer 3 Hardware Offloading, we can offload blackhole routes to the hardware and block unwanted traffic on the hardware level without performance degradation. But we cannot do the same for "unreachable" and "prohibit" routes - the hardware would have to send the packets to the CPU for composing ICMP replies and, therefore, make the system vulnerable to DDoS.

As mrz said, you can still send the ICMP replies via Firewall rules if needed. Otherwise, "unreachable" and "prohibited" routes are deprecated.

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

Posted: Tue Apr 20, 2021 5:12 pm
by Gennadiy51
hAPac^3
Led WiFi in RouterOS 7.1beta5 does not work.

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

Posted: Tue Apr 20, 2021 5:48 pm
by nostromog
The problem with "unreachable" and "prohibited" routes is that the decision to send an ICMP reply gets taken on Layer 3 before reaching the firewall. Therefore, those routes are vulnerable to DDoS attacks. Moreover, with Layer 3 Hardware Offloading, we can offload blackhole routes to the hardware and block unwanted traffic on the hardware level without performance degradation. But we cannot do the same for "unreachable" and "prohibit" routes - the hardware would have to send the packets to the CPU for composing ICMP replies and, therefore, make the system vulnerable to DDoS.

As mrz said, you can still send the ICMP replies via Firewall rules if needed. Otherwise, "unreachable" and "prohibited" routes are deprecated.
In my use case, blackhole routes are useless, as this is exactly the behaviour I get from upstream if I let the packets go to the default route; on the other side, I have no risk of DDoS because I control (at least I can find them physically and hit their owner in the head!) all of the machines in the (small) office at the internal side, and the external side will never send packets addressed to RFC addresses. The unreachable routes are handy because intranet users get a quick rejection message instead of waiting forever if they try to reach an address outside of the internal addresses or a VPN address while the link is down, etc.

So, you mean doing something like this?
/interface bridge add name=nowhere
/ip route
add disabled=no distance=2 dst-address=10.0.0.0/8 gateway=nowhere
add disabled=no distance=2 dst-address=172.16.0.0/12 gateway=nowhere
add disabled=no distance=2 dst-address=192.168.0.0/16 gateway=nowhere
# for me a nice place to put this rule is before the "accept all ICMP" one
/ip firewall filter add action=reject chain=forward out-interface=nowhere reject-with=icmp-network-unreachable place-before=[/ip/firewall/filter/find where chain=forward and action=accept and protocol~"icmp"] 
It seems to work for me but I wonder if I overlooked something...

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

Posted: Tue Apr 20, 2021 6:49 pm
by mrz
If, as you say, you have default route, then there is no need to add static routes to nowhere, you can use address lists
/ip firewall address-list 
add list=unreachable address=10.0.0.0/8
add list=unreachable address=172.16.0.0/12
add list=unreachable address=192.168.0.0/16

/ip firewall filter add address-list=unreachable action=reject chain=forward reject-with=icmp-network-unreachable

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

Posted: Tue Apr 20, 2021 6:51 pm
by pe1chl
So, you mean doing something like this?
That is what I had in mind, yes. At least it has the same functionality as an unreachable route.
Like you, I do not worry that much about DDoS, so it is a bit of a pity that we still have to suffer from feature reduction.
Hopefully this solution would also work on those hardware accelerated devices (I don't have any).

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

Posted: Tue Apr 20, 2021 6:52 pm
by pe1chl
If, as you say, you have default route, then there is no need to add static routes to nowhere, you can use address lists
No, this is wrong! See reply #216.

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

Posted: Tue Apr 20, 2021 8:33 pm
by nostromog
If, as you say, you have default route, then there is no need to add static routes to nowhere, you can use address lists
/ip firewall address-list 
add list=unreachable address=10.0.0.0/8
add list=unreachable address=172.16.0.0/12
add list=unreachable address=192.168.0.0/16

/ip firewall filter add address-list=unreachable action=reject chain=forward reject-with=icmp-network-unreachable
If I did so, as already mentioned, I would have to except one by one, and possibly dynamically, the subnets that actually exist, and have routes (some VPN related, some static, some dynamic, some even going through the same default gateway interface...). So instead of adding 192.168.0.0/16 I would have complex subnets. I really use the routing machinery to deal with the specific routes, and only packets going through the default route would need to be rejected.

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

Posted: Tue Apr 20, 2021 9:14 pm
by syadnom
What about the wave2 wifi package features? Will it support WDS or 802.11s meshing?

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

Posted: Tue Apr 20, 2021 9:19 pm
by eworm
I think this will cause some headache for me as well... Let's say I have a route 10.20.0.0/16 and 192.168.20.0/24 via OSPF. How can I excludes these from being catched by the above access-list and firewall rule?

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

Posted: Tue Apr 20, 2021 9:33 pm
by pe1chl
I think this will cause some headache for me as well... Let's say I have a route 10.20.0.0/16 and 192.168.20.0/24 via OSPF. How can I excludes these from being catched by the above access-list and firewall rule?
That access list based on address-list is no good. The other workaround (reply #219) should be OK.

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

Posted: Tue Apr 20, 2021 9:55 pm
by eworm
Ah, skipped that one too fast... Yes, looks promising.
I will give it a try as soon as a beta with OSPF setting for path cost is available.

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

Posted: Thu Apr 22, 2021 8:04 pm
by pe1chl
When using multiple routing tables combined with a routing protocol in v6 I encounter the problem that the "connected route" for an interface is only inserted in the main table.
While this is usually no problem for the routing itself (ip route rules can be configured to look in the main table for local traffic), it causes a problem when using "bgp networks" to configure what the BGP instance should publish.
To work around that, I regularly copy the connected routes from main to the second routing table using winbox (open all DAC routes, do a Copy, change routing mark and distance and store).
However, that does not solve the problem for dynamically created interfaces like VPN or PPPoE.

Will the new architecture for routing and routing protocols in v7 fix this? If not, please think about a fix. E.g. some setting per interface to copy connected route to some specified table.
(it could be that using the VRF feature could solve part of these issues, but unfortunately there is too little documentation on how this exactly works to make it useful)

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

Posted: Thu Apr 22, 2021 8:41 pm
by mducharme
Will the new architecture for routing and routing protocols in v7 fix this? If not, please think about a fix. E.g. some setting per interface to copy connected route to some specified table.
(it could be that using the VRF feature could solve part of these issues, but unfortunately there is too little documentation on how this exactly works to make it useful)
This is already on the list: https://help.mikrotik.com/docs/display/ ... col+Status

"Some kind of mechanism to import/export routes from one vrf to another within same router"

Currently listed as not yet implemented but that page has not been updated for v7beta5.

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

Posted: Thu Apr 22, 2021 9:59 pm
by shavenne
I've accidently rebooted my RB4011 (without WiFi) after 5 days uptime on 7.1beta5. All was running fine but since this reboot it crashes every about 4 hours. Happened six times now. Sometimes a bit less than 4 hours, sometimes a little above.
There's nothing else noticeable. No cpu load, no unusual memory usage (always <100MB usage), no slowdown, nothing. It just crashes, reboots (did not come back itself one time), and log just says "router was rebooted without proper shutdown". Nothing else.

Does anybody know what RouterOS could be doing every about 4 hours?

The only thing that could be new is that I'm using EOIP over a Wireguard connection now (Wireguard without EOIP before that). Unfortunately I can't deactivate it to test it at this time.

Image

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

Posted: Thu Apr 22, 2021 10:21 pm
by mducharme
I've accidently rebooted my RB4011 (without WiFi) after 5 days uptime on 7.1beta5. All was running fine but since this reboot it crashes every about 4 hours. Happened six times now. Sometimes a bit less than 4 hours, sometimes a little above.
Make sure your RouterBOOT firmware is also upgraded to 7.1beta5. I had similar reboots on RouterOS 7.1beta5 (with wifi) and found out it was because I forgot to update the RouterBOOT firmware to 7.1beta5 as well.

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

Posted: Thu Apr 22, 2021 10:25 pm
by shavenne
Thank you but it already is updated :/

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

Posted: Thu Apr 22, 2021 11:23 pm
by Jotne
Does anybody know what RouterOS could be doing every about 4 hours?
Do you use DoH with certificate verification?

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

Posted: Thu Apr 22, 2021 11:27 pm
by infabo
Does anybody know what RouterOS could be doing every about 4 hours?
Do you use DoH with certificate verification?
I use that and have no reboots.

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

Posted: Thu Apr 22, 2021 11:31 pm
by infabo
I had reboots every few hours as well, caused by cake simple queue. After disabling that, reboots happend only once a day. Then only netinstall finally resolved it and the device is rock stable right now (10d+ uptime)

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

Posted: Thu Apr 22, 2021 11:47 pm
by Jotne
I use that and have no reboots.

I do not have reboot, but a big memory leakage.
viewtopic.php?p=854375#p854375

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

Posted: Fri Apr 23, 2021 12:20 am
by shavenne
No DoH, also no queues.
I've managed to remove the EoIP and route my stuff now again directly over Wireguard like before. Hope the crashes are gone now. I'll report.

/edit: 12 hours uptime now. So it seems EoIP is kinda broken maybe?!

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

Posted: Fri Apr 23, 2021 12:13 pm
by telecomadmin
RouterOS version 7.1beta5 has been released in public "development" channel!

What's new in 7.1beta5 (2021-Mar-16 14:41):

!) added new "iot" package with initial Bluetooth (KNOT only) and MQTT publisher support;
!) ported features and fixes introduced in v6.48.1;
!) enabled initial MPLS support (CLI only);
*) export - fixed "export" command hanging;
*) wifiwave2 - improved interface stability with multiple WPA3 authenticated clients;
*) other minor fixes and improvements;

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

How to report RouterOS v7 bugs:
viewtopic.php?f=1&t=152006
routeros 7.1b5 dev chr bugs
viewtopic.php?f=1&t=174711

1. GRE tunnel keepalive is not available
2.pppoe-out1 no have any data to show
3.Routing-mark cannot add new mark routing name

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

Posted: Fri Apr 23, 2021 12:17 pm
by mrz
3.Routing-mark cannot add new mark routing name
You need to add routing table first, see example here.
https://help.mikrotik.com/docs/display/ ... tingTables

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

Posted: Fri Apr 23, 2021 4:49 pm
by rextended
Someone please chech this bug if also on 7.1beta5:
viewtopic.php?f=2&t=174719

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

Posted: Fri Apr 23, 2021 5:23 pm
by baronkis
Thanks for the suggestion. I increased the drive on ESXI 6.5 VM from 64M to 128M and successfully started RouterOS

Mine fails to boot too. My message is slightly different though:
Load system

Resizing disk(GPT)...
ERROR: could not mount disk!
Please attach it somewhere else.
For those seeing these GPT errors - you have to give the VM more HDD space.

For me I had mine set to the default? 64MB. I increased to 256MB and it resolved my issue without loss of configuration.

Looks like its converting from MBR to GPT, so you need extra space for the FAT32 UEFI partition I'm guessing.

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

Posted: Fri Apr 23, 2021 5:50 pm
by pe1chl
Someone please chech this bug if also on 7.1beta5:
viewtopic.php?f=2&t=174719
That cannot be present in v7 because there are no such separate packages for parts of the basic functionality anymore, everthing is now in one package "routeros".
Now packages are only used for some niche functions like UPS monitoring. So there is no such thing as disabling/removing the "security" package anymore in v7.

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

Posted: Fri Apr 23, 2021 6:05 pm
by rextended
Someone please chech this bug if also on 7.1beta5:
viewtopic.php?f=2&t=174719
That cannot be present in v7 because there are no such separate packages for parts of the basic functionality anymore, everthing is now in one package "routeros".
Now packages are only used for some niche functions like UPS monitoring. So there is no such thing as disabling/removing the "security" package anymore in v7.
Very thanks for that info!
I must try 7 when I have time.
Have a nice day.

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

Posted: Fri Apr 23, 2021 6:58 pm
by mrz
Yes, in v7 all security stuff is integrated into system package.

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

Posted: Sat Apr 24, 2021 12:38 pm
by b0n3v
RB3011 arm, CAPsMAN on 1AP, PPPoE WAN (100mbps), ~20 clients, high internal traffic, WireGuard VPN in 70% of the time is active, only IPv4 used here, 28 firewall rules, cloud enabled. No issue for now(or at least I haven't noticed there).
Capture.PNG

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

Posted: Sat Apr 24, 2021 4:25 pm
by mhugo

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

Posted: Tue Apr 27, 2021 1:43 am
by Cablenut9
I just got a random reboot on my RB4011 running 7.1b5, all I get in the log is that it was rebooted without a proper shutdown. Memory usage was normal beforehand so it likely wasn't a memory leak.

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

Posted: Wed Apr 28, 2021 9:53 am
by mafiosa
waiting for a beta with functional route filtering. I can then test it extensively.

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

Posted: Thu Apr 29, 2021 1:23 am
by mhugo
waiting for a beta with functional route filtering. I can then test it extensively.
Same here :) Hopefully soon!

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

Posted: Thu Apr 29, 2021 9:57 am
by memelchenkov
When the new beta will be released? I am so tired to wait for a fix of bridge IP filtering functionality, which totally break my config (I must disable it to continue to use your router).

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

Posted: Thu Apr 29, 2021 5:19 pm
by infabo
Maybe report the issues you have found to support. They may provide beta6 for testing.

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

Posted: Thu Apr 29, 2021 8:57 pm
by memelchenkov
Maybe report the issues you have found to support. They may provide beta6 for testing.
Their official answer at 21st of April was "Unfortunately, the issue still is not fixed. I will remind the developer team about this issue. Apologize for the inconvenience caused." Original report of the issue was in November-December 2020.

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

Posted: Fri Apr 30, 2021 1:45 am
by nannou9
They are doing the right thing (I hope) stabilising core.
7.1b5 is still crashing frequently on many devices (sometimes multiple times a day on my Audience), same with wifi.
So they are (I hope again) focusing on core features, without which it makes no sense to use it at all.
Otherwise you would have your IP filter but it would be crashing multiple times a day- makes no sense.
Reality is (sadly) ROS 7 is still long way from being stable, and will not be released this year at this speed.

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

Posted: Fri Apr 30, 2021 4:25 pm
by pe1chl
Under /system logging action for target=remote please add some option to include the topics in the message sent to the remote log server.
E.g. add [topic,topic,topic] between the system name and the message when this option is set.

(would be nice when that is done in v6 as well...)

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

Posted: Fri Apr 30, 2021 11:25 pm
by sfrode
  1. IPv6 support for L3 HW Offloading is on the roadmap. Should be implemented later this year.
This is great news!

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

Posted: Sat May 01, 2021 7:26 am
by Moebius
MC7455 modem, working under 7.1b2 in MBIM is not functional under 7.1b5. A downgrade to 7.1b2 restores functionality.

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

Posted: Tue May 04, 2021 1:54 am
by Rfulton
My drop invalid rule is dropping pings on the return from internal on IPV6

Drop Invalid forward: in:UplinkToCisco-LAN out:ETH1-WAN, src-mac 7c:21:0e:d9:cc:c0, proto ICMP (type 129, code 0), 2600:ccc0->2604:2001, len 64

9 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid log=yes log-prefix="Drop Invalid

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

Posted: Tue May 04, 2021 6:51 pm
by Rfulton

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

Posted: Tue May 04, 2021 8:00 pm
by Rfulton
It appears IPV6 connection tracking does not work on 7.5Beta5?

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

Posted: Wed May 05, 2021 1:30 am
by nannou9
My Audience 2.4GHz network is crashing frequently every few hours to every few days- this is consistent behaviour for beta 3/4/5 for me.
No idea what is causing it as there is nothing special happening- not adding any new devices, nor removing anything. So not sure why it sometimes crashes after few hours and sometimes after few days.
When it happens, there is no way to recover it and full reboot is needed. Simple stop/start of wifi1 interface doesn't work.
Logs are flooded with group key timeout errors when this happens.
I have 25 devices connected to 2.4GHz radio.
Never seen this happening to wifi3 on Beta5, but on wifi3 I have only 7 devices.
/interface bridge
add name=bridge-vlan1000 vlan-filtering=yes
/interface wifiwave2
add band=2ghz-n channel-width=20/40mhz-eC disabled=no mac-address=XXX mode=ap mtu=1500 name=wifi1 security.authentication-types=wpa-psk,wpa2-psk ssid=X2
add band=5ghz-ac channel-width=20/40/80mhz configuration.country="United Kingdom" disabled=yes mac-address=XXXXXX mode=ap mtu=1500 name=wifi2 security.authentication-types=wpa2-psk ssid="X5"
add band=5ghz-ac channel-width=20/40/80+80mhz configuration.country=Malaysia disabled=no mac-address=XXXX mode=ap mtu=1500 name=wifi3 security.authentication-types=wpa2-psk,wpa3-psk .disable-pmkid=yes \
    .encryption="" ssid="X6"
/interface vlan
add interface=bridge-vlan1000 name=vlan1000 vlan-id=1000
/interface bridge port
add bridge=bridge-vlan1000 frame-types=admit-only-vlan-tagged interface=ether1
add bridge=bridge-vlan1000 interface=ether2 pvid=1000
add bridge=bridge-vlan1000 interface=wifi3 pvid=1000
add bridge=bridge-vlan1000 interface=wifi1 pvid=1000
add bridge=bridge-vlan1000 interface=wifi2 pvid=1000
add bridge=bridge-vlan1000 interface=*8 pvid=1000
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/interface bridge vlan
add bridge=bridge-vlan1000 tagged=bridge-vlan1000,ether1 untagged=ether2,wifi3,wifi2,wifi1,*8 vlan-ids=1000
/ip dhcp-client
add disabled=no interface=vlan1000
Recently observed another pattern for wifi problem where random clients are not able to rejoin. Affects wifi1 and 3 on my audience. This is happening to me from beta 4 I think but initially wasn’t sure what is causing it. Over time more devices been misbehaving like that only leaving the router as possibility.
Export in quoted text.
This was never happening to me on any other router with exactly same devices for years.
Simply randomly every few days some devices stops working and only restart helps, sometimes both devices.

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

Posted: Wed May 05, 2021 8:54 am
by mducharme
It appears IPV6 connection tracking does not work on 7.5Beta5?
It works fine for me, but I am using the factory default MikroTik IPv6 firewall config and not the one from help.mikrotik.com that you pasted.

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

Posted: Wed May 05, 2021 10:58 am
by nostromog
I have a hAP ac^2 configured with a set of /queue/tree queues and I have been seeing panic reboots ever 3-6 hours of the router since I upgraded to 7.1beta5.

Once I did a
/queue/tree/disable [find]
I have not seen any more kernel failure reboots.

Waiting for next version that can do traffic shaping...

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

Posted: Wed May 05, 2021 6:32 pm
by nos1609
Image
Same on wAP R ac LTE6 Kit

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

Posted: Wed May 05, 2021 10:36 pm
by weswarren
Recently observed another pattern for wifi problem where random clients are not able to rejoin. Affects wifi1 and 3 on my audience. This is happening to me from beta 4 I think but initially wasn’t sure what is causing it. Over time more devices been misbehaving like that only leaving the router as possibility.
Export in quoted text.
This was never happening to me on any other router with exactly same devices for years.
Simply randomly every few days some devices stops working and only restart helps, sometimes both devices.
I have apparently the same problem on Chateau with any 7.1 versions: random wifi disconnects for clients between a few hours and a few days. The only solution was to go back to 7.0 beta 8, where wifi is stable. I wasn't able to find the initial version installed on the router (7.0 beta 6). Rant: I don't think is fair for Mikrotik to sell a product with development software, that can't be brought back to a stable version, without stating this explicitly.

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

Posted: Fri May 07, 2021 3:39 am
by tmcnulty1982
This is an old wAP. Does 132k Sector Writes Since Reboot in 26 days (see below) seem high to anyone else? This router is barely doing anything - maintaining an internet connection, a few wireless clients (2-3), and a single Wireguard tunnel. Logs aren't set up to go to flash or anything.

My main capsman controller + AP at home (6.47.9 (long-term)) has been up for twice as long and has only 30k Sector Writes Since Reboot.

Uptime 26d 03:42:22
Free Memory 23.7 MiB
Total Memory 64.0 MiB
CPU MIPS 74Kc V5.0
CPU Count 1
CPU Frequency 720 MHz
CPU Load 2 %
Free HDD Space 4200 KiB
Total HDD Size 16.0 MiB
Sector Writes Since Reboot 132 114
Total Sector Writes 163 416
Bad Blocks 0.0 %
Architecture Name mipsbe
Board Name wAP ac
Version 7.1beta5 (development)
Build Time Mar/16/2021 14:41:12
Factory Software 6.33.5

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

Posted: Fri May 07, 2021 10:11 am
by rextended

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

Posted: Fri May 07, 2021 5:51 pm
by carolynperry
Simply randomly every few days some devices stops working and only restart helps, sometimes both devices.

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

Posted: Sat May 08, 2021 2:05 am
by Rfulton
It appears IPV6 connection tracking does not work on 7.5Beta5?
It works fine for me, but I am using the factory default MikroTik IPv6 firewall config and not the one from help.mikrotik.com that you pasted.
Can you post the rules?

Ive seen 3 others post about ipv6 connection tracking being broken. Another one is in this exact same thread.

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

Posted: Sat May 08, 2021 6:11 am
by mducharme
Can you post the rules?

Ive seen 3 others post about ipv6 connection tracking being broken. Another one is in this exact same thread.
Hi, you can get the rules from your own device easily:
/system default-configuration print
Make sure your window is wide enough first or the ends of the lines will be cut off and a > put at the end of the line to show there is more. Once your window is wide enough, run the print command, and copy and paste the IPv6 firewall section to a text file. Double check to make sure that no lines are cut off before the end, and if it is all good, copy and paste into your live router.

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

Posted: Sat May 08, 2021 1:38 pm
by pe1chl
The problem is that those default routers only exist in the RouterOS for the consumer-oriented routers.
When you have e.g. CCR or CHR the default configuration is much much smaller and does not include things like firewall settings.

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

Posted: Sat May 08, 2021 6:43 pm
by Rfulton
Can you post the rules?

Ive seen 3 others post about ipv6 connection tracking being broken. Another one is in this exact same thread.
Hi, you can get the rules from your own device easily:
/system default-configuration print
Make sure your window is wide enough first or the ends of the lines will be cut off and a > put at the end of the line to show there is more. Once your window is wide enough, run the print command, and copy and paste the IPv6 firewall section to a text file. Double check to make sure that no lines are cut off before the end, and if it is all good, copy and paste into your live router.
;;; defconf: drop invalid
11 forward drop 9 360 127

Drop invalid is still dropping everything. My connection list is completely empty when trying to generate traffic outward. if i disable drop invalid, everything works but my connection list is still empty.

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

Posted: Sat May 08, 2021 7:16 pm
by Rfulton
My issue was resolved by disabling queues that target 0.0.0.0/0.

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

Posted: Sun May 09, 2021 1:32 pm
by anav
Hate to state the obvious we are only at 6.48, long way to go to a 7.0. Its a fictitious number anyway as they back port development into the 6 chain when possible.
7beta is just a development concept with a whole bunch of volunteer testers. :-)
I would guess they will go from 6.99 in about 5 years, to the next RoS which will be 8.0 ;-P

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

Posted: Sun May 09, 2021 2:02 pm
by memelchenkov
volunteer testers. :-)
volunteers choose their own destiny, deceived customers do not 😠 Show me idiots who want to test this alpha-quality piece of code by itself. NO, they sold it as release.

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

Posted: Sun May 09, 2021 3:16 pm
by anav
It seems you are disturbed that they sold products that depend on using a beta firmware. Seems justified but the folks that are affected are all those that jumped on the home wifi bandwagon of MT which many have been stating to avoid for some time now. So my sympathy factor for those with audience or hapac3 and anyone that buys any hapac or capac product for the wifi, is very very low.

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

Posted: Sun May 09, 2021 3:31 pm
by mkx
@anav, I'm still waiting for you to buy a couple of EAP6xxs and throw your existing EAP245s ... just throw them in azimuth around 58° real hard. Aim for my hand.

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

Posted: Sun May 09, 2021 3:44 pm
by memelchenkov
It seems you are disturbed that they sold products that depend on using a beta firmware. Seems justified but the folks that are affected are all those that jumped on the home wifi bandwagon of MT which many have been stating to avoid for some time now. So my sympathy factor for those with audience or hapac3 and anyone that buys any hapac or capac product for the wifi, is very very low.
I absolutely do not care about your sympathy factor, mister. Stop flooding.

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

Posted: Sun May 09, 2021 4:27 pm
by anav
@anav, I'm still waiting for you to buy a couple of EAP6xxs and throw your existing EAP245s ... just throw them in azimuth around 58° real hard. Aim for my hand.
Why, they are working quite well actually, stable expected speeds achieved one time setup no dfs issues, could go on and on......... LOL.
When I see a sale on the 620s I will get one as I dont like paying regular price, well except for the excellent MT routers!

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

Posted: Sun May 09, 2021 4:29 pm
by anav
It seems you are disturbed that they sold products that depend on using a beta firmware. Seems justified but the folks that are affected are all those that jumped on the home wifi bandwagon of MT which many have been stating to avoid for some time now. So my sympathy factor for those with audience or hapac3 and anyone that buys any hapac or capac product for the wifi, is very very low.
I absolutely do not care about your sympathy factor, mister. Stop flooding.
The only person to blame is yourself, as you failed in due diligence before purchasing.
Deceived no, careless yes!

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

Posted: Sun May 09, 2021 4:34 pm
by memelchenkov
It seems you are disturbed that they sold products that depend on using a beta firmware. Seems justified but the folks that are affected are all those that jumped on the home wifi bandwagon of MT which many have been stating to avoid for some time now. So my sympathy factor for those with audience or hapac3 and anyone that buys any hapac or capac product for the wifi, is very very low.
I absolutely do not care about your sympathy factor, mister. Stop flooding.
The only person to blame is yourself, as you failed in due diligence before purchasing.
Deceived no, careless yes!
Oh, so toxic words and victim blaming like you are from one of exUSSR countries. Are you an immigrant?

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

Posted: Sun May 09, 2021 5:51 pm
by mkx
Are you an immigrant?

No, not AFAIK. But in the troll mode (again after some quiet time LOL).

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

Posted: Sun May 09, 2021 5:54 pm
by memelchenkov
Are you an immigrant?

No, not AFAIK. But in the troll mode (again after some quiet time LOL).
Ahaha, OK OK :)

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

Posted: Sun May 09, 2021 9:33 pm
by anav
Finally we agree :-) Someone who does not take responsibility for their actions/decisions is not defined as a victim, thank you!, that definition is solely reserved for MT purchasers of new home wifi products! OR, and dont you like options!!! someone who thinks that MT staff sit around the table imagining the ways they screw customers....... Those Latvians are tricky devils LOL.
I think the Audience/Chateau/HAPAC3 makes a handsome paperweight!

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

Posted: Sun May 09, 2021 9:54 pm
by mducharme
I think the Audience makes a handsome paperweight!
My Audience is running pretty decently with v7 beta. I would like to try wifiwave2 on it, but need 4 address mode support for that, plus CAPsMAN support.

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

Posted: Sun May 09, 2021 10:38 pm
by sindy
need 4 address mode support for that, plus CAPsMAN support
Sorry for off-topic, but how do you make these two work together on any ROS release, without wifiwave2?

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

Posted: Mon May 10, 2021 12:11 am
by mducharme
Sorry for off-topic, but how do you make these two work together on any ROS release, without wifiwave2?
Can you clarify? I'm not exactly sure what you are asking.

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

Posted: Mon May 10, 2021 12:16 am
by sindy
You wrote you need the 4-(mac)-address mode and capsman to be supported on wifiwave2 in order to be able to test it. That implies to me that you normally use both these features simultaneously (i.e. a capsman-controlled AP in AP-bridge mode), which I thought was impossible. What am I missing?

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

Posted: Mon May 10, 2021 12:22 am
by mducharme
You wrote you need the 4-(mac)-address mode and capsman to be supported on wifiwave2 in order to be able to test it. That implies to me that you normally use both these features simultaneously (i.e. a capsman-controlled AP in AP-bridge mode), which I thought was impossible. What am I missing?
The Audience has three wireless interfaces - a 2.4ghz for user connections, a 5ghz for user connections, and a second 5ghz for backhaul. The Audience is at the other end of my home and uses wireless for backhaul, it isn't wired in. So I need 4 address mode support on the second 5ghz interface for bridging back to my main router, plus CAP support for the main 5ghz interface and the 2.4ghz interface. Currently, without wifiwave2, I have that second 5ghz interface excluded from CAP functionality so that I can use station-bridge on it, and have CAPsMAN managing the other two interfaces on the Audience.

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

Posted: Tue May 11, 2021 11:00 pm
by rpress
Are you an immigrant?

No, not AFAIK. But in the troll mode (again after some quiet time LOL).
Mikrotik is free to run this forum as they see fit, allowing this trolling behaviour as they do. But at least some of us think allowing this is wholly unprofessional.

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

Posted: Sat May 15, 2021 6:45 pm
by nannou9
It’s about time for next beta.
Let’s hope it improves wifi stability.

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

Posted: Sun May 16, 2021 6:18 am
by RoyT
Updated to v7.1beta5, reset to defaults. Getting 404 and connection reset errors. Traced it to the default masquerade rule not having an in interface set.

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

Posted: Sun May 16, 2021 12:24 pm
by pe1chl
The default masquerade rule should have "interface list" WAN and the WAN interface should be member of that interface list.
Probably you are familiar with old defaults where the masquerade rule has an explicit interface and that has been changed some time ago.

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

Posted: Wed May 19, 2021 11:12 am
by emils
New version 7.1beta6 has been released in development RouterOS channel:

viewtopic.php?f=1&t=175369