*) sfp - fixed "rate" monitor value for SFP interface on L009UiGS series devices; *) sfp - fixed combo-ether link monitor for CRS328-4C-20S-4S+ switch; *) sfp - fixed combo-sfp linking at 1G rate for CRS312 switch; *) sfp - improved 10G interface stability for 98DX8208, 98DX8212, 98DX8332...

Same here. Since today, same symptoms, with ROS 7.5

Technical details of the worm here : https://blog.talosintelligence.com/2018 ... ilter.html

Ok thx for informations

Well what happens is that : If I say I use SLAAC (managed=0) My Windows hosts uses SLAAC just all right, but has no DNS If I say I use SLAAC (managed=0) and want to provide DNS throught DHCPV6 (other=1) My Windows hosts uses SLAAC just all right, but still has no DNS : it performs no DHCPV6 request ...

With SLAAC , it works

I have the same configuration yes :-p

That's what I do , but my Windows client asks for an address , even if I say that I use SLAAC. And it won't get an adress through DHCP , thus it stucks at renewing its IPV6.

Windows 8.1 is the target.

Strange, doesn't work for me. I get in the mkt logs "handling only prefix delegation discarding" , Mkt seems to only delegate prefix through DHCP, no IA for single stations. I can't make DHCPV6-server work for hosts (tried Windows host) , and I can't make DNS pass through DHCP for Windows ...

Hi. What about OVPN stopping to work in 6.40.3 ? I made some investigations, and have my OVPN work back now. OVPN clients on PC log that certificate expired, which obviously is not true (worked in 6.40.2 , as a reminder. And certificates dates are OK, obviously). To make them work again, I had to se...

Hi, after upgrading, I can't connect my OVPN tunnels any more. It says "TLS failed" in log messages. From 6.40.2 (client) to 6.40.3 (server) and from 6.40.3 (client) to 6.40.3 (server) , impossible. I'm OVPN server with CCR1009-7G-1C-1S+ and got different ROS clients , one being a 2011UAS-...

The prefer-source is only set on connected routes, not on any static one.

Another torch here that seems to show a problem.

Requests from ROS (output) select an interface to get out, but don't select the right source IP.

Aka, I can see DNS requests from ROS leaving from WAN1 , but having as source IP the one of WAN2 , and opposite.

Pretty strange.

Packets are already masqueraded when they leave using a private src-addr , so they get translated

My INPUT is correct because I can make it work by forcing DNS to bypass ECMP. Then all is right in such a case.

I have an Accept Established-related on INPUT.

You're right on this, I was just pointing out that there are scenarios (if you were to provide any service from the mikrotik router to the Internet, or dst-nat internal servers) where you need to keep track even on the output chain. Yes I know, I already did that for incoming traffic , to let the a...

mmmm , I still dont get it. In my case, RouterOS doesn't answer anyone. It doesn't answer an incoming request coming from WANs. It issues itself a DNS request to a DNS forwarder, using ECMP WANs as output So for this, it will output a packet to some DNS forwarder. This packet will be ECMP'ed , it wi...

No I did not. But the prefer source is filled-in for connected routes. Aka : flags dst addr gateway pref.source AS 0.0.0.0/0 1.2.3.4, 4.5.6.7 DAC 1.2.3.1/24 eth10 1.2.3.4 DAC 4.5.6.1/24 eth9 4.5.6.7

Traffic for input , needs mangle tracking , so that the answer takes the same route as the source packet. I agree , but this is not my actual problem. Why would it need some rules for output traffic ? Output traffic should just get generated, then be routed like any other traffic (forward traffic f....

No provider-locked DNS.
Only public ones as IPs , like 8.8.8.8 etc...

Just adding a +1 to say that I would be delighted to see MPTCP support added to RouterOS.

Hi everyone. I experimented ECMP yesterday, and I think I did hit a bug in RouterOS. The setup is really simple. I'm talking IPV4 here. I got 2 ISP , so I added one default 0.0.0.0 route with two gateways. src-NAT at the end, and we are done. Manual add as static routes, no routing protocol involved...