v7.1rc7 [development] is released!

emils · Fri Nov 26, 2021 11:08 am

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

What's new in 7.1rc7 (2021-Nov-25 16:35):

!) device-mode - added feature locking mechanism;
*) arp - limit total ARP table size based on installed RAM size;
*) bgp - fixed "nexthop-choice" selection;
*) bgp - fixed peer handling on point-to-point addresses;
*) bgp - ignore empty filter names on upgrade;
*) bgp - implemented BGP VPN configuration upgrade and other configuration upgrade fixes;
*) conntrack - limit total connection tracking table size based on installed RAM size;
*) crs3xx - fixed interface linking for some optical QSFP+ modules on CRS354 devices;
*) health - improved temperature reporting;
*) ipsec - fixed hardware acceleration support for ARM and ARM64 devices;
*) ipsec - fixed software fallback mode for AES-192 on IPQ4018/IPQ4019;
*) led - added "dark-mode" functionality control with Mode button for cAP XL ac;
*) lte - added "cell-monitor" support for Chateau 5G;
*) lte - improved LTE setting reporting to supout file;
*) ospf - fixed MD5 authentication with large packets;
*) ospf - fixed OSPFv3 interface configuration;
*) ospf - improved DB exchange speeds;
*) ospf - improved stability with large LS update packets;
*) route - fixed "Route Target" byte order;
*) route - fixed unreachable routed networks on VRFs;
*) route - fixed route rule upgrade;
*) route - fixed situation when routes with unequal distances got treated as ECMP routes;
*) route - improvements on VRF isolation;
*) route-filters - added "as-path" regexp testing tool;
*) route-filters - added "as-path-slow-legacy" to dsupport old style "as-path" filtering;
*) route-filters - fixed "as-path" bracket parsing and 4byte ASN usage;
*) routerboard - fixed "mode-button" functionality on devices that have such feature;
*) upgrade - improved major version upgrade process on hAP ac2 and cAP ac;
*) wifiwave2 - fixed enforcement of access list rules which only checks client signal strength for new connections;
*) wifiwave2 - removed non-functioning VLAN configuration parameters from access list;

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

mafiosa · Fri Nov 26, 2021 11:17 am

Is container package available?

emils · Fri Nov 26, 2021 11:19 am

Not yet. Still working on improvements.

pe1chl · Fri Nov 26, 2021 11:42 am

*) route - fixed route rule upgrade;

Does that include the /routing table section generation? Will existing badly converted config be auto-fixed?

mrz · Fri Nov 26, 2021 11:45 am

If config was converted once then no. If you have a backup from ROS v6 which was generated on the router that was never upgraded to v7. Then you can load backup and crossfig will perform new config upgrade.

pe1chl · Fri Nov 26, 2021 12:04 pm

If config was converted once then no. If you have a backup from ROS v6 which was generated on the router that was never upgraded to v7. Then you can load backup and crossfig will perform new config upgrade.

I hope you understand that when users have been helping you for a while by testing some rcs (rc5, rc6, now rc7) it is not really an option for them anymore to load a backup from v6, as that was made too long ago, and also a lot of work went into fine-tuning the configuration to run v7 in daily use.
The only thing I can realistically do now to cleanup config mistakes is export the config, edit it manually, and then reset the router and import that config.

So I presume that when I next do that (I intend to try it anyway to see if it fixes another issue) I can delete these lines?

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

msatter · Fri Nov 26, 2021 12:04 pm

Device-mode: https://help.mikrotik.com/docs/display/ROS/Device-mode

kamillo · Fri Nov 26, 2021 12:05 pm

Could you please update https://help.mikrotik.com/docs/display/ ... col+Status.

Thanks

msatter · Fri Nov 26, 2021 12:16 pm

What if Crossfig allowed to import a v6 RSC and write a v7 RSC file in files. Using backup files would require a passwod to be provided.

soheilsh · Fri Nov 26, 2021 12:31 pm

If config was converted once then no. If you have a backup from ROS v6 which was generated on the router that was never upgraded to v7. Then you can load backup and crossfig will perform new config upgrade.

please fix socks 5 problem
viewtopic.php?t=180440

aliclubb · Fri Nov 26, 2021 1:15 pm

I don't suppose you can give us a rough estimate on when the container package will once again be available?

mikegleasonjr · Fri Nov 26, 2021 1:38 pm

Unfortunately, we still can't define one of the parameters of a Cake queue when creating it: direction. Right now if we don't specify it, it defaults to egress.

It is clearly a bug since the parameter Autorate ingress is broken if ingress is not specifed.

See my post here: viewtopic.php?t=178341#p878504

See the available parameters here (last parameter): https://www.man7.org/linux/man-pages/ma ... l#SYNOPSIS

woland · Fri Nov 26, 2021 1:43 pm

Hi,

I´m also waiting eagerly for the container feature for the brand new RB5009 I will receive next week.

In the meantime: update of my HAP AC3 worked well from 6.49.
Thanks & regards!
Peter
Ps. we have the first snow in Vienna today so I grabbed 2 Socks this morning. 5 SOCKs would be an overkill!

Panbambaryla · Fri Nov 26, 2021 1:53 pm

Is proxy-arp on a bridge working back again?
What about IPSec/L2TP Road Warrior connection - does connection attempts stil reboots the CCR2004?

Fri Nov 26, 2021 2:19 pm

Unfortunately, we still can't define one of the parameters of a Cake queue when creating it: direction. Right now if we don't specify it, it defaults to egress.

It is clearly a bug since the parameter Autorate ingress is broken if ingress is not specifed.

See my post here: viewtopic.php?t=178341#p878504

See the available parameters here (last parameter): https://www.man7.org/linux/man-pages/ma ... l#SYNOPSIS

Thank you very much for your posts. We see them

Currently we are polishing v6 features into v7. Once v7 will be released, we will look closely into features and improvements for functions, that were introduced in v7.x

pe1chl · Fri Nov 26, 2021 2:47 pm

Currently we are polishing v6 features into v7. Once v7 will be released, we will look closely into features and improvements for functions, that were introduced in v7.x

Hopefully you will give priority to routing (e.g. BGP and also OSPF) in this, because there you removed the v6 features and introduced the v7 variant, but that is far from finished.
Lots of places are USING those routing features, and now have them in very unpolished state. I can sort of live with it on my home router but I certainly cannot update other routers in the network.

I fully understand those that want to have their CAKE and see it improved, but that is just a luxury food item compared to the core functionality of a router, routing and routing protocols.
And as it is now in v7.1rc7, BGP still logs silly things like:
12:36:25 route,bgp,info Connection closed
12:36:25 route,bgp,info Session *=0x3004c640

We need that improved. It should log WHICH session is closed, not a pointer value.
(this is only one example)

VitohA · Fri Nov 26, 2021 2:47 pm

Still the same: viewtopic.php?t=180153#p890291
Obviously that changelog doesn't contain these fixes but I hoped it was fixed.

leeratanak · Fri Nov 26, 2021 2:52 pm

Radius not working still error "Radius Server not responding"

bobaoapae · Fri Nov 26, 2021 3:05 pm

On ugprade RB760iGS from 6.49 to 7.1 my ipv6 stop working connection, i keep receiving valid ipv6 on router and on machines but traffic don't flow.. don't show any error log too, firewall it's ok too.

When i roolback to 6.49 ipv6 back to work again.

What i can do?

Znevna · Fri Nov 26, 2021 3:11 pm

[...]

You didn't check the routes: viewtopic.php?t=177800#p874200

bobaoapae · Fri Nov 26, 2021 3:23 pm

On ugprade RB760iGS from 6.49 to 7.1 my ipv6 stop working connection, i keep receiving valid ipv6 on router and on machines but traffic don't flow.. don't show any error log too, firewall it's ok too.

When i roolback to 6.49 ipv6 back to work again.

What i can do?

Already figured out what is happening... wrong dynamic route was being created after upgrade, manually remove all routes and start dhcp client ipv6 again fixed the problem

pe1chl · Fri Nov 26, 2021 3:29 pm

Already figured out what is happening... wrong dynamic route was being created after upgrade, manually remove all routes and start dhcp client ipv6 again fixed the problem

Over here, maybe you also, we have the situation where internet is delivered over PPPoE and IPv6 prefixes are delivered via DHCPv6.
There are a lot of guides copied around "how to get this working in RouterOS" where the DCHPv6 client is configured with "Add default route".
That works, but it is WRONG. The default route is added by the PPPoE client already, it should not be added by the DHCPv6 client.
In RouterOS v6 it worked, you got 2 default routes but the one added by DHCPv6 was "inactive". In RouterOS v7 they both become active and IPv6 does not work.

osc86 · Fri Nov 26, 2021 3:29 pm

Thanks for fixing ipsec on arm/arm64.
Still a problem in rc7, when a peer is disabled, the corresponding policies are not marked invalid.
The result is, affected policies are still installed in kernel, and blocking traffic between src and dst networks defined in these policies.

theosoft · Fri Nov 26, 2021 4:09 pm

Repartioning still not working.
Also waiting for container...

regards

Jotne · Fri Nov 26, 2021 4:32 pm

Still CPU (or other) problems on SXT 5HPnD.
Export of config on SXT 5HPnD takes for ever.
Export of config on SXT 5HPnD r2 take a few seconds.
r2 seems to be much more responsive in all conifg.

Both on 7.1.rc7

Chupaka · Fri Nov 26, 2021 5:05 pm

Changelog is still empty in WinBox...

nithinkumar2000 · Fri Nov 26, 2021 5:08 pm

Please add Delegated IPv6 Prifix Parameter in PPP Radius Accounting.......................

markmcn · Fri Nov 26, 2021 5:09 pm

Has anyone seen any more details on

*) ipsec - fixed hardware acceleration support for ARM and ARM64 devices

Like what the specific issue was?

Jotne · Fri Nov 26, 2021 5:37 pm

Changelog is still empty in WinBox...

Can confirm this as well.

osc86 · Fri Nov 26, 2021 5:43 pm

@markmcn, traffic wasn't encrypted / decrypted properly, so no communication between peers was possible. in-state-protocol-errors counter went up. I had this problem on a CCR2004-16G-2S+, I'm glad it's solved with rc7. Spent hours debugging it in rc6, but couldn't find a configuration error. Now I know why.

eworm · Fri Nov 26, 2021 5:55 pm

Trying to make IPv6 work with masquerading... Is that broken?
I see the reply on external interface, but not on internal one. Instead the count for invalid packets in input chain increases...

osc86 · Fri Nov 26, 2021 6:01 pm

IPv6 masquerading is working fine here

felixka · Fri Nov 26, 2021 6:22 pm

Is AES GCM not being hardware offloaded for IPSec on RB5009 a bug or is this simply not supported? AES CBC is offloaded just fine.

levicki · Fri Nov 26, 2021 7:38 pm

@sergejs

Audience owner here, running RouterOS 7.1rc6. Only packages I have installed are routeros and wifiwave2 on it.

After upgrading to 7.1rc7 I have this message in the log right after rebooting and after interfaces are brought up:

error while running customized default configuration script: bad command name wireless (line 977 column 25)

I have no scripts on the device -- it is used as a dumb AP with two eth ports bonded and a bridge created over that with Wi-Fi.

Any idea what that might mean? Is it safe to ignore?

mducharme · Fri Nov 26, 2021 7:42 pm

Can confirm this as well.

Strange.. I am seeing the changelog no problem in Winbox on my RB4011.

msatter · Fri Nov 26, 2021 7:48 pm

I see the changelog also...however only longterm shows longterm. Stable and testing shows 7rc7.

This on my 4011 and I updated today by placing the update file in files.

mducharme · Fri Nov 26, 2021 8:11 pm

I see the changelog also...however only longterm shows longterm. Stable and testing shows 7rc7.

I do not think this is a bug. This is the result of the change made in 6.49.1 where there was an "upgrade" channel added. You do not see v7 in the development channel anymore on v6 and can only upgrade by going to the "upgrade" channel. After upgrading, everything except long term is in the new v7 channel stream. I think this was done due to complaints from some users who have set up auto upgrade scripts to upgrade to every stable immediately after release that they would go up to v7 unexpectedly, and I would reiterate to such people that such auto upgrade systems are a very bad idea and very dangerous potentially. I guess MikroTik was worried about the number of people who might have this ill-advised setup and would get angry with the v7 upgrade. So we now essentially have new "development-v7", "testing-v7" and "stable-v7" channels in v7, and "development-v6", "testing-v6" and "stable-v6" in v6, but without the -v6 and -v7 modifier. The names of the channels therefore match in v6 and v7, but they are not the same channels anymore.

Jotne · Fri Nov 26, 2021 8:23 pm

Strange.. I am seeing the changelog no problem in Winbox on my RB4011.

Both of the test boxes do now show change log, after the upgrade.
One of them takes som time before it shows up. So it may be a problem that all is slow and I need to wait longer than normal to see the log.

mkx · Fri Nov 26, 2021 8:48 pm

Here ya go!

Won't help ... wrong power plug type (and probably voltage and frequency).

roswitina · Fri Nov 26, 2021 9:16 pm

I use RB4011 with ROS 6.49.1. I cant upgrade to ROS 7rc7. In the Log i found:.. Not enough disc space.
The Upgrade from 6.49.1 to 7beta5 to 7rc7 works.

pe1chl · Fri Nov 26, 2021 9:31 pm

error while running customized default configuration script: bad command name wireless (line 977 column 25)

I think in earlier releases this particular error message was output when you had changed the name of the wireless interface from the default.
(e.g. renamed wlan1 into wlan-2.4)

That should have been fixed in a later release, but it could be that it returned. Did you rename the wireless interface?

atakacs · Sat Nov 27, 2021 12:51 am

Was rc7 pulled ?

I could download earlier today but not now (2300 GMT) ?

msatter · Sat Nov 27, 2021 1:53 am

Was rc7 pulled ?

I could download earlier today but not now (2300 GMT) ?

For which router you tried it? Just downloaded the ARM version without any problem.

https://mikrotik.com/download

Grant · Sat Nov 27, 2021 7:48 am

Hello,
Hap ac2 low speed on wi-fi if fasttrack is disable
This is only for v7.1

DaniGarcia · Sat Nov 27, 2021 8:06 am

It stuck on "calculating download size..." when trying to update from any ROS 6.

Jotne · Sat Nov 27, 2021 8:48 am

v7.1rc7 download for ll types of boxes found here:
https://mikrotik.com/download

elbob2002 · Sat Nov 27, 2021 10:01 am

It stuck on "calculating download size..." when trying to update from any ROS 6.

You need to remove any extra packages you have installed first.

atakacs · Sat Nov 27, 2021 11:20 am

Do you see anything that should not me here ?

[xxx@mkt-sx-00] /system package> print
Flags: X - disabled 
 #   NAME                                 VERSION                                 SCHEDULED              
 0   routeros-tile                        6.49.1                                                         
 1   system                               6.49.1                                                         
 2   ipv6                                 6.49.1                                                         
 3   wireless                             6.49.1                                                         
 4   hotspot                              6.49.1                                                         
 5   mpls                                 6.49.1                                                         
 6   routing                              6.49.1                                                         
 7   ppp                                  6.49.1                                                         
 8   dhcp                                 6.49.1                                                         
 9   security                             6.49.1                                                         
10   advanced-tools                       6.49.1                                                         
11   multicast                            6.49.1

erlinden · Sat Nov 27, 2021 11:38 am

On my RB4011 I see RX Drops on all its ports. On the Hex S I manage I don't see any. Both running RC7. What might cause these drops?

msatter · Sat Nov 27, 2021 11:56 am

On my RB4011 I see RX Drops on all its ports. On the Hex S I manage I don't see any. Both running RC7. What might cause these drops?

I don't see that on my 4011. The SFP port has always a high RX-drop so I won't look at that one.

I have also upgraded the firmware and so had an extra reboot.

Cha0s · Sat Nov 27, 2021 11:57 am

Has anyone checked if /routing/bgp/advertisements is implemented on this release?

msatter · Sat Nov 27, 2021 12:01 pm

Has anyone checked if /routing/bgp/advertisements is implemented on this release?

/routing/bgp/advertisements

Red stands in Terminal for not implemented.

Jotne · Sat Nov 27, 2021 12:02 pm

Here are what I do see under bgp

/routing/bgp/
connection  session  template  vpn  export

no advertisements

pe1chl · Sat Nov 27, 2021 12:10 pm

Here are what I do see under bgp

There is a lot of work to be done on BGP! The possibilities to debug and track it are really lacking.
The "prefix count" in connections is always zero, there is no field tracking the uptime or last disconnect of a connection, and when a connection is interrupted it is logged with a meaningless "pointer value" instead of the connection name.
As it is now, it is impossible to keep an eye of the BGP connections and I think BGP is unusable in this state.
(remember in v6 we had wishes that it would be improved, and now looking back it was much better in v6. SNMP also still not available...)

mafiosa · Sat Nov 27, 2021 12:27 pm

Here are what I do see under bgp
There is a lot of work to be done on BGP! The possibilities to debug and track it are really lacking.
The "prefix count" in connections is always zero, there is no field tracking the uptime or last disconnect of a connection, and when a connection is interrupted it is logged with a meaningless "pointer value" instead of the connection name.
As it is now, it is impossible to keep an eye of the BGP connections and I think BGP is unusable in this state.
(remember in v6 we had wishes that it would be improved, and now looking back it was much better in v6. SNMP also still not available...)

I agree. Even bgp filters is not properly implemented. No proper guide. Use of Output.network is not clear.

erlinden · Sat Nov 27, 2021 12:49 pm

I have also upgraded the firmware and so had an extra reboot.

Standard procedure for me (as well?). Don't see it on my switches (running 6.49.1) either.
It looks like all ports (including connected hue) are reporting. Doesn't make sense...

pe1chl · Sat Nov 27, 2021 12:52 pm

If config was converted once then no. If you have a backup from ROS v6 which was generated on the router that was never upgraded to v7. Then you can load backup and crossfig will perform new config upgrade.

I have instead exported my config in v7.1rc6, removed the main and "" fib from the export, then upgraded the router to 7.1rc7, reset config and imported the export again.
During this procedure I found that in the /export file the /routing bgp template section is exported before the /routing table section.
This is obviously wrong as the bgp template refers to an alternative routing table which has not yet been created at that time.
After moving the /routing table section up in the export file it was imported correctly, and now without those two extra tables.

pe1chl · Sat Nov 27, 2021 1:00 pm

I agree. Even bgp filters is not properly implemented. No proper guide. Use of Output.network is not clear.

Well the filters are improving over time and so is the documentation on them. After discussing in the previous release topic I was able to make my filters working.
The config syntax for BGP is quite different from the usual RouterOS syntax. When I first saw it I expected that everything would be modeled after this, but as it is now it looks like BGP is the only subsystem using it. It requires a lot of familiarization with no apparent benefit. Maybe we will understand later.
The output.network is the replacement for "BGP networks". Instead of /routing bgp networks you put your BGP networks in an address list (/ip firewall address-list) and put the name of that addresslist in output.network. Advantage is that you can have a different output.network address list per BGP template (= instance).

We will have to re-learn everything. But at least we would have wanted it to be a more finished work, after all those years of promises.

pe1chl · Sat Nov 27, 2021 1:25 pm

*) bgp - fixed peer handling on point-to-point addresses;

Don't know if it was referring to this bug, but that is still going wrong here:
When a BGP connection has an interface name in local.address= the entry is marked invalid and does not work. When an IP address is put there it works.
But in winbox, when an interface name is typed in that box the name turns from red to blue at the moment a valid interface name is typed, so that apparently is still recognized.
(in v6 this was a dropdown box where it normally showed the interface names, but instead you could also enter an IP address there)

Halfeez92 · Sat Nov 27, 2021 3:52 pm

DHCP6-PD still not working. IPV6 DHCP client still searching

mukky · Sat Nov 27, 2021 3:57 pm

SMB features not working at 1 TB SATA HDD,
look at my post here: viewtopic.php?t=116210
post # 6

Amm0 · Sat Nov 27, 2021 4:28 pm

!) device-mode - added feature locking mechanism;

This works in my limited testing. But noticed "quickset" isn't a choice, is that intentional or an oversight?

Also, I guess it would have expected it to be removed from winbox UI & smartphone app if a feature was disabled – seems easier than creating a v7 skin for it. Although I like CLI still having all the options, even if device-mode "locks" a feature as a script import wouldn't care & the comment tells you its "locked" so you'd know.

hel · Sat Nov 27, 2021 5:11 pm

Upgrading hAP Lite from 7.1b5 to 7.1b7 solves the high CPU problem when winbox connects.
It goes to 100% only for about 1-4 seconds after connection now. Before upgrade I waited 2-15 minutes before CPU load goes down every time I connect using winbox.

mducharme · Sat Nov 27, 2021 5:54 pm

This works in my limited testing. But noticed "quickset" isn't a choice, is that intentional or an oversight?

The feature locking mechanism seems to be designed for features that could be used to hack into the device or aid in the spread of malware and the Meris botnet. All of the features that they have included in it are features that either are being actively used right now by the Meris botnet and malware, or have a strong likelihood to be used by the Meris botnet or malware in the future (like the new container feature). That is why they require the button press, so that hackers cannot just turn features back on to help spread malware once they gain access to the router, as the user would have to physically press a button on the router. Quickset doesn't really have anything to do with malware or the Meris botnet - at least I do not see any way that hackers could use quickset to help spread more malware. Enabling and disabling quickset therefore should not require a button press, and makes more sense through a skin.

ufm · Sat Nov 27, 2021 7:18 pm

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

Is ZeroTier still only available for ARM?

Amm0 · Sat Nov 27, 2021 7:40 pm

This works in my limited testing. But noticed "quickset" isn't a choice, is that intentional or an oversight?
Enabling and disabling quickset therefore should not require a button press, and makes more sense through a skin.

I ask since in general good admin practices are enough for Meris – it's future attack vectors to worry about. While quickset doesn't seem like one, I'd argue somewhat it provides a good basis for future ones: it's one-stop shop for getting an Mikrotik to a "base state" to inject other code. e.g. just one HTTP call to webfig/quickset can radically reconfigure a router – so the attacking bot just needs to try quickset and since the config is known, the injected config after a malicious quickset for the desired attack can be small and static.

Now certainly more likely DoS "vector": a decent admin familiar with networking, but not Mikrotik specifically, thinking it's safe to change one variable on the QuickSet page, say password, without potential downtime-inducing side-effects. We actually do a lot of work adapt our custom configs so QuickSet's "config detect" resolve to a reasonable "profile", so hitting "OK" in QuickSet won't blow away all/most of our custom config, but it's tedious and not always possible.

At some point, I'd like to declare the device "not QuickSet-able" globally – both to reduce attack surfaces and human error. And, some configs just aren't design for automatic configuration – so some global lock-out of any of the automatic configuration options across the smartphone, webfig, and winbox interfaces be helpful.

Yes, somewhat solvable with a skin, but that's a per-user thing that could be forgotten. Forgotten admin tasks lead to Meris.

pe1chl · Sat Nov 27, 2021 8:33 pm

DHCP6-PD still not working. IPV6 DHCP client still searching

Works for me! What is the problem you are encountering? Please show relevant config.

mducharme · Sat Nov 27, 2021 9:59 pm

Yes, somewhat solvable with a skin, but that's a per-user thing that could be forgotten. Forgotten admin tasks lead to Meris.

There is a default skin, skins/default.json, that is used by default for all users. You can use the branding package creator in MikroTik "My Account" to make a branding package that will deploy it to the devices, and when you netinstall the device with your custom config you can include the branding package in the netinstall to put the json file in there, that way it wont' be forgotten.

As for smartphones, I suspect they will be adding support for the same skins to the smartphone interface so that if quickset is blocked in the skin, "Quick Setup" will be blocked in the phone app.

fragtion · Sat Nov 27, 2021 10:08 pm

Is the crossfig update likely to address the sporadic config loss problem some people were experiencing on previous builds? I've been experiencing that on my hAP ac lite and possibly other units in 7.1rc6

Also anything about the bgp-networks bug where it needs to be disabled & enabled to propagate routes ?

Tnx

msatter · Sat Nov 27, 2021 10:16 pm

Do you have by any chance a: *) upgrade - improved major version upgrade process on hAP ac2 and cAP ac;

Crossfig has been improved as you can read in the beginning of this tread.

fragtion · Sat Nov 27, 2021 10:26 pm

Do you have by any chance a: *) upgrade - improved major version upgrade process on hAP ac2 and cAP ac;

Crossfig has been improved as you can read in the beginning of this tread.

Me? Problem was occurring on hAP ac lite specifically. Also, not specifically on update process, but randomly some time after the upgrade.

I read the changelog, but I thought "crossfig" means config migrating/crossing between major versions. What is the meaning of crossfig anyway?

I'll upgrade to 7.1rc7, monitor the situation and post if it happens to me again also with this version

Amm0 · Sat Nov 27, 2021 10:29 pm

Yes, somewhat solvable with a skin, but that's a per-user thing that could be forgotten. Forgotten admin tasks lead to Meris.
There is a default skin, skins/default.json, that is used by default for all users.

But that the same logic applies to socks, web proxy – put it in the skin to disable it & done. I view "device-mode" more like the replacement for "package".

Did not mean to pick on just QuickSet – although disabling it is common request on the forums. Different example, In ROS v6, I always disable the IPv6 package – we don't use it – and it requires at least a reboot to enable the package in ROS v6. Now in v7, it's been relegated to a checkbox waiting to be enabled – no reboot required. That's a reduction of security options in v7. Given IPv6 is often ignored or poorly understand, another config setting just waiting to get exploited.

Although you're totally right – seems like an "after action" from Meris – just saying doing more before the next attack isn't a bad approach. No one know future attacks, a smaller code footprint is better.

OlofL · Sat Nov 27, 2021 10:33 pm

When fasttrack for ipv6?

msatter · Sat Nov 27, 2021 10:42 pm

Crossfig converts your 6.x to 7.x and maybe even back to 6.x

As you could read at the beginning of this tread you can load your 6.x backup and Crossfig will convert it to the current version of 7.1rc7.

mducharme · Sat Nov 27, 2021 10:43 pm

I view "device-mode" more like the replacement for "package".

It is not a replacement for "package". While it is true that hotspot was a package, socks proxy was never a package by itself, tool fetch was not a package, etc.

Now in v7, it's been relegated to a checkbox waiting to be enabled – no reboot required.

Yes, and I am super happy about this change. IPv6 is enabled by default now. In v6 we had to jump through hoops before in our configuration routines to get IPv6 up and running. Now it is so much easier, we can remove some of the complexity of the router setup.

What you might be missing here is there is a default IPv6 firewall, like the default IPv4 one, that protects the router quite well. Even if IPv6 is left enabled, the router is secure due to the default IPv6 firewall. Even if there was no firewall, the router will not get a global address automatically, someone would have to add one manually. Without a firewall, yes you could log into it with a link local, but you would have to have a layer 2 connection to the device to do so. You make it sound like having IPv6 enabled means instantly it will be open to the planet, which isn't the case. There is really no need to disable IPv6, it just means more work when you actually do want to go back and deploy it.

albertothepunisher · Sat Nov 27, 2021 11:11 pm

Error, when creating templates for users in Webskins part, it does not apply the changes. You create a style and mark the options you want to view, once you go in and out with the user created to have the style, the same options come out completely. Version test 7.1rc7

mrz · Sat Nov 27, 2021 11:23 pm

I agree. Even bgp filters is not properly implemented. No proper guide. Use of Output.network is not clear.

Could you be more specific what exactly is not properly implemented and what is not clear from routing filter manual?
https://help.mikrotik.com/docs/pages/vi ... d=74678285

Amm0 · Sat Nov 27, 2021 11:35 pm

Now in v7, it's been relegated to a checkbox waiting to be enabled – no reboot required.
Yes, and I am super happy about this change. IPv6 is enabled by default now.

I actually think IPv6 being enabled by default is a good thing – it's come a long way from v6. Not suggesting changes to the default-configurations here.

What I'm talking about reducing attack surfaces in more secure environments. And, for OEM/ISV/VAR cases, to reduce the support footprint too. If I know in a particular use case IPv6 will never come up, then why worry it could used in some attack regardless if the firewall is "very good". We used "packages" for that in v6, as best we could. Since it's a brand new feature, my feedback simple:

I like it – putting some options "out-of-reach of children" is useful – just have a more "lockable" services.
Current support services seems more random: Why are L2TP or ZeroTier in device-mode, while IPv6, wireguard or openvpn are not? Basically the more unused features that I can disable in ROS, the better for security, for little investment time/money.

JardinEspanol · Sun Nov 28, 2021 1:18 am

DNS Servers value, in DHCP Server section, does not get updated, when you change Local Network settings using Quick Set.

I changed default from *.88.* to *.91.*. But in DHCP Servers section, the DNS Servers value stays 192.168.88.1. This caused me to spend few hours figuring out why I can ping to 1.1.1.1 but no www.google.com or any other normal ping destinations I test with.

Quick Set.PNG

DHCP Server.PNG

msatter · Sun Nov 28, 2021 2:06 am

I don't agree that the DNS server should set to the same subnet when you change that. I am surprised that on the LTE page DNS is not shown and editable. That is the better way.

There are a few other servers that are defined in DHCP, but DNS is extremely important and parts of the router will not function without a working DNS.

I myself don't use quick Set, only for accessing Check fo updates. I tried it a few times and had to correct later manually what went wrong. I rather see it go than stay in 7.x .

Amm0 · Sun Nov 28, 2021 3:18 am

DNS Servers value, in DHCP Server section, does not get updated, when you change Local Network settings using Quick Set.

I changed default from *.88.* to *.91.*. But in DHCP Servers section, the DNS Servers value stays 192.168.88.1.

As I said, I use QuickSet for some use cases, and actually ran into it but didn't report it. (We use LTE stuff, sometimes people have static IPs for equipment, so adapting the Mikrotik LAN subnet to match using QuickSet is a pretty easy solution for a non-IT person to do in field)

This is a v7-specific QuickSet bug – they used to rely on NOT setting a DNS server in the IP>DHCP Server>Network it creates (at least for LTE profile) – that means inherit from IP>DNS servers. Since with the right APN, the LTE interface should get DHCP servers and the Interface>LTE>APN>default says to "Use DNS" by default. So in v6, it didn't have to set the DNS, since by default it just copy them from IP>DNS's one (which come the LTE interface). And, DNS just "passthrough" so you it didn't need any DNS settings in QuickSet. This generally worked if the use case matches the QuickSet profile & upstream network did "typical" things.

In v7 at somepoint, QuickSet changed to preferring using the router as the DNS server for the LAN, and also setting "Allow Remote Requests" in IP>DNS (in v6, I recall this preferences changes through versions). But since they decided to explicitly set the DNS server in IP>DHCP Server>Networks, instead of leaving blank as in v6. While "clearer", you're right QuickSet needs to update it. It's also bad about updating the DHCP address ranges too, but different issue.

AshuGite · Sun Nov 28, 2021 8:08 am

High CPU Usage on 7.1rc7 on CCR2004-16G and Rb5009 routing, management and unclassified. almost negligible load on network
MikroTik support #[SUP-67196]

mducharme · Sun Nov 28, 2021 8:26 am

High CPU Usage on 7.1rc7 on CCR2004-16G and Rb5009 routing, management and unclassified. almost negligible load on network

You may be cherry-picking a single unidentified interface in those screenshots. Please show the overall interfaces list instead, and the overall config for the device. You might be using a feature that places a very heavy load on the device.

Note: I am not suggesting that there is not an issue here, there could very well be an issue. However, to my knowledge, other users of those devices have not experienced those problems, so it is likely configuration related.

AshuGite · Sun Nov 28, 2021 10:15 am

High CPU Usage on 7.1rc7 on CCR2004-16G and Rb5009 routing, management and unclassified. almost negligible load on network
You may be cherry-picking a single unidentified interface in those screenshots. Please show the overall interfaces list instead, and the overall config for the device. You might be using a feature that places a very heavy load on the device.

Note: I am not suggesting that there is not an issue here, there could very well be an issue. However, to my knowledge, other users of those devices have not experienced those problems, so it is likely configuration related.

i suspect the issue is with OSPF as this high usage is for arond 5-10 minutes and then it gets normal.
simillar setup runs on my other routers including CCR1009, RB4011 and CCR2004-12S but such behaviour never happend i guess the culprit here is ROS7.

pe1chl · Sun Nov 28, 2021 12:16 pm

I agree. Even bgp filters is not properly implemented. No proper guide. Use of Output.network is not clear.
Could you be more specific what exactly is not properly implemented and what is not clear from routing filter manual?
https://help.mikrotik.com/docs/pages/vi ... d=74678285

Well, to fill that in: at least what is not properly implemented is the winbox interface to the route filters. The panel should be like that of a firewall chain, i.e. the rules are shown in sequence as they are in the ruleset and you can move them up or down. As it is now the rules are shown sorted by name, which is completely wrong. Now we have to use commandline for something that could "easily" be done from the winbox screen with proper panel layout.
Also, the whole new filter concept is a departure from the original RouterOS concept of having everything configurable with a user interface that shows you the available options to select from in one glance. We now have to learn a new "scripting language" like when writing a script. I don't know if that was a clever idea, and if it even was required. For the typical route filters I am using it certainly wasn't. Maybe for others, it was.
(maybe we can still hope for a sort of "filter rule compiler" in winbox that will generate the appropriate rule at least in cases where there is only a set of items to be matched with AND operator, as it was in v6)

The routing filter manual is too basic, it lacks sufficient examples and relies on user's understanding of the concept and the way of defining such things as a syntax description. That issue was avoided in the v6 version of routing filters because they you could just read along the options and enable what you like. It would be best when every definition at least had some practical example of usage.

In general BGP looks very unpolished in v7, as I already mentioned in comments in the v5 and v6 release topics. None of those items have been resolved yet.
This already starts with basic stuff like "how are events logged". That should have been part of the design from the beginning, every programmer knows the impact of proper error handling and event logging on the design of the code. It is usually not something you can "do later when you have the time", it should be incorporated into the structure of the code.

mafiosa · Sun Nov 28, 2021 1:11 pm

I agree. Even bgp filters is not properly implemented. No proper guide. Use of Output.network is not clear.
Could you be more specific what exactly is not properly implemented and what is not clear from routing filter manual?
https://help.mikrotik.com/docs/pages/vi ... d=74678285

I am attaching the support.rif and the export of config. The networks defined under output.network is announced but suddenly disappeared. Now I cannot get that to be announced. If possible tell me what is wrong in the config?

nithinkumar2000 · Sun Nov 28, 2021 5:52 pm

I agree. Even bgp filters is not properly implemented. No proper guide. Use of Output.network is not clear.
Could you be more specific what exactly is not properly implemented and what is not clear from routing filter manual?
https://help.mikrotik.com/docs/pages/vi ... d=74678285

I too Agree with this... There should be Proper Documentation with Examples...

mrz · Sun Nov 28, 2021 8:44 pm

What configuration examples you would require? Documentation then can be updated with required examples if that helps, but syntax is not a rocket science that you have to learn for months, its literally one if with operators and action.

mafiosa · Sun Nov 28, 2021 9:04 pm

What configuration examples you would require? Documentation then can be updated with required examples if that helps, but syntax is not a rocket science that you have to learn for months, its literally one if with operators and action.

I am announcing a network using output.filter but it stops announcing all of a sudden in iBGP. /routing/filter/rule print doesn't show the rule.

sindy · Sun Nov 28, 2021 9:04 pm

syntax is not a rocket science that you have to learn for months, its literally one if with operators and action.

What I always liked most about RouterOS is the systematic way of presenting the configuration, as compared to common Linux distributions where every package has its own configuration file format. If you say the structure of the BGP filter rules is still just "operators and action", why did it have to become different from the syntax of firewall rules, routing rules, ipsec policies etc.? Will that get unified to one of the forms or the other in future versions?

Cha0s · Sun Nov 28, 2021 10:34 pm

Could you be more specific what exactly is not properly implemented and what is not clear from routing filter manual?
https://help.mikrotik.com/docs/pages/vi ... d=74678285
Well, to fill that in: at least what is not properly implemented is the winbox interface to the route filters. The panel should be like that of a firewall chain, i.e. the rules are shown in sequence as they are in the ruleset and you can move them up or down. As it is now the rules are shown sorted by name, which is completely wrong. Now we have to use commandline for something that could "easily" be done from the winbox screen with proper panel layout.
Also, the whole new filter concept is a departure from the original RouterOS concept of having everything configurable with a user interface that shows you the available options to select from in one glance. We now have to learn a new "scripting language" like when writing a script. I don't know if that was a clever idea, and if it even was required. For the typical route filters I am using it certainly wasn't. Maybe for others, it was.
(maybe we can still hope for a sort of "filter rule compiler" in winbox that will generate the appropriate rule at least in cases where there is only a set of items to be matched with AND operator, as it was in v6)

The routing filter manual is too basic, it lacks sufficient examples and relies on user's understanding of the concept and the way of defining such things as a syntax description. That issue was avoided in the v6 version of routing filters because they you could just read along the options and enable what you like. It would be best when every definition at least had some practical example of usage.

In general BGP looks very unpolished in v7, as I already mentioned in comments in the v5 and v6 release topics. None of those items have been resolved yet.
This already starts with basic stuff like "how are events logged". That should have been part of the design from the beginning, every programmer knows the impact of proper error handling and event logging on the design of the code. It is usually not something you can "do later when you have the time", it should be incorporated into the structure of the code.

++

I am very disappointed with the direction that BGP and filters have taken in v7.
We have been waiting for many many years to get all those fixes, new features and performance improvements on v7 BGP, and it stands right now, to me it is useless.
Not only it's nowhere near production ready, with key features simply missing, but we have to learn a completely new way of doing things without any immediate benefit. Yes we can get a single rule to do many stuff at once to make it compute things faster, compared to how it was done on v6, but at what cost?
You cannot search, sort, filter, or anything that all other RouterOS features support in both Winbox and CLI.

What's also sad is that MikroTik doesn't seem to want to hear our feedback, and they are bound to continue with this half-baked, functionality-reduced, implementation.

And since it's not rocket-science, why not completely ditch winbox and webfig? And convert the CLI to a bunch of "if then else" rules. That would be great, right?

pe1chl · Sun Nov 28, 2021 11:28 pm

What configuration examples you would require? Documentation then can be updated with required examples if that helps, but syntax is not a rocket science that you have to learn for months, its literally one if with operators and action.

I agree with the comment that sindy made above. If it is hardly changed, then why did the syntax have to change?
I understand the benefit of the new matching for AS path, but that could have been done within the old syntax of filters.
The new syntax has the advantage that you now can have any boolean combination of filter matching rules, but who is ever using that?
In the filters here I match on things like community value or AS path element only, and even the latter would only require "AS number at the end" or "AS number occurs somewhere". No need for all those fancy matches that are now possible. Maybe that is different for some other users?

W.r.t. the examples: by now I have figured it out, both because the documentation has been improved after I first commented about it (when some details were simply not documented at all), and because I have a programming background and know how these language syntax definitions normally work.
But I feel for those users that do not have that background, the ones that also do not understand how to use scripting. Before, they could easily use the user interface to match some item by using the corresponding keyword or even use the winbox gui, now they have to understand a programming language.
And because some of the characters used are special in the configuration syntax, there also are unpleasant surprises that are different between command mode and winbox.
For example this rule in my filters:

add chain=hamnet-in disabled=no rule="if (dst == 0.0.0.0/0 && bgp-as-path [[:gw-44-137:]]\$) { accept; }"

In the old config this used to be:

add action=accept bgp-as-path="4220406100\$" chain=hamnet-in prefix=0.0.0.0/0

and it could be built by simply entering some fields in winbox. Without knowing that $ is special and has to be written as \$.
Now, we have to consult a documentation page to get the correct syntax. And $ is shown as $ so you need to know it has to be \$ in commandline syntax. Of course that is written elsewhere, but it is frustrating to hit this when trying to master the filter syntax.
(and I had to use a routing filter num-set to work around a bug in v7.1rc6, cost me quite some time to find that)
I think normally one would have only a list of matches all AND'ed together, so that language was not really necessary.

At least the documentation could have shown usage examples for every type of match. It cost me quite some time to extract from that documentation that e.g. to compare dst with an address you need an operator like == but to match bgp-as-path with a path regex there is no operator like ~ as it would be in the script language. And in case of the dst I was helped with the conversion by crossfig of existing rules, with bgp-as-path there was no such help as those rules were simply dropped during the conversion.

That kind of details is of course not obvious when you have followed the development from inside and have a developer on your side to ask questions, but please imagine how it is for someone for who all this is new.

Amm0 · Sun Nov 28, 2021 11:43 pm

syntax is not a rocket science that you have to learn for months, its literally one if with operators and action.
What I always liked most about RouterOS is the systematic way of presenting the configuration, as compared to common Linux distributions where every package has its own configuration file format.

Totally agree. Mikrotik's strength is provides "common schema" for the various network RFCs. I deal with their subpar Wi-Fi support solely because it I like the network has a "common" management interface/control, and scriptable.

But I keep think: why didn't Mikrotik just re-use the existing CLI script-style:

:if condition="" do=""

with condition being optional seems like a more ROS-way of handling it.

We don't regularly use BGP... But every time this BGP filter topic comes up, I have say the BGP filters syntax looks so out of place in ROS. I sorta get the need to move beyond "just" attributes: In ROS, you can't combine formal logic operators (AND, OR, NOT) in "one line" of config – in some case this might improve readability. e.g. reading the firewall config takes some getting used...

And, "wifiwave2" seems to go in a different direction: there CAPsMAN's "dot sub-attributes" and "attribute inheritance" like configuration.ssid="MyWiFi" are used, but this sub-attribute style syntax is nowhere else.

Sure the syntax will be more regularized over time. But commenting more that all of these "specialty" configs do increase the difficultly in using/teaching/mastering ROS. If you regularly deal with BGP filters, the new syntax does look more "readable" than trying to sort out the logic from a series of firewall-like rules.

Will that get unified to one of the forms or the other in future versions?

I do wish sometimes Mikrotik do more of "Here's where we're going with this...", especially with these "configuration philosophy" things that I think are one of the biggest strength of ROS.

Like on this one:
Do they see the firewall filters/NAT one day moving to or supporting a similar "script-based" approach?
Or, since they do look like Wireshark filters, is the same OR+AND logic going to make it to Tool>Sniffer or elsewhere?
On the "BGP filter language", why not extend the existing script language, instead of inventing something new?

Mikrotik generally has a good "Why" on things, but boy it's not always easy to see (certainly reasonable people may differ, but getting their POV might help).

benkreuter · Mon Nov 29, 2021 1:52 am

Is there any plan or timeline for implementing BFD for OSPF in v7? I cannot upgrade until it is implemented or a reasonable alternative is available (for various reasons iBGP does not cut it, and I cannot use proprietary protocols), and to be honest I am shocked that a release candidate is missing such a basic feature (especially given all the effort put into not-so-basic features). Why is BFD on the back burner -- broken for BGP and unavailable for any other routing protocol?

I have also noticed that adjacencies will break very frequently between v7 and v6 if BFD is enabled on the v6 side; adjacencies between v7 and a linux box running Bird do not seem to have this problem, so it may be an ROSv6 bug. As a result if BFD is not implemented for OSPF in v7 it will be difficult to run a mixed network, which will make the entire process of upgrading a pain even for a very small number of devices.

mducharme · Mon Nov 29, 2021 2:47 am

Is the v7 routing protocol status page going to be updated?

mducharme · Mon Nov 29, 2021 3:24 am

Mikrotik generally has a good "Why" on things, but boy it's not always easy to see (certainly reasonable people may differ, but getting their POV might help).

I suspect the why is likely to do with performance. Probably the ability to have "or" and "else" conditions with a standard if statement allows people to create the same filters with fewer rules, and fewer rules to be processed means faster loading and less CPU. If you wanted to do "or" and "else" with the old method you would have to have additional rules, which means more looping, which translates to higher CPU usage and longer load times for initial processing and in the case of big route flaps.

Znevna · Mon Nov 29, 2021 9:57 am

In 7.1rc5 this was added:
*) winbox - added "netmap" action to IPv6 NAT rules;
But "to-address" and "to-ports" fields don't show up, tested in WinBox and WebFig.
Thank you!

Znevna · Mon Nov 29, 2021 10:16 am

High CPU Usage on 7.1rc7 on CCR2004-16G and Rb5009 routing, management and unclassified. almost negligible load on network

On RB5009, if you have a script that polls data from /bridge/host or even have that window open in WinBox, that causes some management and unclassified CPU spikes (3 spikes in a row every few seconds for every bridge/host/print or export).
Support confirmed that this is "current expected behaviour for RB5009 and CCR2004-16G-2S+" and that they will see if this can be improved in future RouterOS releases.
On my RB5009 keeping bridge/hosts open in WinBox causes about 30-38% usage on a random core.
For now I'd suggest to not poll that data very often.

Mon Nov 29, 2021 10:20 am

device-mode This works in my limited testing. But noticed "quickset" isn't a choice, is that intentional or an oversight?

What do you mean? You want to forbid the QuickSet feature for home users? That's a little counter intuitive, no?

msatter · Mon Nov 29, 2021 10:41 am

In this case quickset did not show a setting that is essential for the workings of a router. How does a 'Home user' solve it then not knowing how to find the cause of why domains don't work in address-lists and why can't he/she browse the internet.

More and more is put behind walls, like the downloaded update files. You can find those files, but it takes a study.

pe1chl · Mon Nov 29, 2021 10:42 am

device-mode This works in my limited testing. But noticed "quickset" isn't a choice, is that intentional or an oversight?
What do you mean? You want to forbid the QuickSet feature for home users? That's a little counter intuitive, no?

Yes, but we have been asking for a long time for some feature to allow disabling QuickSet, and now that this mechanism for enabling/disabling some features is introduced for other reasons, maybe it could be used for this.
But a separate package for QuickSet or some checkmark in global router settings would be fine in this case as well, as it is not so important to guard this against external attackers.

rpingar · Mon Nov 29, 2021 10:58 am

on x86 with mellanox and intel cards we are reporting a very strange behavior after 24/48hours of operation.
In this condition the router is not able to formward correcly the udp, some tcp sessions are broken.

The router is perfectly reachble in this status.

Opened the ticket providing the supout: [SUP-67221]

Ros

mrz · Mon Nov 29, 2021 11:26 am

Yes, but we have been asking for a long time for some feature to allow disabling QuickSet, and now that this mechanism for enabling/disabling some features is introduced for other reasons, maybe it could be used for this.
But a separate package for QuickSet or some checkmark in global router settings would be fine in this case as well, as it is not so important to guard this against external attackers.

If you want to hide config from the user then skins should be used.

Mon Nov 29, 2021 11:34 am

In this case quickset did not show a setting that is essential for the workings of a router.

which setting? how can we fix something, if you are so vague?

Znevna · Mon Nov 29, 2021 11:42 am

Probably related to this: viewtopic.php?p=893820#p893660
And more details here: viewtopic.php?p=893820#p893669
As in, if the subnet changes the DNS settings in DHCP/Networks are left intact(?) which leads to a nonfunctional network.
In the past DNS in DHCP/Networks was left blank.
I've tried to report QuickSet quirks in the past too, but a bunch of friendly `enterprise on a boat` forum users went all "AAA DON'T USE QUICKSET QUICKSET BAD!!!" .. and .. well, I didn't report them anymore.

osc86 · Mon Nov 29, 2021 11:44 am

I just noticed that networks defined in wireguard peer "AllowedAddress" are not dynamically added to the routing table.
Wireguard for linux, windows and mac (except for 0.0.0.0/0) does this automatically. Please consider changing this.

Jotne · Mon Nov 29, 2021 12:31 pm

That is just as its written in the manual
https://help.mikrotik.com/docs/display/ROS/WireGuard

You also need to add an IP address to the WireGuard interface, so there will be some manual work in anyway.
But do agree that a route could be added autoatically.

Znevna · Mon Nov 29, 2021 12:45 pm

WireGuard, the protocol, doesn't add any routes. The helpers on each platform automagically do that.
In RouterOS this classifies as a new feature, so make a request

Until then, follow the RouterOS docs mentioned and add the IP Addresses to the wireguard interfaces manually, and specify the routes also manually.
Or script it if you like.

msatter · Mon Nov 29, 2021 12:50 pm

In this case quickset did not show a setting that is essential for the workings of a router.
which setting? how can we fix something, if you are so vague?

I wrote that in the next sentence in that posting that just you qouted.

mducharme · Mon Nov 29, 2021 12:51 pm

What do you mean? You want to forbid the QuickSet feature for home users? That's a little counter intuitive, no?

Yes, but skins can be used to do this.

One example that we have is we purposely have both a DHCP client and PPPoE client on ether1. The DHCP client gets a private management IP for the router and installs a default route with distance 2 but doesn't actually get the customer online, and the PPPoE client gets a public IP that gets the user online and installs a default route with distance 1. If the user goes into the QuickSet window it gets confused by this configuration and all they have to do is click OK or apply in that window and it deletes their PPPoE client in favour of the DHCP client (which again is used for management only) and they lose Internet access and will call us to complain.

I do not necessarily expect MikroTik to change this behavior of QuickSet as it can be disabled with skins, but the skins functionality needs to be extended to the mobile client.

Mon Nov 29, 2021 1:21 pm

You also need to add an IP address to the WireGuard interface, so there will be some manual work in anyway.

Anav most certainly will disagree with you on that

IP address on Wireguard interface seems NOT to be needed for all cases but it makes it a lot more clear to do it anyhow.
I also do it every time. And yes, it is stated in the documentation as well to do so.

pe1chl · Mon Nov 29, 2021 1:43 pm

Yes, but we have been asking for a long time for some feature to allow disabling QuickSet, and now that this mechanism for enabling/disabling some features is introduced for other reasons, maybe it could be used for this.
But a separate package for QuickSet or some checkmark in global router settings would be fine in this case as well, as it is not so important to guard this against external attackers.
If you want to hide config from the user then skins should be used.

Unfortunately the skin configuration does not fully work. E.g. when it is used to remove the "apply configuration" and "reset configuration" buttons on the quickset page, they still work in winbox.
Also, even in webfig there remains an OK button that cannot be removed. Only fully removing QuickSet works in webfig, but it does not work in winbox.
I think it would be more helpful to have a setting that disallows changes made via QuickSet. It can still show the QuickSet page but everything would be read-only.

mducharme · Mon Nov 29, 2021 2:02 pm

Only fully removing QuickSet works in webfig, but it does not work in winbox.

I’m not sure what you mean here. I used a skin to remove Quickset from webfig and it disappears in winbox too so it is not possible to use quickset in winbox. You are experiencing different behaviour?

Mon Nov 29, 2021 3:06 pm

Winbox has Skin support for a while now. Some people don't know that yet.

pe1chl · Mon Nov 29, 2021 3:19 pm

Only fully removing QuickSet works in webfig, but it does not work in winbox.
I’m not sure what you mean here. I used a skin to remove Quickset from webfig and it disappears in winbox too so it is not possible to use quickset in winbox. You are experiencing different behaviour?

I tested it with 6.49.1 but there it does not work. I had in mind that it was also added in v6, but apparently not.
Still, even in v7.1rc7 it does not appear to be possible to remove just the "OK" and "Apply" buttons, you can hide the entire QuickSet but not make it read-only.

Halfeez92 · Mon Nov 29, 2021 3:23 pm

DHCP6-PD still not working. IPV6 DHCP client still searching
Works for me! What is the problem you are encountering? Please show relevant config.

I am using PPPoE to get connected to Internet. Still I cannot get IPv6 address from my ISP through IPv6 DHCP Client. It works on v6 though.

huntermic · Mon Nov 29, 2021 3:32 pm

Works for me! What is the problem you are encountering? Please show relevant config.
I am using PPPoE to get connected to Internet. Still I cannot get IPv6 address from my ISP through IPv6 DHCP Client. It works on v6 though.

same issue here

pe1chl · Mon Nov 29, 2021 3:50 pm

Have you read and acted upon reply #22 viewtopic.php?p=893377#p893377 above?
IPv6 over PPPoE in combination with DHCP client not working in v7 is due to a common misconfiguration, almost all "guides how to set this up" get it wrong!

huntermic · Mon Nov 29, 2021 3:54 pm

Have you read and acted upon reply #22 viewtopic.php?p=893377#p893377 above?
IPv6 over PPPoE in combination with DHCP client not working in v7 is due to a common misconfiguration, almost all "guides how to set this up" get it wrong!

Yes, but it did not solve the issue

Amm0 · Mon Nov 29, 2021 4:53 pm

device-mode This works in my limited testing. But noticed "quickset" isn't a choice, is that intentional or an oversight?
What do you mean? You want to forbid the QuickSet feature for home users? That's a little counter intuitive, no?

QuickSet works great, if your use case, matches the profile – in "home" device-mode, QuickSet makes perfect sense. Same case for the "LTE" profile, it's pretty useful to quickly get those types of devices up. I actually wish they let you with the branding kit change the profiles QuickSet uses (or disable just some QuickSet profiles so they can't be selected), which might avoid the need to disable/hide QuickSet.

Now the "enterprise", QuickSet is more problematic sometimes. Even if you start with QuickSet, once you do some types of configuration, using QuickSet again after could cause real problems to a previously working config. This may not intuitive to a non-Mikrotik expert doing maintenance on ROS – they want to change an SSID, see it in QuickSet, but have no idea that it could apply configuration beyond that. These "QuickSet side-effects" are not easy to predict, or obvious, when it looks you're "changing only one thing". QuickSet does sometime have bugs: there is one in this forum, that when he changed his IP address in QuickSet, it didn't update the DHCP Server Network's DNS server to the one he set in QuickSet.

QuickSet is super-use sometimes – disastrous others.

Anyway, my feature request here was simply that the new "device-mode" should include more things to "lock out", QuickSet being one example – this be especially useful in OEM/ISV/VAR use-cases. In V6, you could "disable more" than in V7 is I think my point. And the "device-lock", if a security measure, is lacking other potential attack surfaces like IPv6 (and I claim QuickSet). Since SOCKS can be disabled in config, just like IPv6, so in theory "device-lock" isn't needed... But ROS credentials being compromised somehow is what device-lock seems be designed around – the less someone can configure the better.

So be good to see "device-lock" applied more universally and above the level of a skin. While a skin can proximate fine grain access control, especially now that it's in winbox, it's not itself a security mechanism (and especially true since the skin isn't "respected" by the smartphone app, which still how skin-disabled things).

"device-lock" looks like a step in the right direction, but just saying it could be improved. I should know better than bring up poor QuickSet... although I was looking for it in the new "device-lock" to see if possible to disable, when I read the release note here about "device-lock"...

pe1chl · Mon Nov 29, 2021 4:55 pm

Have you read and acted upon reply #22 viewtopic.php?p=893377#p893377 above?
IPv6 over PPPoE in combination with DHCP client not working in v7 is due to a common misconfiguration, almost all "guides how to set this up" get it wrong!
Yes, but it did not solve the issue

For me it works OK after removing the "Add default route" in IPv6 DHCP client!

pe1chl · Mon Nov 29, 2021 5:00 pm

This may not intuitive to a non-Mikrotik expert doing maintenance on ROS – they want to change an SSID, see it in QuickSet, but have no idea that it could apply configuration beyond that.

THAT is the big problem, something that MikroTik still does not seem to understand.
I happened before that I configured a router completely OK (these are routers that do not operate in the typical "internet router with NAT" mode but have direct routing, BGP, tunnels etc).
The user gets his new router configured completely working, and at some point they are interested to see how that all works, they login to the router, get the QuickSet page as first page, they see something there that they want to change (e.g. the router identity), change only that and hit Apply, and then the whole router config is f*cked up because some standard template is applied again.

That is why I want to disable changes made via QuickSet. That is not the same as "hiding" it.

solaoxo · Mon Nov 29, 2021 5:13 pm

ROS7 is now a test version, why not upgrade the kernel to 5.10 LTS version?

Amm0 · Mon Nov 29, 2021 5:42 pm

This may not intuitive to a non-Mikrotik expert doing maintenance on ROS – they want to change an SSID, see it in QuickSet, but have no idea that it could apply configuration beyond that.
THAT is the big problem, something that MikroTik still does not seem to understand.

That is why I want to disable changes made via QuickSet. That is not the same as "hiding" it.

Why I was hoping the new /system/device-lock be the simple way of doing that... QuickSet also is still not a separate policy option for the user groups to disable either.

On QuickSet specifically, if device-lock isn't going to be the answer... I guess the more generic feature request is I want to allow a ROS user to change most things (write, sensitive, etc.), just not do "OK" in quickset (and not allow "Quick Configuration" in app) – one way or another.

Did notice a "rest-api" permission when I just check user groups in v7.1rc7 – not sure what that's about...

infabo · Mon Nov 29, 2021 6:10 pm

THAT is the big problem, something that MikroTik still does not seem to understand.

They must defend QuickSet. It's "their baby".

msatter · Mon Nov 29, 2021 6:29 pm

Quickset can have it's use, but limit it then to only unconfigured or only with the default config.

If something is changed then you have to confirm twice that wan't use the Quickset config to be applied. In general it seems also to be wise to even request this for unconfigured/default routers.

In between confirms, you get a warning that you are about to apply a new/different config that it could break the current workings of the router.

infabo · Mon Nov 29, 2021 6:40 pm

The Mikrotik android app has the same mindset. When you connect to a device you see the wifi-interfaces listed on the dashboard. When I tap for example wlan2, it lists connected devices and some base info. But when I want to leave the screen, it always asks me if I want to save my changes! I did not change anything. But I am damn sure, if I say yes - it would re-configure some settings on my wlan2. That kind of "quickset-magic" is spinkled over Winbox, Webfig and even the app. The only trustworthy interface is the CLI. No magic involved there.

Amm0 · Mon Nov 29, 2021 7:04 pm

Did notice a "rest-api" permission when I just check user groups in v7.1rc7 – not sure what that's about...

To answer my own question, this is documented (and in release notes for v7.1beta4):
https://help.mikrotik.com/docs/display/ROS/REST+API

Jotne · Mon Nov 29, 2021 10:54 pm

Socks in RouterOS broken since v7.1rc4, please fix.
viewtopic.php?t=180440

@MT since this is broken do reply to the guy with the support ticket that yes we see it and will see what we do about it.
Its frustrating not get any response. Should at least get a support ticket.

mhugo · Tue Nov 30, 2021 1:40 am

We complain (me too) a lot here, so for let me break my own habit!

Good work on the OSPF in this release - We had some oddities and got 7.2b17 and now 7.1rc7 - guessing this was part of the big LS update bug and possibly speed. Routers became unstable when neighbour next to them came online. All gone in our test with 16 2004s and some 317s.

Now we just need show show recieved and sent prefixed plus prefix count in BGP to expand the deployment size.

/M

mwp · Tue Nov 30, 2021 3:00 am

I've got several vlans set up each with their own IPv6 /64 prefix. The bridge has a different /64. ND is enabled. RAs from vlan1 keep making their way onto the bridge, which is bad news. This didn't happen in the previous RC.

Tue Nov 30, 2021 8:23 am

Please do not look at device-mode as a means to disable features. It is only a means to protect the router. It disables dangerous or advanced settings the home user does not understand, or that could be used in malicious ways by other people, unbeknownst to the user.

I understand that some of you think of quickset as a dangerous feature, but we will not add it as a dangerous feature to the device-mode list.

mducharme · Tue Nov 30, 2021 9:14 am

We really need at least working VPLS that does not crash the router. Currently setting up two hardware routers with static routing and MPLS, the VPLS tunnel will come up but crash both routers when traffic starts to pass or within a minute or two after the tunnel coming up even without traffic being passed. This is the same as the previous RC's. I am starting to worry that v7.1 stable will come out without working VPLS. My coworker can't even test the v7.1beta at all yet at home because of this, as his home setup terminates VPLS tunnels on almost every device.

buset1974 · Tue Nov 30, 2021 6:05 pm

/routing/bgp/cache/ did not show prefix counts properly on winbox

Amm0 · Tue Nov 30, 2021 11:42 pm

Please do not look at device-mode as a means to disable features. It is only a means to protect the router.

Setting aside the much maligned QuickSet

... it's beside my question on Mikrotik "best practices" for using device-mode.

Wouldn't you want to protect the router in the "enterprise" case too?

Say after a network is designed/tested, but before going live/production – doing a "lock out" be an easy way to add another layer of security. Essentially 2FA done on a feature-basis. But if I hear you right, it seems you discourage using this feature, outside the "home" use cases? I saw using device-lock as a potential V7 "best practice"...that I hoped one day be expanded with a broader definition of "dangerous". I seem to be wrong, just not sure why.

IMO, the root cause of Meris wasn't the "dangerous services", it was mainly password-related. At some level, that isn't Mikrotik's fault. But, the typical solution to compromised passwords is using 2FA and/or X509 for admin access – that's not likely anytime soon, I'd imagine. So, this new "device-mode" feature added here seemed like a good "stopgap":

If a password was compromised somehow, device-mode limit the possible configuration in unused functionality, that could be exploited in new ways beyond Meris. It's hard to predict what vectors a future attack may take. And, imagine there is a lot of new code/drivers/etc. in V7. With any future/successful password attack, more "locked features" be better, than less. Even if QuickSet isn't one.

Just sharing my thoughts – certainly not attacking Mikrotik. I persist since y'all make some great devices for industrial/IoT use cases. But those don't all fit so neatly inside "enterprise" or "home" category. Once integrated into into a system/environment, the ROS features needed are generally very well known. This feature looked like a dirt simple way to add a layer of security, especially since you can't remove packages as in V6, nor provide 2FA/X509 client certs for winbox/REST/API/etc access...

PapsGrey · Wed Dec 01, 2021 11:06 am

I just got RB5009 and I want to use vrf route-target import/export but looks like that is not ready yet on the v7.
the RB5009 came with the v7 RouterOS out of the box, Is it possible to downgrade to RouterOS v6?

nescafe2002 · Wed Dec 01, 2021 11:58 am

What's new in 7.1rc7 (2021-Nov-25 16:35):
*) ipsec - fixed hardware acceleration support for ARM and ARM64 devices;

Not sure what is fixed, but my RDP sessions to Windows 2012 R2-instances are still dropping out about every minute.

RDCMan_DYG87BsyBf.png

This has been the case since v7 with multiple endpoints (to MT and UBNT endpoints). V6 does not have this issue.

mrz · Wed Dec 01, 2021 12:06 pm

I just got RB5009 and I want to use vrf route-target import/export but looks like that is not ready yet on the v7.
the RB5009 came with the v7 RouterOS out of the box, Is it possible to downgrade to RouterOS v6?

Import/export RTs are now part of the BGP configuration.

Znevna · Wed Dec 01, 2021 1:56 pm

What's new in 7.1rc7 (2021-Nov-25 16:35):
*) ipsec - fixed hardware acceleration support for ARM and ARM64 devices;
Not sure what is fixed, but my RDP sessions to Windows 2012 R2-instances are still dropping out about every minute.
This has been the case since v7 with multiple endpoints[...]

Probably related to this: viewtopic.php?t=180675#p893400
And ipsec hardware acceleration for arm and arm64 was added in 7.1rc5 and if you've experienced issues with older builds(?) also, your issue is very less likely to be related to hardware acceleration since it was all done in software up to that point.
And I have a tunnel currently working fine since some time now on arm64 (RB5009) with 7.1rc7, other end is arm 6.47.10 (hAP ac2). No drops.

RB5009 v7.1rc7 IKEv2 aes-cbc 256.PNG

Probably worth debugging the issue a little more on your end.

Kindis · Wed Dec 01, 2021 2:50 pm

What's new in 7.1rc7 (2021-Nov-25 16:35):
*) ipsec - fixed hardware acceleration support for ARM and ARM64 devices;
Not sure what is fixed, but my RDP sessions to Windows 2012 R2-instances are still dropping out about every minute.

RDCMan_DYG87BsyBf.png

This has been the case since v7 with multiple endpoints (to MT and UBNT endpoints). V6 does not have this issue.

I'm willing to bet that this is Windows Auto-tuning going bananas. Turn this of on server level. We turn this of via policy as it do not work well over VPN.
https://www.thewindowsclub.com/window-a ... windows-10
From the site!
To check the status of Auto-Tuning feature on your system, in an elevated command prompt windows, type the following and hit Enter:
netsh interface tcp show global
If you see ‘normal’ written against Receive Window Auto-Tuning Level, it means that the feature is enabled and it is working fine.
To disable Windows AutoTuning, run the following command:
netsh int tcp set global autotuninglevel=disabled
To enable Windows AutoTuning, run the following command:
netsh int tcp set global autotuninglevel=normal

PapsGrey · Wed Dec 01, 2021 3:05 pm

I just got RB5009 and I want to use vrf route-target import/export but looks like that is not ready yet on the v7.
the RB5009 came with the v7 RouterOS out of the box, Is it possible to downgrade to RouterOS v6?
Import/export RTs are now part of the BGP configuration.

I have checked the BGP configuration. I see its a little different from the v6 but I still can't find how to configure
the route-targets. Please can you assist me on the how to.

mrz · Wed Dec 01, 2021 3:16 pm

Look at /routing/bgp/vpn menu:
https://help.mikrotik.com/docs/pages/vi ... ng/bgp/vpn

Amm0 · Wed Dec 01, 2021 5:03 pm

Wanted to use /routing/filter to set distance and check-gateway on DHCP Client injected routed. The filter rules have do this in V6, but can't make it work in v7rc7.

Pretty sure it me, but not sure why this doesn't work using the new rule syntax:

/routing filter rule add chain=dynamic-in disabled=no rule="if (distance==1) { set gw-check icmp; accept }"

And seems like I have a "dynamic-in" chain:

/routing/filter> chain/print 
Flags: I - inactive; D - dynamic 
 0  D name="dynamic-in"

But it's not changing the "check-gateway" as shown /ip/route. Tried with and without the "accept". Also tried using "check-gateway" just in case it was a bug in the docs... Although it pretty confusing to using "gw-check", as said in the docs, to set a property named "check-gateway"). In V6, the tab completion allows me to know if attributes were "correct"... but obviously you can't "hit tab" in the rule= part of "routing filter rules" to fill in the right name, so very hard to which name right...so tried both in a few different combos. Nothing seems to change the DHCP Client's dynamicly-created default routes settings.

mrz · Wed Dec 01, 2021 5:05 pm

There is no built-in connected-in or dynamic-in chains in ROS v7.

Amm0 · Wed Dec 01, 2021 5:15 pm

There is no built-in connected-in or dynamic-in chains in ROS v7.

Fair enough, using the filter rules was kinda weird for this in V6.

But, what's the workaround for V7 to set distance on DHCP client route? Didn't try crossfig to see what happens, would that convert this?

We use the dynamic-in filter rule in our V6 configs, so when then upgrade, that could be very problematic since the routing order may change after upgrade...

pe1chl · Wed Dec 01, 2021 7:03 pm

You should closely watch your filter rules after upgrade anyway. They are converted to a completely different syntax, and we do not know if the converter can handle all possible cases.
(I did my conversion under v7.1rc5 and it was a mess, many rules were deleted without any trace. I would think the least they could do is convert them into a comment)
I'll try what happens with v7.1rc7, on my other router.

mrz · Wed Dec 01, 2021 8:06 pm

The converter wasn't finished yet in rc5. RC7 should convert all the filters and if some parameter cannot be converted, the comment is added and all the rules in the chain with an error becomes inactive.

mducharme · Wed Dec 01, 2021 8:53 pm

I noticed that the v7 Routing Protocol Status has apparently been updated with the feature status in v7.1 stable.

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

Implying a stable release may be only days away now.

pe1chl · Wed Dec 01, 2021 9:06 pm

I noticed that the v7 Routing Protocol Status has apparently been updated with the feature status in v7.1 stable.

Well it has mainly been deletions of info... actually it was nice to see the feature status of the previous version(s) so you could easily see what has improved and can be tested again.
Now there isn't even a column for v7.1rc7 anymore so we cannot know what the feature status is right now (is likely the same as already shown).

mducharme · Wed Dec 01, 2021 9:15 pm

Now there isn't even a column for v7.1rc7 anymore so we cannot know what the feature status is right now (is likely the same as already shown).

Confluence tracks the page history, so at least you can have a look at the old page with v7.1rc6:

https://help.mikrotik.com/docs/pages/vi ... d=97779899

msatter · Wed Dec 01, 2021 9:43 pm

Maybe now Mikrotik van start with device specific fixed already in V6. Like th RB4011 not able to maintain a MTU of 1500 on a PPPoE connection through the SPF interface. It now reaches a MTU 1492.

jookraw · Wed Dec 01, 2021 10:37 pm

Maybe now Mikrotik van start with device specific fixed already in V6. Like th RB4011 not able to maintain a MTU of 1500 on a PPPoE connection through the SPF interface. It now reaches a MTU 1492.

My RB4011 have no problem on PPPoE with MTU 1540 when using the SFP+ port.
I use a router-in-a-stick configuration, as the switch on the RB4011 is useless

Znevna · Wed Dec 01, 2021 10:42 pm

Why is it useless?

pe1chl · Wed Dec 01, 2021 10:51 pm

... in fact the switch in the 4011 is the rare exception in MikroTik routers that can actually switch VLANs while configured as a bridge...

msatter · Wed Dec 01, 2021 11:31 pm

Maybe now Mikrotik van start with device specific fixed already in V6. Like th RB4011 not able to maintain a MTU of 1500 on a PPPoE connection through the SPF interface. It now reaches a MTU 1492.
My RB4011 have no problem on PPPoE with MTU 1540 when using the SFP+ port.
I use a router-in-a-stick configuration, as the switch on the RB4011 is useless

Strange because it is stated that PPPoE is max 1500:

https://www.juniper.net/documentation/u ... rview.html

The header uses six bytes and the ID two. Then the MTU behind the PPPoE should be 1508. I have to use VLAN and that adds 4 bytes and the SPF sets at 1598 or so.

My 4011 is also only doing the connection plus VPN. What are your setting for over 1500? Mine drops after a few seconds from 1500 to 1492.

pe1chl · Wed Dec 01, 2021 11:42 pm

I have 1500 byte MTU on a 4011 with PPPoE connection running over a VLAN on ether1.
ether1 has MTU 1592, the VLAN has MTU 1588, the PPPoE is configured with MTU 1500, and remains at that.
The SFP+ has MTU 1598 so should be able to do that as well.

Remember not all ISPs support it! The fact you can configure it on the router does not mean it will work, as the ISP may force MTU 1492 anyway.

msatter · Wed Dec 01, 2021 11:54 pm

I have 1500 byte MTU on a 4011 with PPPoE connection running over a VLAN on ether1.
ether1 has MTU 1592, the VLAN has MTU 1588, the PPPoE is configured with MTU 1500, and remains at that.
The SFP+ has MTU 1598 so should be able to do that as well.

Remember not all ISPs support it! The fact you can configure it on the router does not mean it will work, as the ISP may force MTU 1492 anyway.

If I use an ether port then it works but then I have to put the NTU in the fiber path. In V6 it was fixed. Before the fix I had to restart the SPF after fours seconds to upgrade to a MTU of 1500. That trick does not work anymore in V7.

ppp-max-payload=1514
<mru 1500>
And switching back:
<data len=1492>

Znevna · Thu Dec 02, 2021 12:12 am

data len 1492 is normal in mikrotik logs for the lcp echo request & reply with a rfc4638 compliant pppoe.
That's also what I see in my logs.
ppp-max-payload is 1500 though.
And resulting mtu/mru is 1500.

nescafe2002 · Thu Dec 02, 2021 12:33 am

Probably worth debugging the issue a little more on your end.

I'm willing to bet that this is Windows Auto-tuning going bananas. Turn this of on server level. We turn this of via policy as it do not work well over VPN.
https://www.thewindowsclub.com/window-a ... windows-10

Thank you for your replies. I know the issue needs more investigation from my end, as it is application specific (Windows 2016 does not have this issue, just Windows 2012 R2). The auto-tuning parameter did not help (unless it requires a reboot, but in my experience netsh is activated immediately). Thanks for your efforts.

Amm0 · Thu Dec 02, 2021 3:28 am

In testing /interface/detect-internet with r7.1rc7, I noticed it creates a DHCP client automatically. This was a surprise to me that "Detect Internet" added a persisted DHCP client, with an un-configurable "default-route-distance=1" – as such, it takes over as default route when during Internet Detect's process. Maybe it did this V6, but our dynamic-in filter rules would caught the distance and prevent a DHCP client from setting a route at distance=1, so I wouldn't have noticed.

Now, the DHCP client created by "Detect Internet" does have a comment with a clue what's happening ";;; internet detect":

/ip/dhcp-client/print
Flags: X, I, D - DYNAMIC
Columns: INTERFACE, USE-PEER-DNS, ADD-DEFAULT-ROUTE, STATUS, ADDRESS
#   INTERFACE         USE-PEER-DNS  ADD  STATUS  ADDRESS          
0 X vlan-internet-in  no            no                            
;;; internet detect
1 D vlan-internet-in  yes           yes  bound   10.11.12.13

This DHCP client seems to persist, until you set internet-interface-list="none". The interface is a VLAN that does goes to a DMZ-type network. While that VLAN interface does have DHCP available from a different host, I didn't expect Detect Internet to turn into Use Internet from DHCP on this particular interface.

Maybe this correct behavior. But not what's document. The "Help" docs states for WAN (which is a prerequisite for Internet state):

Any L3 tunnel and LTE interfaces will initially have this state. Layer 2 interfaces can obtain this state if:

an interface has an active route to 8.8.8.8 in main routing table.
an interface can obtain (or has obtained) an address from DHCP (does not apply if DHCP server is also running Detect Internet on the DHCP server interface).

It doesn't say "will obtain a DHCP address for you if needed". The two bullets weren't clear

if help==\[*\] then {&& or ||, (", or" | &)} else  '\;-\)'

.

The config used isn't mine – it's what the Mikrotik iPhone smartphone (advertised at top

) adds when some user enables it in the app:

/interface/detect-internet> export
# dec/01/2021 15:04:08 by RouterOS 7.1rc7
# model = RBD25GR-5HPacQD2HPnD
/interface detect-internet
set detect-interface-list=all internet-interface-list=WAN

So the config here isn't my choice. And reconfiguring it in the app looked like a bad idea since it didn't match the CLI, so didn't try to tap the checkmark:

/interface/detect-internet> print
    detect-interface-list: all
       lan-interface-list: none
       wan-interface-list: none
  internet-interface-list: WAN

The full config is same as I posted here, which is largely my V7 test platform: viewtopic.php?t=180369

buset1974 · Thu Dec 02, 2021 5:03 am

did anyone successfully migrate mpls to v7.1rc7?
i don't know why my ospf suddenly going crazy (not perfectly works) right after i activated the LDP.

thx

infabo · Thu Dec 02, 2021 9:32 am

I noticed myself that the Mikrotik app for Android is on some screens off the actual config. So better check twice before saving. Some screens you can reach from the app dashboard are actually something like quickset. so be careful!

pe1chl · Thu Dec 02, 2021 11:01 am

In testing /interface/detect-internet with r7.1rc7, I noticed it creates a DHCP client automatically.

Well I think detect-internet is in the same class as QuickSet: something that may be nice for home users with a NAT router, but you need to
disable it when you use your router in a more traditional way.
I have seen such mysterious DHCP clients in v6 as well, but they were not marked with a comment. Maybe they were from the same origin.
E.g. when I install a CHR image which still has blank config, and I am accessing it via MAC address, to prepare it to load an import file, it keeps
creating a DHCP client on the first ethernet port. You can remove it and quickly import the file and it stays quiet, but when you just examine
the situation it is created again after a while. Could well be that this was detect-internet as well! (of course it was disabled in my imported config)

As always with these "smart" features, sometimes they are nice to have (e.g. you want to access that new CHR via IP), sometimes they are irritating.

spleach · Thu Dec 02, 2021 11:55 am

Hi, not sure if this has been reported - it's not been mentioned on this page or the forum page on 7.1rc6 though - but I have issues with my wireguard interfaces and peers after upgrading ROS through the wireguard connection.

That is, I activate a wireguard client on my phone or laptop. Once active, I log in to webfig on my router (RB4011), go to Packages and press Download and Install. Progress goes up to 75% and then appears to hang, but what I think happens is the connection gets severed. After a few minutes, by which time the router should have been upgraded and rebooted, I cannot reconnect using my phone. Bytes received (on the client) goes to 92B, hangs for a while, then jumps to 124B. Maybe the handshake occurs, then a keep alive packet, but no actual data throughput. At this point, I think I'm locked out...

However, I've another wireguard client configured, my laptop. That works no problem. I can connect and sign in to webfig without any issue. Everything seems fine within webfig. If I disable and reenable the wireguard Peer that is my phone, then my phone can connect again, but for whatever reason this then kills my laptop's connection. It's a bit bizarre really.

This happened with upgrades to both 7.1rc6 and 7.1rc7. Maybe the Download & Install button shouldn't be used through a wireguard connection. When 7.1rc6 broke it, I downgraded the ROS (to rc5) and upgraded again and it kind of worked again, but this was only after creating a new wireguard interface specifically for my laptop, and then disabling the first wireguard interface and reenabling it.

Basically, there seems to be an issue with the wireguard interfaces or peers when upgraded through webfig, through a wireguard connection.

Should I report this elsewhere, or is there any further information I can provide here? Can anyone else reproduce this?

Thanks and kind regards,
Alex

msatter · Thu Dec 02, 2021 12:20 pm

data len 1492 is normal in mikrotik logs for the lcp echo request & reply with a rfc4638 compliant pppoe.
That's also what I see in my logs.
ppp-max-payload is 1500 though.
And resulting mtu/mru is 1500.

I tried several variation but in PPPoE screen the MTU drops to 1492 or when I put in a fixed MTU it drops back to 1480.
Pinging I can use 1492 but not higher. In V6, this problem was solved after a few ROS versions.

CTassisF · Thu Dec 02, 2021 12:54 pm

Version 7.1 1638367647 was briefly released under the "testing" branch, but then this release was rolled back.

jookraw · Thu Dec 02, 2021 1:04 pm

Why is it useless?

If you enable vlan-filtering, you loose fasttrack, fastpath and any other kind of hw acceleration, which make not possible to get 1gig LAN - WAN on the RB4011 (not even half of it).
In my case I have to use a external switch (CSS610) to do the work that the switch on the RB4011 is unable to do.

Znevna · Thu Dec 02, 2021 1:06 pm

Really?
This changelog is listed in v7.1rc1:
*) added bridge HW offload support for vlan-filtering on RTL8367 switch chip (RB4011, RB1100AHx4);
So it doesn't work?

eworm · Thu Dec 02, 2021 1:14 pm

Keep in mind that RB4011 has two switch chips... Bridging ports from both chips makes the/some traffic go through the CPU.

jookraw · Thu Dec 02, 2021 1:18 pm

My RB4011 have no problem on PPPoE with MTU 1540 when using the SFP+ port.
I use a router-in-a-stick configuration, as the switch on the RB4011 is useless
Strange because it is stated that PPPoE is max 1500:
https://www.juniper.net/documentation/u ... rview.html
The header uses six bytes and the ID two. Then the MTU behind the PPPoE should be 1508. I have to use VLAN and that adds 4 bytes and the SPF sets at 1598 or so.
My 4011 is also only doing the connection plus VPN. What are your setting for over 1500? Mine drops after a few seconds from 1500 to 1492.

My ISP, uses vlan with 1600, PPPoE 1540. I've set the SFP+ port to 6000.
some of those settings I took when exploring the ISP-provided gateway.
My PPPoE client does not even have MTU set on my side, is the server who is setting it at 1540, and looking the server's mac, it is a Juniper.

jookraw · Thu Dec 02, 2021 1:21 pm

Really?
This changelog is listed in v7.1rc1:
*) added bridge HW offload support for vlan-filtering on RTL8367 switch chip (RB4011, RB1100AHx4);
So it doesn't work?

Yes, if you use 1 vlan, no tagging and no intra-vlan routing (which includes having the PPPoE client on a vlan).
If I use vlans, the FP RX/TX is always at 0, the last time that I bothered tesing was on 7.1rc4

jookraw · Thu Dec 02, 2021 1:22 pm

Keep in mind that RB4011 has two switch chips... Bridging ports from both chips makes the/some traffic go through the CPU.

I know that, I was just trying to use one switch of the two, but still no luck...

the problem is exact the same with the RB5009, that is a complete unfinished product...

pe1chl · Thu Dec 02, 2021 1:23 pm

Really?
This changelog is listed in v7.1rc1:
*) added bridge HW offload support for vlan-filtering on RTL8367 switch chip (RB4011, RB1100AHx4);
So it doesn't work?

It works for me! The switchports on my RB4011 have hw accel enabled even with bridge vlan filtering!

jookraw · Thu Dec 02, 2021 1:24 pm

Really?
This changelog is listed in v7.1rc1:
*) added bridge HW offload support for vlan-filtering on RTL8367 switch chip (RB4011, RB1100AHx4);
So it doesn't work?
It works for me! The switchports on my RB4011 have hw accel enabled even with bridge vlan filtering!

yes you see the "H" on the ports, but the traffic is not getting fasttracked or going via fastpath, look the counters

example:

Screenshot 2021-12-02 124021.png

emils · Thu Dec 02, 2021 1:58 pm

New version 7.1 has been released in testing RouterOS channel:

viewtopic.php?t=180831