*) nand - implemented once a week nand refresh to improve stored data integrity *) nand - improved nand refresh feature to enhance stored data integrity
Why dont you add an option to turn on/ off those features introduced in 6.35 rc 43 and 6.36 rc 7?
Merry Christmas!
Wasn’t such feature implemented some time ago already? Reinventing a wheel…
Exactly!
Can I have more info about that ? Thank you.
Anyone experiencing mangle problems on 6.38rc52? I’ll elaborate:
Problem started approximately one day after I replaced some configuration on a RB2011 to a hEX v3. Mangle is pretty simple, chain prerouting from a vlan with action mark routing. Today it stopped working and I can’t seem to find the problem, double checked NAT/Firewall/routes and nothing, only strange thing is I find lots of “time wait” TCP States on connections. Testing speed, latency and upload is ok, but download shows error.
Interesting thing is that the error occurs in this network where I have a route to the ISP modem, but If I route it to a PPPoE connection, it works fine. Can’t put that modem in bridge though, and tested connection directly to the modem, or without the mangle and works fine.
Let me know if I haven’t made myself clear, but any help is appreciated.
Well, I’ve had a similar issue somewhere in this RC at 2016-12-02.
The following NAT rules were passed.
This was fixed by disabling and enabling the concerend rules a single time.
(As the firewall rules filter on connection state dstnat, the traffic couldn’t get through)
/ip firewall nat
add action=dst-nat chain=dstnat comment="Translate Exchange" dst-address=10.0.0.32 \
protocol=tcp src-address=192.168.89.0/24 to-ports=444
add action=dst-nat chain=dstnat comment="Translate WWW" dst-address=10.0.0.5 \
protocol=tcp src-address=192.168.89.0/24 to-ports=80
I’ve downgraded and re-upgraded several times but couldn’t reproduce the issue therefore did not report it.
This is not mangle related, but also concerns connection tracking. Could you try disabling / enabling the mangle rules and check the outcome? Perhaps create a backup and/or supout.rif before if it has effect for support ticket purposes.
Thanks for the quick response. I’ve certainly disabled and enabled the rules during the troubleshooting, but not sure if tested without altering anything else. Will do first thing on the afternoon and send the supout to support anyway, since I’m not the first with similar issues, maybe it’s not something I’m doing wrong.
Will try disabling the related nat and firewall rules too, just in case.
When you add NAT rules for traffic that is already flowing, the NAT rule will not be triggered anymore
because the established session will pre-empt that. Same reason why the NAT rule onlu counts
the first packet of every session (some people wonder why the counters on NAT rules are so low).
When this leads to confusing situations, it is best to reboot the router.
are there plans to add NAT for IPv6 ?
at home i have dynamic ipv6 from the provider and a static ipv6 net with no flatrate at tunnelprovider.
the simplest solution is to NAT unknown networks und known networks without NAT for static firewall config.
Now that I installed the 6.38rc on my home router, I notice a new problem in the WebFig:
The AS number for a BGP peer is displayed as a signed value. AS values that are near to the 32-bit unsigned limit (i.e. the Private AS range 4200000000 - 4294967294) are incorrectly displayed as negative numbers.
This is unfortunate as we widely use these AS numbers in our HAMNET network.
This is the third bug in WebFig in 6.38RC that I encounter and that appears to be related to signed/unsigned handling.
I think an investigation into possible further issues similar to this is in order. It appears some datatype change has been made that is not correct or not well tested for consequences.
As mentioned in other threads there still is an issue with DHCPv6 PD in certain scenarios.
My provider uses DHCPv6 PD to assign IPv6 addresses, the lease has a 2 hour lifetime but it becomes invalid when the PPPoE session is closed.
While everything works OK in RouterOS with a DHCPv6 client configured on the PPPoE interface, unfortunately the router stores the obtained
lease and does not track the down-status of PPPoE. When the link has been reset or the modem is rebooted, the existing lease is used but
the provider does not route IPv6 until a new lease is obtained. It recovers at the end of the 2 hour lifetime period or when a RELEASE is done,
but it would be preferable when a new lease is requested automatically whenever:
As I understand that in some other cases this behavior may not be optimal or be considered nonstandard, maybe an option could be
added to the DHCPv6 client such that it:
Or alternatively: provide a mechanism to run a script whenever a PPPoE link comes up, so I can put this command into that:
/ipv6 dhcp-client release [find status=bound]
That fixes the problem immediately…
Version 6.39rc has been released:
http://forum.mikrotik.com/t/v6-39rc-release-candidate-is-released/104800/1