v7.1rc4 [development] is released!

[vaka]

Another OVPN - Problem:
Upgraded a Chateau LTE12 from 7.1Beta5 to 7.1rc3.
Same with 7.1rc4 !

Under PPP/Interface OVPN - Server Button and PPPoE Scan Button disappeard in Winbox AND Webfig !

ccr2004 - 7.1rc4. all buttons in place

[tpedko]

does not work socks 5 + auth-method=password

[winap]

No, you can’t make a backup.
regarding the “how buggy” It depends what you want to do, in the normal “home/office” use case, it should be fine. I did not have any issues with mine on both RB5009 and RB4011 when using rc4.

I’m using IPv4/IPv6 with firewall, OSPF, Wireguard and ZeroTier (testing) with no issues for now

Thank you for specification..it will be ok for me

[mhugo]

Please update https://help.mikrotik.com/docs/display/ROS/v7+Routing+Protocol+Status

Its still missing and needed for us to really test the correct things.

[Manfred]

Another OVPN - Problem:
Upgraded a Chateau LTE12 from 7.1Beta5 to 7.1rc3.
Same with 7.1rc4 !

Under PPP/Interface OVPN - Server Button and PPPoE Scan Button disappeard in Winbox AND Webfig !

ccr2004 - 7.1rc4. all buttons in place

Seems to be a problem with the Chateau LTE12 !
On RB2011 also all buttons are available !

[rextended]

…or simply the user disable the button on skin?..

[infabo]

Well, is there going to be a stable wifiwave2 package when 7.1 goes out of RC?

[SiB]

Next BUG, reported: SUP-61789
Ping for timeout with count=1 return nil instead of 0
Ping for ‘net unreachable’ with count=[1,2] return nil instead of 0
workaround: just use count=3 or more

[vfreex]

Hi,

I found 2 issues with v7.1rc4:

1. using igmp-snooping with frame-types breaks VLAN interfaces:
   With igmp-snooping enabled on bridge interface, setting frame-types=admit-only-untagged-and-priority-tagged or admit-only-vlan-tagged will block the access to VLAN interfaces on that bridge interface. Disabling igmp-snooping will unblock the VLAN interface.

2. High CPU load due to broadcast or unicast packets flooding to the bridge interface.
   I described this issue in detail in https://help.mikrotik.com/servicedesk/servicedesk/customer/portal/1/SUP-61649.

[infabo]

In rc4 I already experienced 2 complete device lockups. Happens after a few days uptime. The device did not auto-reboot nor did the watchdog generate an autosupout.rif nor any log entry. I thought that times are long behind me, but in this recent RC the instability has catched up again.

[infabo]

Another OVPN - Problem:
Upgraded a Chateau LTE12 from 7.1Beta5 to 7.1rc3.
Same with 7.1rc4 !

Under PPP/Interface OVPN - Server Button and PPPoE Scan Button disappeard in Winbox AND Webfig !

Chateau here and I have both buttons in Winbox and Webfig. As rextended already mentioned: maybe they are hidden in active design.

[jookraw]

In rc4 I already experienced 2 complete device lockups. Happens after a few days uptime. The device did not auto-reboot nor did the watchdog generate an autosupout.rif nor any log entry. I thought that times are long behind me, but in this recent RC the instability has catched up again.

Which hardware you have? Do you have l2mtu set bigger than the default (1592)?

[skylark]

IPv6 traffic doesn’t flow through the router when a Simple Queue is active. I setup a Simple Queue with target LAN Interface and Destination WAN interface - and queue type FQ_Codel. When the queue is active, IPv6 traffic doesn’t work, queue inactive - it works again. This problem isn’t new, also had it in 7.1rc3

And

IPv6 connection tracking with simple queue (cake and pcq) and queue tree is also still broken.

Please send us supout.rif files to the support@mikrotik.com
Simply configuring IPv6, queues, and dst/target interfaces, limitations work for us, so there must be some specific settings we are missing.

[ingus16]

Hi guys,
Did anyone else noticed that ntp server doesn’t work. Clients to stratum 0 works as expected ?

[elbob2002]

Not sure if this happened to anyone else but the 3 devices I had running 7.1RC4 stopped routing after 7 days uptime.

RB3011, 750GR3 and a CHR.

I could connect to each device on their management IP but even the devices themselves couldn’t ping other subnets they were each connected to.

They are running OSPF but static routes were also inaccessible. No crashes or supout recorded.

Rebooted each device and issue gone.

[mfrey]

IPv6 traffic doesn’t flow through the router when a Simple Queue is active. I setup a Simple Queue with target LAN Interface and Destination WAN interface - and queue type FQ_Codel. When the queue is active, IPv6 traffic doesn’t work, queue inactive - it works again. This problem isn’t new, also had it in 7.1rc3

And

IPv6 connection tracking with simple queue (cake and pcq) and queue tree is also still broken.

Please send us supout.rif files to the support@mikrotik.com
Simply configuring IPv6, queues, and dst/target interfaces, limitations work for us, so there must be some specific settings we are missing.

I just tried to get a minimal config working on a hex PoE (freshly reset without default) which produces this issue:

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/queue type
add cake-bandwidth=70.0Mbps kind=cake name=cake-download
add cake-bandwidth=10.0Mbps kind=cake name=cake-upload
/queue simple
add name=queue1 queue=cake-download/cake-upload target=ether1
/ipv6 dhcp-client
add add-default-route=yes interface=ether1 pool-name=inet-prefix request=\
    address,prefix
/ipv6 firewall filter
add action=accept chain=input connection-state=invalid,new log=yes log-prefix=\
    ipv6,invalid,new

That’s it. Nothing complex. When logging onto the device using Winbox MAC and pinging some random IPv6 internet host all incoming packets are new and invalid according to the log.

[woro]

I had 7.1rc4 on my RB4011 for some days now w/o stability issues.
Yesterday I installed

• zerotier
• user-manager
• container
  packages and since then the devices rebooted at least 2 times within 24 hours w/o a supout.

I haven’t done anything yet with the above packages but it seems to me that one of them is causing the crashes as before that was no issue at all.

[jult]

Most of us are more interested in when the stable v7 is released (with the newer cake/fq_codel supporting linux kernels), because honestly, cake is what everybody needs (now) and is waiting for.
And, not unimportant, many other big brands are already using it. So, users are fleeing towards those other brands because of that.

[huntermic]

Most of us are more interested in when the stable v7 is released (with the newer cake/fq_codel supporting linux kernels), because honestly, cake is what everybody needs (now) and is waiting for.
And, not unimportant, many other big brands are already using it. So, users are fleeing towards those other brands because of that.

This is funny, you just joined the forum but appear to know wat all people here want.
Trust me, cake/fq_codel is not that important for most people.

[mikegleasonjr]

Most of us are more interested in when the stable v7 is released (with the newer cake/fq_codel supporting linux kernels), because honestly, cake is what everybody needs (now) and is waiting for.
And, not unimportant, many other big brands are already using it. So, users are fleeing towards those other brands because of that.

Not only v7 is not stable, CAKE is not implemented fully at the moment. (When specifying a queue, you can’t tell it it will be ingress or egress and defaults to egress).

tc qdisc ... cake
       ...
       [ mpu N ]
       [ ingress | egress* ]   <----------
       (* marks defaults)

See https://man7.org/linux/man-pages/man8/tc-cake.8.html


I also opened SUP-59224 since rc3 if I recall correctly about that.