*) ccr1072 - fix traffic halting when sfp+ 1-4 or 5-8 where all disabled;
*) chr - fixed crash when layer7 firewall option used;
*) fetch - fixed TTFP download;
*) gre - fixed memory leak;
*) lcd - fixed security screen did not show ip addresses on ccr;
*) netinstall - fixed link negotiation for different sfp modules;
*) ppp - fixed ppp crash;
*) queue-tree - improved nested queue limit calculation;
*) ssh - fixed crash on failed scp read;
*) winbox - allow to set multiple dh-groups;
*) winbox - do not show fan statuses in passive cooling CCR1009;
*) winbox - fixed typo in “echo reply”;
*) winbox - fixed unset options in /routing ospf interface menu.
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
Don’t know about this version but yesterday played with a ROS v.6.33.2 running rb1100AHx2’s ventilator setting and found I could set temp treshold setting and something else that after an upgrade to 6.34.2 (so presumably also 6.34.3) is not possible anymore…
Since I see the winbox fix in regarding the fan statuses info it might be an idea to check all fan related issues…?
Update problem.
Given:
mAP lite 6.34.2, latest FW 3.29
Config very basic, just bridge ether1 and wlan1 and dhcp client on bridge1.
PROBLEM:
After standard update procedure ( packages update via winbox 3.1) from 6.34.2 to 6.34.3 mAP lite does not accept DHCP server offered address. (i general any address)
I also noticed that DHCP is being offered to another MAC address than originally as i had it reserved.
Original: 4C:5E:0C:14:58:61
After update requested from/offered to: 4C:5E:0C:14:58:60
Cannot access AP now to pull the plug and verify solution on second mAP lite
Solution:
Unplug and plug back LAN cable into mAP lite.
I had this issue with 2 mAPlite’s
Beware of doing this update if you cannot access mAPlite physically to unplug/plug LAN cable.
CCR1036-12G-4S after update to v6.34.3 lost all IPSec settings.
Configuration is empty, even default values.
Also is not possible to create new IPSec config using Winbox, SSH or terminal
Terminal gives output:
action timed out - try again, if error continues contact MikroTik support and send
a supout file (13)
EDIT: After router restart everything is OK. EDIT2: After 18 hours of work same situation , all of IPSec settings disappeared and all VPN tunnels don’t work.
6.34.3 made about 30 seconds on my office MikroTik CRS-125 unit. Installed it, rebooted and connected to ADSL2+ as expected, but the vast majority of websites would not load (including Microsoft sites, all Mikrotik websites including this forum site and even https://thunderbolttechnology.net/blog/thunderbolt-3-usb-c-does-it-all) and various apps worked whereas others failed (Remote desktop worked, Dropbox was working, Skype for Business would not connect, Skype, however, connected fine.
I performed a DNS cache flush with no change to the issues. I rebooted the MikroTik again with no improvement, so I downgraded to 6.34.2 and everything worked as before and as expected.
I’d strongly recommend people not use 6.34.3 if they like Internet connectivity and wait for the bugs to be fixed and 6.34.4 to be released.
You should rather create supout file and send it to support. It looks like some MTU problem maybe. Pity that you haven’t tried to remove the configuration and set up the router again.
I’ll also add to this that my Dude server (CHR, running virtualized on my network) which was working perfectly when the gateway CRS-125 was running 6.34.2 could not connect to the MikroTik site to check for updates when running 6.34.3 on my CRS-125, but immediately connected fine when I downgraded to 6.34.2.
Why would I want to remove the configuration and set up the router again? How would this be possible for the (numerous) MikroTik devices I support remotely?
I’m happy to reload 6.34.3 and create a supout file, then restore to 6.34.2 to send it - there’s no way I could send it whilst running 6.34.3 as the Internet connection is so unusable.
I’ll wait and see if Krisjanis wants the supout file and do this if it will help them.
I decided to do as you suggested now before waiting for Krisjanis to rise from his (no doubt well-deserved) slumber.
I have reloaded 6.34.3, seen the same issues, created and saved off a supout.rif file, then fondled the Max MTU settings and it now seems to be playing much better. I was previously using a Max MTU of 1464 which worked perfectly. I have since tried a few smaller ones and found that 1446 now at least allows the Internet connectivity to work again under 6.34.3.
And having a look at the supout.rif that was generated, it looks like there’s an issue with the Max MTU - most definitely - as it was set to “1500” in the supout.rif file which was not what I was previously using. So it looks like the PPP Max MTU in the upgrade process is changed from that which was set by the user. This is not good as it means that remotely updating routers may result in broken Internet connectivity and the inability to fix this remotely.
supout.rif only exports the first 2 * PPPoE CLIENT interfaces and therefore fails to show my active PPPoE CLIENT interface which happens to the the third in the list That makes supout.rif creation pretty damned useless.
Now, having said that, if I go back to 6.34.2 and set the Max MTU to 1446, my Internet connectivity is flaky. it is fine at 1464 (which is what it was running at previously). If I copy over the 6.34.3 package and upgrade, upon reboot the Max MTU is still set at 1446 and Internet connectivity is still flaky.
So it does look like an MTU issue, but the creation of the supout.rif file won’t help MikroTik diagnose the issue as it doesn’t actually generate enough of an output based on the actually configured interfaces to help them.
Krisjanis, can I suggest that you modify the code that creates the supout.rif file so that it actually exports the configuration of all defined interfaces, not just, for instance, the first 2 * pppoe-client interfaces? That would help you guys greatly when it comes to trying to diagnose issues through the supout.rif files. Also as previously discussed on another issue (ie, the memory leak in the CHR code that has since been fixed) saving some more log info into the supout.rif file would also be beneficial.
End result: I am running 6.34.2 here now and will continue to do so as it is more stable than 6.34.3 and I am not willing to run this upgrade on any client site using pppoe in case the pppoe connectivity issue discussed here and above rears its ugly head and takes them off the Internet.
HiltonT, there is never safe update. That’s why you are making the tests, no? And you are not doing any updates until you have positive reason for it, right? There is no justification to blindly install every new version that mikrotik produces. If you have time and resources to help mikrotik with beta testing, they are always happy to receive the supout from the bad situation together with the supout from the good situation and with as good description they might get from you. Mostly they are able to see and reproduce the problem and start to work on the correction. Sometimes it may happen that they are not able to reproduce the situation on their devices so they ask for access to your devices to see the problem directly and even to make the ros fine tuning directly on your devices / testing lab.
6.34.3 is in the “Current” channel. That’s not beta. I’m running a number of 6.35 RC systems which are the “Release Candidate” channel and expect different issues with those - and am communicating with MikroTik on various issues found and fixed in the Release Candidate channel. I don’t expect “this release breaks your Internet connection” issues with “current” releases.
Production users/systems should not be the unknowing beta testers for a commercial company.
This is the point of view difference. I consider everything to be beta. When I think I need to update, I make my own tests In my lab and then deploying very carefully to reachable devices first. Once on twice per year.
You don’t seem to be an experienced person working for a long time in the industry…
I’ll give you an example not related to Mikrotik products at all. I’m currently working for a company developing database-related software product. When it comes to upgrade, most of our customers do internal testing on their dev/QA environment, then move to UAT environment and do even more testing, then finally deploy it to production environment. Testing usually takes weeks (sometimes a couple of months). And the bigger the customer, the longer and more pedantic testing they perform. Even if there’s a real issue on production, and the upgrade is from one minor version to the following minor version with the only bugfix solving their specific problem, they will always ask a support for a possible workaround, and still go the full cycle of internal testing. And this approach is not specific to how they handle our product, such approach is considered a best practice for any kind of software product in use.
Back to Mikrotik. RouterOS is so versatile that it is not really possible to test each and every configuration before the release. You should NEVER expect your particular configuration to work flawlessly with a particular version of RouterOS. ALWAYS test first before the upgrade; test it twice when it comes to a core devices in your network.
, all of IPSec settings disappeared and all VPN tunnels don’t work.