v6.47rc [testing] is released!

emils · Tue May 26, 2020 11:38 am

Version 6.47rc2 has been released.

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 6.47rc2 (2020-May-25 12:30):

Important note!!!

- The Dude server must be updated to monitor v6.46.4 and v6.47beta30+ RouterOS type devices.
- The Dude client must be manually upgraded after upgrading The Dude server.
- Make sure LTE APN Profile name does not match any of the DHCP server's names if LTE passthrough is used.
- The Dude requires "winbox" policy instead of "dude" to monitor v6.46.4 and v6.47beta30+ RouterOS type devices.

MAJOR CHANGES IN v6.47:
----------------------
!) dns - added client side support for DNS over HTTPS (DoH) (RFC8484);
!) socks - added support for SOCKS5 (RFC 1928);
!) user - enable "winbox" policy for groups with "dude" policy;
----------------------

Changes since last beta release:

*) api - added ECDHE cipher support for "api-ssl" service;
*) bonding - fixed ALB and TLB bonding modes after interface disable/enable (introduced in v6.47beta19);
*) bonding - fixed packet receiving on bonding slave ports (introduced in v6.47beta19);
*) bridge - added warning message when a bridge port gets dynamically added to VLAN range;
*) chr - added support for hardware watchdog on ESXI;
*) crs3xx - fixed tagged VLAN packet receiving on Ethernet interfaces for CRS354 devices (introduced in v6.47beta49);
*) crs3xx - improved 10G interface initialization on CRS312 devices;
*) dhcpv4-server - disallow zero lease-time setting;
*) dhcpv6-server - do not require "server" parameter for bindings;
*) dns - added support for multiple type static entries;
*) dot1x - added "radius-mac-format" parameter;
*) dot1x - improved Dot1X service stability when receiving bogus packets;
*) dot1x - improved value validation for dynamically created switch rules;
*) email - added support for multiple "to" recipients;
*) ethernet - fixed interface stopping responding after blink command execution on CCR2004-1G-12S+2XS;
*) filesystem - fixed NAND memory going into read-only mode or becoming unstable over time;
*) health - improved stability for system health monitor on CCR2004-1G-12S+2XS;
*) ike2 - added support for RFC8598;
*) ike2 - allow initiator address change before authentication;
*) ike2 - fixed authentication handling when initiator disconnects before RADIUS response;
*) interface - improved system stability when receiving bogus packets;
*) ipsec - added "split-dns" parameter support for mode configuration;
*) ipsec - added "use-responder-dns" parameter support;
*) ipsec - allow specifying two peers for a single policy for failover;
*) ipsec - place dynamically created IPsec policies at the begining of the table;
*) l2tp - added "src-address" parameter for L2TP client;
*) l2tp - added "use-peer-dns" parameter for L2TP client;
*) l2tp - improved dynamically created IPsec configuration updating;
*) l2tp - use L2TP interface when adding dynamic IPsec peer;
*) lcd - improved general system stability when LCD is not present;
*) log - added logging entry when changing user's password;
*) log - added tunnel endpoint address to establishment and disconnect logging entries;
*) log - fixed logging topic for MAC address learning on a different bridge port events;
*) log - made startup script failures log as critical errors;
*) lte - fixed "band" parameter persistence after disable/enable;
*) lte - fixed "ecno" and "rscp" value reporting on R11e-LTE6;
*) lte - fixed VLAN interface passthrough support;
*) lte - improved stability during firmware upgrade;
*) netwatch - improved Netwatch service stability when invalid configuration values are passed;
*) ovpn - added "use-peer-dns" parameter for OVPN client;
*) poe - fixed missing PoE out settings on CRS354-48P-4S+2Q (introduced in v6.47beta49);
*) port - removed serial console port on hEX S;
*) ppp - removed "comment", "set" and "edit" commands from "PPP->Active" menu;
*) pptp - added "use-peer-dns" parameter for PPTP client;
*) profile - added support for CCR2004-1G-12S+2XS;
*) qsfp - added support for FEC mode (fec74), with the FEC mode disabled by default
*) quickset - fixed invalid configuration applying when performing changes during LTE modem initialization process;
*) routerboard - added "hold-time" parameter to mode-button menu;
*) routerboard - added "reset-button" menu - custom command execution with reset button;
*) routing - improved routing service stability when receiving bogus packets;
*) sfp28 - added support for FEC modes (fec74 and fec91), with fec91 mode already enabled by default;
*) sfp28 - fixed interface linking after power cycle on CCR2004-1G-12S+2XS (introduced in v6.47beta49);
*) switch - correctly enable and disable CPU Flow Control on RB3011UiAS;
*) tr069-client - added LTE firmware update functionality support;
*) tr069-client - added additional LTE information parameters;
*) tr069-client - added additional wireless registration table parameters;
*) tr069-client - added interface type parameter support;
*) tr069-client - added multiple simultaneous session support for diagnostics test;
*) tr069-client - added total connection tracking entries parameter;
*) ups - added battery info for APC SmartUPS 2200;
*) webfig - fixed 5GHz wireless interface "frequency" parameter value list on Audience;
*) winbox - added "auth-info" parameter under "Dot1X->Active" menu;
*) winbox - added "auth-types", "comment", "mac-auth-mode" and "reject-vlan-id" parameters for Dot1X server;
*) winbox - added "bus" parameter for "USB Power Reset" command on NetMetal ac^2;
*) winbox - added "comment" parameter and "dynamic" flag support under "Switch->Rule" table;
*) winbox - added "comment" parameter for Dot1X client;
*) winbox - added "region" parameter for W60G interfaces;
*) winbox - added "skip-dfs-channels" parameter to wireless interface menu;
*) winbox - added enable and disable buttons for "MPLS->MPLS Interface" table;
*) winbox - do not allow to enter empty strings in "caps-man-names" and "common-name" parameters;
*) winbox - fixed WDS usage when connecting to RouterOS access point using QuickSet;
*) winbox - fixed dates and times in interface link up/down properties (WinBox v3.24 required);
*) winbox - fixed wireless sniffer parameter setting;
*) wireless - fixed Nstreme wireless protocol performance decrease;
*) wireless - updated "egypt" regulatory domain information;

Full changelog is available here: https://mikrotik.com/download/changelog ... lease-tree

SiB · Tue May 26, 2020 12:10 pm

Prev: v6.47beta [testing] is released!

whatever · Tue May 26, 2020 12:32 pm

*) filesystem - fixed NAND memory going into read-only mode or becoming unstable over time;

Which previous versions are/were affected by this issue?

osc86 · Tue May 26, 2020 12:42 pm

*) winbox - fixed dates and times in interface link up/down properties (WinBox v3.24 required);

finally, thanks

Cha0s · Tue May 26, 2020 1:15 pm

*) wireless - fixed Nstreme wireless protocol performance decrease;

Can you give more information about this?

msatter · Tue May 26, 2020 1:33 pm

I can now connect over SFP and get a link up of 1Gbit/s. However like with 6.46.x the PPPoE connection drops back to a MTU of 1480 instead of the usual MTU of 1500 after short time.

Back to using the media converter connected to a ether-port.

Hoping this can be solve this before release of 6.47

Addition: When I set not MTU then it becomes 1488 and that is 1500 minus 12 used for PPPoE and VLAN.

Update: writing the addition I thought let's try it again. I set the MTU of the SFP MTU to 1512 and also 1512 to to the vlan and with without any MTU manual setting on the PPPoE I got at MTU of 1492 on the PPPoE and so the VLAN was already above 1500. Then I set also the MTU of 1500 to the PPPoE and did not got an connection. hmmmmm
While having the PPPoE trying to connect I disabled the SFP and enabled it again, and BOOM I have also a MTU of 1500 on the PPPoE.

I also lowered the L2MTU of the SFP from 1600 to 1592 to be the same as the that of the ether ports.

Not going to touch it again now it is running. Bit more stable would be nice in case of a reboot of the 4011 router.

eworm · Tue May 26, 2020 1:45 pm

This has...

*) dns - added support for multiple type static entries;

... but is missing from 6.47beta60...

*) dns - added support for forwarding DNS queries of static entries to specific server (CLI only);

This can still be configured, but still does not work when DNS over HTTPS is enabled.

I would like to have DNS over HTTPS and conditional forwarding of DNS queries, at the same time.

emils · Tue May 26, 2020 2:08 pm

whatever All versions.The fix is quite trivial and improves how files are handled on NAND type memory.
eworm Currently DoH will be prioritized over all other DNS configuration. Not sure if this will change any time soon.

eworm · Tue May 26, 2020 2:21 pm

On boot system logs:

system;error;critical error while running customized default configuration script: no such item

Is this expected? (If it is I would like to see the severity reduced. "error" and "critical" raise alerts here.)

eworm · Tue May 26, 2020 2:22 pm

eworm Currently DoH will be prioritized over all other DNS configuration. Not sure if this will change any time soon.

In general this makes sense. But I vote for an excepting with conditional forwarding of DNS queries.

xrayd · Tue May 26, 2020 3:01 pm

*) wireless - fixed Nstreme wireless protocol performance decrease;

there was problem with Nstreme wireless protocol?
since when?

Cha0s · Tue May 26, 2020 3:04 pm

Frankly since 802.11n, but I am curious what exactly they fixed.

Tue May 26, 2020 3:29 pm

Frankly since 802.11n, but I am curious what exactly they fixed.

Sad but true

pe1chl · Tue May 26, 2020 5:03 pm

Did someone check if the breakage of IPsec in beta60 has been completely fixed?
(it is not mentioned in the release notes)

santyx32 · Tue May 26, 2020 5:23 pm

Is ROS 7 still being developed?, I wonder since there haven't been new betas since February.

w0lt · Tue May 26, 2020 6:08 pm

Did someone check if the breakage of IPsec in beta60 has been completely fixed?
(it is not mentioned in the release notes)

I'm a little cautious, but...yes So far so good..at least to the parts of IPSec that I am using.
Still going to leave many on 6.45.9 for a while yet..

Definitely only using dual partition capable to be able to switch back if necessary.
I wish Tiki's would put enough ram in all models to be able to do this.

-tp

kerafyrm · Tue May 26, 2020 6:32 pm

eworm Currently DoH will be prioritized over all other DNS configuration. Not sure if this will change any time soon.
In general this makes sense. But I vote for an excepting with conditional forwarding of DNS queries.

agree with you.
dns forwarding via DOH is a very useful feature.

Chupaka · Tue May 26, 2020 7:17 pm

eworm Currently DoH will be prioritized over all other DNS configuration. Not sure if this will change any time soon.
In general this makes sense. But I vote for an excepting with conditional forwarding of DNS queries.
agree with you.
dns forwarding via DOH is a very useful feature.

+1. I'd like to forward internal zones via VPN to an organization DNS and all the rest - to 1.1.1.1 via DoH

eworm · Tue May 26, 2020 9:21 pm

+1. I'd like to forward internal zones via VPN to an organization DNS and all the rest - to 1.1.1.1 via DoH

Exactly my use case.
Two great now features - would be frustrating to have to choose between them.

pe1chl · Tue May 26, 2020 9:40 pm

Did someone check if the breakage of IPsec in beta60 has been completely fixed?
(it is not mentioned in the release notes)
I'm a little cautious, but...yes So far so good..at least to the parts of IPSec that I am using.

Ok thanks! I updated one router that is not so critical and it appears to work with L2TP/IPsec (which completely failed in beta60).

nmt1900 · Tue May 26, 2020 11:05 pm

*) filesystem - fixed NAND memory going into read-only mode or becoming unstable over time;

Most interesting question here is - what would be possible consequences of "NAND memory going into read-only mode or becoming unstable over time" in context of this fix???

Sob · Tue May 26, 2020 11:30 pm

I have to join other DNS fans, I'm grateful for improvements, but it's like you stopped just few steps before finish line.

If I have regular resolver in global config (/ip dns set servers=<...>), then all local overrides (/ip dns static add <...>) are preferred, whether it's single hostname or new FWD. But if I use global DoH resolver, then static records still have preference, except just one type (FWD), which is suddenly ignored. What's the logical explanation for this inconsistency?

Then there are still other things about FWD. Possibility to have redundancy would be very nice. There's already first step with round-robin when forward-to contains hostname with multiple addresses. And the whole thing with regexp being the only way for forwarding <anything>.domain.tld, it would deserve at least an explanation, why it should be the best solution. Current behaviour, where name=domain.tld for FWD means exact hostname "domain.tld", is strange. Who even needs that? Maybe there are some use cases, but IMHO the expected behaviour is to forward all subdomains. Can't that be made optional (new parameter forward-subdomains=<yes|no> for FWD would do the trick)? Then you can combine it together, get addresses from all FWDs with same name, and use something more intelligent for redundancy, at least simple fallback to next server. And everyone would love it.

Sob · Wed May 27, 2020 12:44 am

There's problem with SOCKS's bind command. It's supposed to return external address to which someone else can connect (e.g. if client wants to use active FTP with PORT command). Old SOCKS4 work correctly, it returns WAN address (192.168.80.183 in this example):

socks4bind.png

But new SOCKS5 doesn't:

socks5bind.png

Wed May 27, 2020 3:11 am

eworm Currently DoH will be prioritized over all other DNS configuration. Not sure if this will change any time soon.
In general this makes sense. But I vote for an excepting with conditional forwarding of DNS queries.
agree with you.
dns forwarding via DOH is a very useful feature.
+1. I'd like to forward internal zones via VPN to an organization DNS and all the rest - to 1.1.1.1 via DoH

+1

It is so annoying not being able to do this.

Davis · Wed May 27, 2020 3:19 am

eworm Currently DoH will be prioritized over all other DNS configuration. Not sure if this will change any time soon.
In general this makes sense. But I vote for an excepting with conditional forwarding of DNS queries.
agree with you.
dns forwarding via DOH is a very useful feature.
+1. I'd like to forward internal zones via VPN to an organization DNS and all the rest - to 1.1.1.1 via DoH

+1 Such configuration (forward for specific zones + DoH for everything else) should be quite common

redskilldough · Wed May 27, 2020 4:50 am

Hi,

I keep getting errors on DoH in the logs:

DoH max concurrent queries reached, ignoring queries

How do I increase the limit? (increasing the max concurrent queries setting doesn't help)

rpingar · Wed May 27, 2020 8:53 am

there is still issue about ARP and Bonding (802.3ad) interfaces!!!!! at least on CCR tilera platform.

update: the problem is present when the link monitoring is arp mode; if I disable it, works fine.

doneware · Wed May 27, 2020 11:31 am

log - made startup script failures log as critical errors;

god bless you!!!!!!

Wed May 27, 2020 11:33 am

@rpingar - We have included a bonding fix that should solve the previously reported non-complete ARP entries. However, ARP link monitoring is not recommended for the LACP mode due to transmit hash policy on the peer device (the ARPs for link monitoring might arrive only on one slave port). This behavior is not related to 6.47 version.

parham · Wed May 27, 2020 12:13 pm

Hey All,

Sorry to asking this questions, 1- can we get feature add in Netwatch for adding srcaddress or ping from interface, and 2- did the fix applied for IPSec mode config spilt subnet?

Thanks for all your hard work.
Parham

sola969 · Wed May 27, 2020 2:11 pm

When ipv6 changes, win10 can get the new address normally, but it cannot be used. It is necessary to disconnect the network port and restart. When can it be fixed, this problem has been for many years.

patrickmkt · Wed May 27, 2020 2:38 pm

I am wondering if the certificate check issue with openvpn was fixed.

anav · Wed May 27, 2020 4:01 pm

It would be better if MT, actually published their requirements documents and associated use cases.
It seems as if they are often incomplete based on these sorts of discussions (seems being the operative word).
In the above discussion, people are saying great we now functionality X so we should be able to do Y.
Why is it that MT stops at X and does not produce X+Y.

I find it hard to believe they do not know about Y!!
The truth is probably in between.......... In that MT has a long term plan and they are very disciplined into breaking out functionality in use-able chunks.
So X must provide some amount of use-able functionality (otherwise wasted code), however to do X+Y at once is too much effort or too much risk or lack of resources.

In other words, without seeing their LONGER term planning documents, it impossible for us to make any judgements. Probably for competitor reasons these plans are not public.
It may very well be that due to developing RoS7, they are implementing similar changes and want to make sure of stability in 6, before porting to 7 etc.
Or they are working on X+Y in Ro7 and want to test the X they have developed in version 6.

pe1chl · Wed May 27, 2020 4:10 pm

When ipv6 changes, win10 can get the new address normally, but it cannot be used. It is necessary to disconnect the network port and restart. When can it be fixed, this problem has been for many years.

Does it work after half an hour? That is the RA Lifetime defined in IPv6->ND.
A known bug is that the RA services does not send an informational message with zero lifetime for the old address when an address is changed.
Maybe you can mitigate that by lowering the RA lifetime (and interval) to something more acceptable than half an hour.

eworm · Wed May 27, 2020 4:42 pm

Setting attributes for static DNS records changes other attributes unintentionally:

[admin@mt] /ip dns static> add forward-to=10.0.0.1 regexp="example.com" type=FWD    
[admin@mt] /ip dns static> set regexp="example\\.com\$" [ find where regexp="example.com" ]
[admin@mt] /ip dns static> export
[...]
add address=10.0.0.1 regexp="example\\.com\$" type=A

Note that type changed to "A" without actually changing it.

mgisbers · Wed May 27, 2020 6:14 pm

eworm Currently DoH will be prioritized over all other DNS configuration. Not sure if this will change any time soon.
In general this makes sense. But I vote for an excepting with conditional forwarding of DNS queries.

+1

osc86 · Wed May 27, 2020 10:08 pm

When ipv6 changes, win10 can get the new address normally, but it cannot be used. It is necessary to disconnect the network port and restart. When can it be fixed, this problem has been for many years.

So, is this a bug in ROS or Windows? This is so annoying, my workaround currently is to disable ipv6 protocol in network adapter settings and re-enable it.

lelmus · Wed May 27, 2020 10:52 pm

On boot system logs:
system;error;critical error while running customized default configuration script: no such item
Is this expected? (If it is I would like to see the severity reduced. "error" and "critical" raise alerts here.)

Same issue pops up here.Log and Terminal say same System Error message, but no details.

Is this System Error message serious??? And where is it?

doneware · Thu May 28, 2020 1:35 am

When ipv6 changes, win10 can get the new address normally, but it cannot be used. It is necessary to disconnect the network port and restart. When can it be fixed, this problem has been for many years.

hi.
it depends on the value of ra-prefix-lifetime. it's 30mins or so. SLAAC is stateless - hence the name. the router is not interested, what address your pc holds. it will just send RAs periodically. you seem to receive it, as your win10 can generate a new EUI based on the changed address. the default gw doesn't change, as it's a link-local address.
most probably your pc still wants to use the 'older' ipv6 addresses, as they 'seem' to be still valid.

the host is responsible for tracking the prefix validity, based on the received prefix-lifetime value.
When the lifetime expires the address is marked as depreciated and should not be used as the source for future communication, but it should still be used to receive communications on.

can you do a packet capture on your PC? just look for RA/RS messages. after your address changes (maybe you receive a new prefix via dhcpv6-pd) there shouldn't be any more RA messages arriving with the old prefix information. also, the value of prefix-lifetime must be according to the ipv6 PD lease your router received from the upstream server.

doneware · Thu May 28, 2020 1:51 am

When ipv6 changes, win10 can get the new address normally, but it cannot be used. It is necessary to disconnect the network port and restart.

well, to me it seems to be an issue, as dynamic ND prefix entries have their valid-lifetime independently from the dhcpv6 PD lease the system used to generate addresses for the respective interfaces.

[admin@router] /ipv6 nd prefix> print 
Flags: X - disabled, I - invalid, D - dynamic 
 0  D prefix=2001:1234:5678:b600::/64 6to4-interface=none interface=lan on-link=yes autonomous=yes valid-lifetime=4w2d 
      preferred-lifetime=1w 

 1  D prefix=2001:1234:5678:b601::/64 6to4-interface=none interface=internet on-link=yes autonomous=yes 
      valid-lifetime=4w2d preferred-lifetime=1w

i filed a new support ticket about this.

rooted · Thu May 28, 2020 5:59 am

Is ROS 7 still being developed?, I wonder since there haven't been new betas since February.

Maybe it will be a larger update vs incremental.

Gombeen666 · Thu May 28, 2020 12:22 pm

Can someone explain -
"The Dude requires "winbox" policy instead of "dude" to monitor v6.46.4 and v6.47beta30+ RouterOS type devices."

raffav · Thu May 28, 2020 1:09 pm

Can someone explain -
"The Dude requires "winbox" policy instead of "dude" to monitor v6.46.4 and v6.47beta30+ RouterOS type devices."

My guess is that they make some changes how the dude interact with routerOS so you need to have winbox policy in order to user the [emoji819] RouterOS in the dude application

Sent from my Moto Z3 Play using Tapatalk

sola969 · Fri May 29, 2020 8:31 am

When ipv6 changes, win10 can get the new address normally, but it cannot be used. It is necessary to disconnect the network port and restart. When can it be fixed, this problem has been for many years.
So, is this a bug in ROS or Windows? This is so annoying, my workaround currently is to disable ipv6 protocol in network adapter settings and re-enable it.

It must be the problem of ROS. It is normal to use other routers IPv6.

sola969 · Fri May 29, 2020 8:33 am

When ipv6 changes, win10 can get the new address normally, but it cannot be used. It is necessary to disconnect the network port and restart. When can it be fixed, this problem has been for many years.
Does it work after half an hour? That is the RA Lifetime defined in IPv6->ND.
A known bug is that the RA services does not send an informational message with zero lifetime for the old address when an address is changed.
Maybe you can mitigate that by lowering the RA lifetime (and interval) to something more acceptable than half an hour.

The minimum can be set to 10 minutes, the time is too long, everything is meaningless, do not know if it will work.

sola969 · Fri May 29, 2020 8:35 am

When ipv6 changes, win10 can get the new address normally, but it cannot be used. It is necessary to disconnect the network port and restart.
well, to me it seems to be an issue, as dynamic ND prefix entries have their valid-lifetime independently from the dhcpv6 PD lease the system used to generate addresses for the respective interfaces.
Code: Select all
[admin@router] /ipv6 nd prefix> print 
Flags: X - disabled, I - invalid, D - dynamic 
 0  D prefix=2001:1234:5678:b600::/64 6to4-interface=none interface=lan on-link=yes autonomous=yes valid-lifetime=4w2d 
      preferred-lifetime=1w 

 1  D prefix=2001:1234:5678:b601::/64 6to4-interface=none interface=internet on-link=yes autonomous=yes 
      valid-lifetime=4w2d preferred-lifetime=1w 
i filed a new support ticket about this.

Thanks for the support, I don't know if the official will ignore it.

doneware · Fri May 29, 2020 9:32 am

The minimum can be set to 10 minutes, the time is too long, everything is meaningless, do not know if it will work.

yes, it still sucks. moreover those ND prefix entries are dynamic.
there's another workaround i proposed to support:
once an interface is getting renumbered (read: it looses a certain previous GUA) either automatically (via pool addressing) or manually (/ipva address remove X)
RouterOS should send a last RA with the disappearing prefix to the network with valid-lifetime = 0. this shall flush all the caches on the nodes that receive it.

in reality this isn't a workaround, more like an addition. i collected packet captures from different devices, and they all respect the DHCPv6 lease time in their RA.
so this two changes shall be combined.

doneware · Fri May 29, 2020 9:53 am

in reality this isn't a workaround, more like an addition. i collected packet captures from different devices, and they all respect the DHCPv6 lease time in their RA.
so this two changes shall be combined.

ok, there should maybe be 3 changes, as the DHCP-PD server in routeros also doesn't care about the lease of dynamic pools if it operates based on them.
sure, you can tune down the lease-time setting in the manually created DHCP-PD entries, but not in the dynamic ones, spawned by /ppp profile configuration.
in either way, you have a change in the pool you receive via PD, and your entire downstream network will lose v6 connectivity.
in this latter case i'd definitely use a simple algorithm to avoid massive leases on all PD clients:
- setting for a default lease time (globally) say SYSTEM_DEFAULT_DHCPV6PD_LEASE (currently it's 3d)
- setting for each PD entry specific lease setting, DHCPV6PD_ENTRY_LEASE (if not specified explicitly then copy over SYSTEM_DEFAULT_DHCPV6PD_LEASE)
- the value derived from the current lease expiration of the referenced pool entry (POOL_LEASE_LEFT)

and the DHCPv6 reply to the PD client shall set th valid lifetime in the IA Prefix option to X, where
X=min(DHCPV6PD_ENTRY_LEASE, POOL_LEASE_LEFT)

this way we'd only have shorter leases than intended if the pool we operate on is running out of lifetime. and we avoid propagating outdated info and potentially cut of parts of the dynamically addressed v6 network from the outside

pe1chl · Fri May 29, 2020 11:10 am

once an interface is getting renumbered (read: it looses a certain previous GUA) either automatically (via pool addressing) or manually (/ipva address remove X)
RouterOS should send a last RA with the disappearing prefix to the network with valid-lifetime = 0. this shall flush all the caches on the nodes that receive it.

Yes, that is what I wrote above as well. But it does not do that.
I checked in a trace and I see that it also does not clamp the time to the 1800 seconds set for ND so lowering that probably will not work either.
The valid time transmitted in the RA is the time it gets from the DHCPv6 PD pool. Even when that is more than 1800 seconds. That is a bug as well, IMHO.

Fortunately this dynamic address crap is not used over here... it is a big PITA especially because RouterOS does not have NPT (network prefix translation).
It makes IPv6 practically unusable on your local network.

sola969 · Fri May 29, 2020 11:23 am

in reality this isn't a workaround, more like an addition. i collected packet captures from different devices, and they all respect the DHCPv6 lease time in their RA.
so this two changes shall be combined.
ok, there should maybe be 3 changes, as the DHCP-PD server in routeros also doesn't care about the lease of dynamic pools if it operates based on them.
sure, you can tune down the lease-time setting in the manually created DHCP-PD entries, but not in the dynamic ones, spawned by /ppp profile configuration.
in either way, you have a change in the pool you receive via PD, and your entire downstream network will lose v6 connectivity.
in this latter case i'd definitely use a simple algorithm to avoid massive leases on all PD clients:
- setting for a default lease time (globally) say SYSTEM_DEFAULT_DHCPV6PD_LEASE (currently it's 3d)
- setting for each PD entry specific lease setting, DHCPV6PD_ENTRY_LEASE (if not specified explicitly then copy over SYSTEM_DEFAULT_DHCPV6PD_LEASE)
- the value derived from the current lease expiration of the referenced pool entry (POOL_LEASE_LEFT)

and the DHCPv6 reply to the PD client shall set th valid lifetime in the IA Prefix option to X, where
X=min(DHCPV6PD_ENTRY_LEASE, POOL_LEASE_LEFT)

this way we'd only have shorter leases than intended if the pool we operate on is running out of lifetime. and we avoid propagating outdated info and potentially cut of parts of the dynamically addressed v6 network from the outside

The ipv6 of ros is really too bad, even the basic use cannot be guaranteed, everything needs official attention and repair.

doneware · Fri May 29, 2020 12:29 pm

The ipv6 of ros is really too bad, even the basic use cannot be guaranteed, everything needs official attention and repair.

i'd say there's a lot more to improve, but it is still superior to many other available implementations out there. and i love the flexibility it offers to me. i spent 20+ yrs in networking, working with all kinds of devices. when it comes down to flexibility, only junOS comes near to routerOS. i've grown up using the cisco CLI, still do it in my 'other life'. nothing is perfect.
you would not believe what kind of pains we endured because of a small packet parser issue in the iOS XR code, and it kept bringing our network to its knees for more than 1 month with absolutely random occurrences. all this was because the microcode identified az IPv4 packet to be IPv6 one which started a chain reaction, and took out sometimes 3-7 ASR9k routers in a row. or when we had to as for an enhancement, because the device was not doing fragmentation and broke PMTUD by silently dropping packets with DF flags.
shit keeps on happening, and sometimes it is totally ridiculous to see what type of junk goes through the software QA of some big brand names.

ROS certainly lacks a lot of things, but it is improving, sometimes in bursts, but some things take a longer time. if we can provide usable feedbacks to dev, they can pretty much nail it down quickly. i once had a feature request with 6.32(?) to add support for DWDM SFPs, and it was done in less than 2 weeks and it was working. if you are specific with the enhancement details or can pinpoint the actual issue, stuff can improve pretty fast.

sola969 · Fri May 29, 2020 1:15 pm

The ipv6 of ros is really too bad, even the basic use cannot be guaranteed, everything needs official attention and repair.
i'd say there's a lot more to improve, but it is still superior to many other available implementations out there. and i love the flexibility it offers to me. i spent 20+ yrs in networking, working with all kinds of devices. when it comes down to flexibility, only junOS comes near to routerOS. i've grown up using the cisco CLI, still do it in my 'other life'. nothing is perfect.
you would not believe what kind of pains we endured because of a small packet parser issue in the iOS XR code, and it kept bringing our network to its knees for more than 1 month with absolutely random occurrences. all this was because the microcode identified az IPv4 packet to be IPv6 one which started a chain reaction, and took out sometimes 3-7 ASR9k routers in a row. or when we had to as for an enhancement, because the device was not doing fragmentation and broke PMTUD by silently dropping packets with DF flags.
shit keeps on happening, and sometimes it is totally ridiculous to see what type of junk goes through the software QA of some big brand names.

ROS certainly lacks a lot of things, but it is improving, sometimes in bursts, but some things take a longer time. if we can provide usable feedbacks to dev, they can pretty much nail it down quickly. i once had a feature request with 6.32(?) to add support for DWDM SFPs, and it was done in less than 2 weeks and it was working. if you are specific with the enhancement details or can pinpoint the actual issue, stuff can improve pretty fast.

I agree with you.
IPv4 will be eliminated in the near future, and IPv6 will become mainstream. The function of ROS in ipv4. Flexibility is unmatched by other router systems, I hope it can continue to develop in IPv6.

SiB · Sat May 30, 2020 3:40 pm

eworm Currently DoH will be prioritized over all other DNS configuration. Not sure if this will change any time soon.
In general this makes sense. But I vote for an excepting with conditional forwarding of DNS queries.

+1
for conditional forwarding of DNS queries AND DoH TOGETHER.

Cha0s · Sun May 31, 2020 9:21 pm

Upgraded from 6.45.5 to 6.47rc2.

Noticed that btest is taking up more memory causing boards with 32MB RAM to become unresponsive.

I don't know in which version this started. I also tried 6.46.6 with the same results.

raffav · Sun May 31, 2020 9:25 pm

Upgraded from 6.45.5 to 6.47rc2.

Noticed that btest is taking up more memory causing boards with 32MB RAM to become unresponsive.

I don't know in which version this started. I also tried 6.46.6 with the same results.

Note from MT about the Btest

Please remember that Bandwidth Test uses a lot of resources. If you want to test real throughput of a router, you should run Bandwidth Test through the tested router not from or to it. To do this you need at least 3 devices connected in chain: the Bandwidth Test server, the router being tested and the Bandwidth Test client.

Cha0s · Sun May 31, 2020 9:27 pm

This is irrelevant.

bbs2web · Mon Jun 01, 2020 8:07 am

The change log is not comprehensive. Shouldn't it include all changes when moving the release candidate to it's own thread?

I'm referring to the following changes which fix packet loss due to bridges learning IP neighbor mac address on blocked STP ports, easily reproducible in a simple ABC triangle.

Originally reported:
viewtopic.php?f=21&t=147904&p=736204#p736204

Discussed this in more detail via a support ticket where some items were simply ignored, for example that LLDP RFC details that link local discovery shouldn't be forwarded by bridges.

Annoying not to ever get feedback when reported problems are worked on, undercuts the good work that is being done and often doesn't allow the original reporter to test and provide feedback while the developers' memory regarding the changes is fresh...

From somewhere in the middle of 6.47 beta:
*) discovery - do not send discovery packets on inactive bonding slave interfaces;
*) discovery - do not send discovery packets on interfaces that are blocked by STP;

mbfound · Mon Jun 01, 2020 11:53 am

*) wireless - fixed Nstreme wireless protocol performance decrease;

there was problem with Nstreme wireless protocol?
since when?

Would also like to know? Have only been around since N days. One link I could test showed no difference.

ganewbie · Mon Jun 01, 2020 2:40 pm

*) wireless - fixed Nstreme wireless protocol performance decrease;

there was problem with Nstreme wireless protocol?
since when?
Would also like to know? Have only been around since N days. One link I could test showed no difference.

Well, since there is no detail on this, I can share our experience of 5 Km PtP Nstream. There is infrequent disconnection that we cannot explain. We tried to move to NV2 when possible but sometimes in the past Nstream would have given better throughput. Not sure if this is related or not.

Cha0s · Mon Jun 01, 2020 2:59 pm

I didn't notice any difference on an 802.11n Nstreme link that I tried 6.47rc2 on.
But it was working fine before anyway.

The general problem with Nstreme, since 802.11n, is that it keeps disconnecting for no apparent reason.
"Polling timeout" IIRC.

When it works OK (clean frequency and biting your tongue the right way) it can even outperform NV2.
You get "0 to 100" in less than a second, while on NV2 the bandwidth slowly climbs to the maximum.
Also the latency is much lower (0.5-0.6ms compared to 2+ms of NV2).

In general, NV2 is mediocre (compared to other TDMA implementations) and not suitable for PtP links.
Especially when you go over multiple NV2 hops, the performance can be atrocious!

astons2 · Mon Jun 01, 2020 11:31 pm

*) wireless - fixed Nstreme wireless protocol performance decrease;

Not all Microtik devices are affected with this problem. As far I know problem was with LHG5 ac version. Issue was with data throughput speed which was around 100mbs even if link could do much better than that. (in my case around 180mbs). In data monitor you could see something like waves, data speed goes up and down ... When you start test speed was almost ok but after a second or two speed decrease and those waves starts ... This problem was present from all versions 6.46.x everything was fine with all versions 6.45.x

Sob · Tue Jun 02, 2020 2:24 am

One more problem with SOCKS. Since requests to connect to hostname are now supported, I expected this to work:

/ip socks
set enabled=yes version=5
/ip socks access
add action=allow dst-address=mikrotik.com
add action=deny

But it doesn't:

socks5acl.png

buset1974 · Tue Jun 02, 2020 4:53 am

any new regarding system-auto-upgrade that has been broken since 6.46?
it's working fine on long-term version 6.45.9

thx

emils · Tue Jun 02, 2020 2:29 pm

New version 6.47 has been released in stable RouterOS channel:

viewtopic.php?f=21&t=161887

Who is online