MikroTik

Posted: **Mon Apr 23, 2018 3:22 pm**

RouterOS version 6.42.1 has been released in public "current" channel!

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.42.1 (2018-Apr-23 10:46):

!) winbox - fixed vulnerability that allowed to gain access to an unsecured router;
*) bridge - fixed hardware offloading for MMIPS and PPC devices;
*) bridge - fixed LLDP packet receiving;
*) crs3xx - fixed failing connections through bonding in bridge;
*) ike2 - use "policy-template-group" parameter when picking proposal as initiator;
*) led - added "dark-mode" functionality for hAP ac and hAP ac^2 devices;
*) led - improved w60g alignment trigger;
*) lte - allow to send "at-chat" command over disabled LTE interface;
*) routerboard - fixed "mode-button" support on hAP lite r2 devices;
*) w60g - allow to manually set "tx-sector" value;
*) w60g - fixed incorrect RSSI readings;
*) w60g - show phy rate on "/interface w60g monitor" (CLI only);
*) winbox - fixed bridge port MAC learning parameter values;
*) winbox - show "Switch" menu on cAP ac devices;
*) winbox - show correct "Switch" menus on CRS328-24P-4S+;
*) wireless - improved compatibility with BCM chipset devices;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

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 some problem has appeared on device

Please keep this forum topic strictly related to this concrete RouterOS release.

Posted: **Mon Apr 23, 2018 4:18 pm**

Upgraded ROS and firmware on RB2011, all seems ok, will continue checking / testing

Posted: **Mon Apr 23, 2018 4:24 pm**

I have updated one 3011 and two CHR (Hyper-V) and so far so good. Took the ones that have a public IP first.
Don't think this was a problem for me though as I block anyone, for 30 days, coming from internet trying to connect to Winbox port.

Posted: **Mon Apr 23, 2018 4:49 pm**

Could You explain: winbox - fixed vulnerability that allowed to gain access to an unsecured router - please?
What do You mean "unsecured router"? All versions under 6.42.1 are affected?

Posted: **Mon Apr 23, 2018 4:53 pm**

@rzirzi
viewtopic.php?f=21&t=133533

Posted: **Mon Apr 23, 2018 4:57 pm**

And implement "security fix" in 6.40.7 PLEASE!!!!!

Posted: **Mon Apr 23, 2018 4:57 pm**

And implement "security fix" in 6.40.7 PLEASE!!!!!

coming next

Posted: **Mon Apr 23, 2018 5:40 pm**

Upgrade one RB750Gr3, and three hAP AC Lite (one of them used as CPE). All fine and dandy. The first reboot took a little longer than what I'm used to, but nothing to write home about.

Posted: **Mon Apr 23, 2018 5:44 pm**

upgraded RB750, RB962 (8pc), RB1100, RB2011, CRS125, CHR, CHR (dude) without issues, tnx for the fast fix !

Posted: **Mon Apr 23, 2018 6:20 pm**

No issues across my mix of devices (RB750Gr3, wAP AC, hAP AC, RB951).

Posted: **Mon Apr 23, 2018 9:39 pm**

CHR - Microsoft AZURE :

After reboot VM works fine, 2 hour later can't get IP address from DHCP server, static IP don't working, enable/disable iface/ dhcp client - without sucess. Reboot can temporarily fix this problem.

Posted: **Mon Apr 23, 2018 10:01 pm**

RB 750G v3

Here is my experience in upgrading from 6.41.3 to 6.42.1
Package, find new package, download , install and reboot.
This works fine. Software is up on 6.42.1
It takes about 2 min to upgrade

Then I go to routerboard.
Current Firmware 6.41.3
Upgrade Firmware 6.42.1
Click Upgrade
Do you really want to upgrade firmware? OK
Nothing happens. no information, no new version.

Manual reboot (around 40 seconds)
Current Firmware 6.42.1
Upgrade Firmware 6.42.1

For me this i a broken hardware upgrade, or at missing some in the process.
Do I need to upgrade hw in the rouerboard menu, or it need just another reboot?
Why does it not reboot and tell me that hw is doing an upgrade when click the upgrade menu in routerboard menu?

PS, seen this with other upgrade version as well

Posted: **Mon Apr 23, 2018 10:15 pm**

The information is in the LOG. The update versions are just cosmetic. You can't if there was anything changed in the firmware anymore.

I never understood why Mikrotk choose to sync the version of the firmware and RouterOS.

Posted: **Mon Apr 23, 2018 10:21 pm**

The same with missing line in log "Firmware upgraded successfully, please reboot for changes to take effect!" happened to me today on RB951G-2HnD.
Little scary on 50km away device

Did the upgrade failed? Should I reboot or better not?
Anyway I sent the reboot command - and all seems fine - after reboot is firmware upgraded to 6.42.1.

Posted: **Mon Apr 23, 2018 10:34 pm**

Upgraded RB2011UiAS-2hND, new hAP Lite, RB951Ui, CCR125 without any issues.

Sent from my C6833 using Tapatalk

Posted: **Mon Apr 23, 2018 10:50 pm**

still waiting for the bugfix only update

Posted: **Tue Apr 24, 2018 12:48 am**

Updated several RB2011UiAS-2HnD, RB1100Dx4 and hAP ac (also lite version) and so far everything looks ok.

In addition to previous messages in this thread, while updating firmware, all RBs wrote "Firmware updated, please reboot to take effect!" message in log.

Posted: **Tue Apr 24, 2018 2:31 am**

still waiting for the bugfix only update

This vulnerability isn't much of a problem. The problem is administrators leaving their firewall services (API, Winbox, SSH, etc.) exposed to untrusted networks. It's better to apply firewall filters to the input chain that will protect against this and other future attacks.

Posted: **Tue Apr 24, 2018 2:32 am**

Edit: Duplicate post.

Posted: **Tue Apr 24, 2018 4:09 am**

still waiting for the bugfix only update

still waiting ...

Posted: **Tue Apr 24, 2018 4:18 am**

CHR - Microsoft AZURE :

After reboot VM works fine, 2 hour later can't get IP address from DHCP server, static IP don't working, enable/disable iface/ dhcp client - without sucess. Reboot can temporarily fix this problem.

Might be same issue for you.

We started rolling it out for security sake. 1/3 of flashed routers lose internet/IP
We found that DHCP server (which is on bridge) goes to "unknown" and goes red
Also, under bridge ports, random ports will also go to "unknown"

Changing those back to correct settings restores all service

Posted: **Tue Apr 24, 2018 4:44 am**

CHR - Microsoft AZURE :

After reboot VM works fine, 2 hour later can't get IP address from DHCP server, static IP don't working, enable/disable iface/ dhcp client - without sucess. Reboot can temporarily fix this problem.
Might be same issue for you.

We started rolling it out for security sake. 1/3 of flashed routers lose internet/IP
We found that DHCP server (which is on bridge) goes to "unknown" and goes red
Also, under bridge ports, random ports will also go to "unknown"

Changing those back to correct settings restores all service

routeros 6.41+ have new implementation of bridges beware of that change

because that we need 6.40.x fixed version to update without the issues on bridge for in production rotuers with many vlans on bridges until shedule a maintenance windows to upgrade una controlled time without service disruption

Posted: **Tue Apr 24, 2018 5:39 am**

I'm in a rural location and going through 3 different mikrotik radios to hook into our local WISP. All were on 6.41.3 and I've upgraded them to 6.42.1 now. However, the final client radio link that is setup as a bridge seems to be having all kinds of problems. After upgrading, when I try to access via winbox it the logs are all empty and the whole winbox interface is unresponsive. On top of that I'm having huge issues with outbound web and ftp traffic? It's a little hard to tell what is going on because I know the WISP has implemented some aggressive firewall blacklist rules until they can patch-up all their mikrotik gear.

Is it possible my issue is the routeros upgrade from 6.41.3 to 6.42.1? Everything went really pear shaped after I patched, but their could have been changes in the network core happening at the same time.

Posted: **Tue Apr 24, 2018 7:27 am**

BartoszP, chechito - We will release 6.40.8 as soon as possible. As we just yesterday found out about this vulnerability, we were lucky that 6.42.1 was already on the way. In order to release a version, we have to test it first. 6.40.8 is coming, but will take most likely one or two days. I assume that no one here wants to install un-tested bugfix version on their routers

miro263, skullzaflare, sspratt - Please generate supout file on your device while problem is present. Send this file to support@mikrotik.com.
Jotne, msatter, Pea, Kraken2k - This is how RouterBOOT upgrade been working since always. You need to reboot device manually after you have performed upgrade feature. Since RouterBOOT mainly is responsible for booting process we do not want to make fully automatical RouterBOOT upgrade process or force it because it rarely has any updates for already released products and automated upgrade/reboot might lead up to more problems than bring anything good into equation. However, if you want to forget about firmware, then you can enable auto-upgrade feature and RouterBOOT will upgrade itself upon the next reboot when RouterOS will be upgraded - RouterOS upgrade, reboot, one more reboot in order to upgrade RouterBOOT.

Posted: **Tue Apr 24, 2018 8:06 am**

Jotne, msatter, Pea, Kraken2k - This is how RouterBOOT upgrade been working since always. You need to reboot device manually after you have performed upgrade feature. Since RouterBOOT mainly is responsible for booting process we do not want to make fully automatical RouterBOOT upgrade process or force it because it rarely has any updates for already released products and automated upgrade/reboot might lead up to more problems than bring anything good into equation. However, if you want to forget about firmware, then you can enable auto-upgrade feature and RouterBOOT will upgrade itself upon the next reboot when RouterOS will be upgraded - RouterOS upgrade, reboot, one more reboot in order to upgrade RouterBOOT.

Then why not give more information about that in the routerboard settings. You know how it works so you do not need such information, I know it now, but for all other that click the upgrade button to sync the firmware it will remain a mystery. Just add som words what to do will help others.

Posted: **Tue Apr 24, 2018 8:26 am**

Warnings are already there. Can you provide screen shot where we can see that the warning is missing?

Screen Shot 2018-04-24 at 08.24.59.png

Posted: **Tue Apr 24, 2018 8:58 am**

Warnings are already there. Can you provide screen shot where we can see that the warning is missing?

Not in WebFig. I have upgraded two hap ac2 yesterday to 6.43rc4 and nothing visible happened on pressing the "upgrade firmware" button in System->Routerboatd (done that with 6.43rc4 already running to be clear, and after reboot, the new firmware is shown as running). Overlay windows do indicate errors like "cannot connect, scan is not running" in wireless configuration, so it should not be a browser incompatibility.

Posted: **Tue Apr 24, 2018 9:22 am**

I've updated a CCR1036 from 6.42 to 6.42.1 and webfig now only works on one of two configured IP addresses on the same interface.
Edit: Solved and not related to the update.

Posted: **Tue Apr 24, 2018 9:25 am**

Hi strods, this happened for the first time that log message about upgrade was missing completely.
Unfortunately all my devices are upgraded already, so I cannot check if the warning was in System/Routerboard/Settings.
But it was definitely missing in log.

Now if I look into terminal I still see 2 lines (I pressed Upgrade button twice

). But this should not be there while the router was already rebooted, right?

Posted: **Tue Apr 24, 2018 10:03 am**

Now if I look into terminal I still see 2 lines (I pressed Upgrade button twice ). But this should not be there while the router was already rebooted, right?

I think this is expected. You installed the firmware upgrade and rebooted without opening the terminal. Critical messages are stored to be shown the next time you open the terminal, that was after reboot.

If you open the terminal before reboot you will not see these messages after reboot.

Posted: **Tue Apr 24, 2018 10:28 am**

Just updated one of our Metal G-52SHPacn to new v6.42.1 RouterOS.

tools/netwatch does not work anymore. When the tested server is "up", we run [:global srvstat "up"] to set the variable srvstat. Did work with 6.41.2
Looks like up event is not working.

Posted: **Tue Apr 24, 2018 10:33 am**

Just updated one of our Metal G-52SHPacn to new v6.42.1 RouterOS.

tools/netwatch does not work anymore. When the tested server is "up", we run [:global srvstat "up"] to set the variable srvstat. Did work with 6.41.2
Looks like up event is not working.

Version 6.42 has this changelog entry:

*) netwatch - limit to read, write, test and reboot policies for Netwatch script execution;

I guess that breaks your use case.

Posted: **Tue Apr 24, 2018 11:10 am**

LED problems：
[admin@911-1] > system leds set interface=wlan1 type=wireless-signal-strength
input does not match any value of type
[admin@911-1] > system leds set interface=wlan1 type=wireless-status
input does not match any value of type
[admin@911-1] >

Posted: **Tue Apr 24, 2018 11:24 am**

Just updated one of our Metal G-52SHPacn to new v6.42.1 RouterOS.

tools/netwatch does not work anymore. When the tested server is "up", we run [:global srvstat "up"] to set the variable srvstat. Did work with 6.41.2
Looks like up event is not working.
Version 6.42 has this changelog entry:
Code: Select all
*) netwatch - limit to read, write, test and reboot policies for Netwatch script execution;
I guess that breaks your use case.

Yes, netwatch is no longer usable to start scripts. Even to write to global variables fails. Only write to .txt files works. On up event, I need to write the server status up to a variable or file and start a script.

Still did not find a solution for that use. A high interval schedule is no option.

Posted: **Tue Apr 24, 2018 11:37 am**

Warnings are already there. Can you provide screen shot where we can see that the warning is missing?

Screen Shot 2018-04-24 at 08.24.59.png

This boggles my mind...

In Winbox you can see the message the firmware is upgraded but you will have to first open the window Settings to see that. Why not display it in the Routerboard window where you initiate the upgrade???

Now you think did I click that Upgrade button or not because nothing happened..and click again and again...

Posted: **Tue Apr 24, 2018 11:58 am**

Now that the firmware has the same version as RouterOS, and assuming that not every update to RouterOS really includes
a changed firmware version, maybe something can be done to change the warning after the firmware update so that it
does not require a reboot when nothing other than the version has changed?
As it is now, every update requires two reboots, and in many cases (e.g. when updating from 6.42 to 6.42.1) that is likely
not very necessary.

Posted: **Tue Apr 24, 2018 12:42 pm**

LED problems：
[admin@911-1] > system leds set interface=wlan1 type=wireless-signal-strength
input does not match any value of type
[admin@911-1] > system leds set interface=wlan1 type=wireless-status
input does not match any value of type
[admin@911-1] >

Maybe your problem is that you haven't specified which LED? Don't know what hardware you are using, so don't know how many LEDs there are.

Posted: **Tue Apr 24, 2018 1:04 pm**

Not related to Winbox security issue, but seems like a bug ...
On 6.41.x and 6.42.x MNDP trafic is not visible anymore in firewall output chain ...
For example I am using this rules

/ip firewall raw> print 
Flags: X - disabled, I - invalid, D - dynamic
 0    chain=output action=passthrough log=yes log-prefix="" protocol=udp
 1    ;;; MT discovery
      chain=prerouting action=notrack dst-port=5678 log=no log-prefix="" protocol=udp dst-address=255.255.255.255 
 2    ;;; MT discovery
      chain=output action=notrack dst-port=5678 log=no log-prefix="" protocol=udp dst-address=255.255.255.255

And on 6.40.x it works as expected

print stats
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                                                                                                                                                                         ACTION                            BYTES         PACKETS
 0  D ;;; special dummy rule to show fasttrack counters
      prerouting                                                                                                                                                                                    passthrough                  55 903 342         279 167
 1    prerouting                                                                                                                                                                                    notrack                         295 008           2 176
 2    output                                                                                                                                                                                        notrack                          25 870             195

But on 6.41.x and 6.42.x no packet is ever detected in output chain

 print stats
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                                                                                                                                                                         ACTION                            BYTES         PACKETS
 0    output                                                                                                                                                                                        passthrough                     226 965           1 663
 1    ;;; MT discovery
      prerouting                                                                                                                                                                                    notrack                          99 706             724
 2    ;;; MT discovery
      output                                                                                                                                                                                        notrack                               0               0

So is this some undocumented new feature and if so what is the benefit, or is it just a bug?

Regards

Posted: **Tue Apr 24, 2018 2:06 pm**

Now that the firmware has the same version as RouterOS, and assuming that not every update to RouterOS really includes a changed firmware version, maybe something can be done to change the warning after the firmware update so that it does not require a reboot when nothing other than the version has changed?
As it is now, every update requires two reboots, and in many cases (e.g. when updating from 6.42 to 6.42.1) that is likely
not very necessary.

Excellent thought and in the release notes it should also state that the firmware is updated and that a upgrade is recommended. If nothing has changed then always as last line in release notes: "- no firmware upgrade needed when you current firmware is x.xx.x or higher."

If Mikrotik don't want to go trough this administration then consider to only increase the firmware revision when it is updated. So lastest firmware can be 6.41.4 and the RouterOS version could be 6.42.1.

Being cosmetic, it could also sync with RouterOS version without the user knowing. On downgrade it will show the sync or downgrade automatically like is the case now if I remember that correctly.

Posted: **Tue Apr 24, 2018 2:11 pm**

How to disable dynamic dhcp client on LTE links?

 /ip dhcp-client print detail 
Flags: X - disabled, I - invalid, D - dynamic 
 0 D interface=lte1 add-default-route=yes default-route-distance=2 use-peer-dns=yes use-peer-ntp=yes dhcp-options=hostname,clientid 
     status=error dhcp-server=192.168.8.1

Leaving as above with static address on lte interface (i need static rules for routing with marks) will generate a lot of errors in logs
"dhcp-client on lte1 failed to add IP address 192.168.8.100: already have such address (6)"

Adding a disabled rule does not block the creation of a dynamic entry.

/ip dhcp-client print detail 
Flags: X - disabled, I - invalid, D - dynamic 
 0 XI interface=lte1 add-default-route=yes default-route-distance=2 use-peer-dns=no use-peer-ntp=no dhcp-options=hostname,clientid 

 1 ID interface=lte1 add-default-route=yes default-route-distance=2 use-peer-dns=yes use-peer-ntp=yes dhcp-options=hostname,clientid

The modem is USB Huaweii E3372h hi-link mode

Posted: **Tue Apr 24, 2018 2:20 pm**

Excellent thought and in the release notes it should also state that the firmware is updated and that a upgrade is recommended. If nothing has changed then always as last line in release notes: "- no firmware upgrade needed when you current firmware is x.xx.x or higher."

Or maybe in the routerboard firmware update screen it could show if the firmware version in the current RouterOS is binary different from the currently installed firmware (excluding version number) and show a message near the upgrade button that upgrade is advised / not necessary.

Posted: **Tue Apr 24, 2018 2:26 pm**

THIS FILTER ON BRIDGE IS NOT WORKING IN THIS VERSION

add action=drop chain=input no dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF

Posted: **Tue Apr 24, 2018 2:55 pm**

Excellent thought and in the release notes it should also state that the firmware is updated and that a upgrade is recommended. If nothing has changed then always as last line in release notes: "- no firmware upgrade needed when you current firmware is x.xx.x or higher."
Or maybe in the routerboard firmware update screen it could show if the firmware version in the current RouterOS is binary different from the currently installed firmware (excluding version number) and show a message near the upgrade button that upgrade is advised / not necessary.

Let's make it foolproof. Make the upgrade button inactive when there is no real upgrade or you executed already an upgrade and the router is waiting for a reboot.

A new button can be added to the settings window of the Routerboard window, with the text "Force Upgrade" so that is still possible if recommended by Mikrotik support.

Posted: **Tue Apr 24, 2018 4:05 pm**

Can we move this double reboot discussion to a separate thread plz...

Posted: **Tue Apr 24, 2018 5:27 pm**

Weird issue..

I went from 6.42 to 6.42.1

At some point in the 48 hours after doing this my scheduled scripts stopped running. None of them work. I saw this on a CCR1009-8G-1S-1S+

I had another partition running 6.42 on it and switched to that and everything is working again.. I will look more at the issue later in the day...

I can run the scripts manually fine. Its the scheduler that appears to have stopped..

Posted: **Tue Apr 24, 2018 5:34 pm**

Yea thats repeatable for me..

I take 6.41.3 in a partition and that works great.. Update it to 6.41.1 and the scheduler stops.. It might also be that Netwatch triggered scripts stopped too..

Posted: **Tue Apr 24, 2018 5:39 pm**

Some of my scripts are owned by a created user VS admin..

I will explore this more later. I will also explore this on other devices..

Posted: **Tue Apr 24, 2018 6:10 pm**

BartoszP, chechito - We will release 6.40.8 as soon as possible. As we just yesterday found out about this vulnerability, we were lucky that 6.42.1 was already on the way. In order to release a version, we have to test it first. 6.40.8 is coming, but will take most likely one or two days. I assume that no one here wants to install un-tested bugfix version on their routers
miro263, skullzaflare, sspratt - Please generate supout file on your device while problem is present. Send this file to support@mikrotik.com.
Jotne, msatter, Pea, Kraken2k - This is how RouterBOOT upgrade been working since always. You need to reboot device manually after you have performed upgrade feature. Since RouterBOOT mainly is responsible for booting process we do not want to make fully automatical RouterBOOT upgrade process or force it because it rarely has any updates for already released products and automated upgrade/reboot might lead up to more problems than bring anything good into equation. However, if you want to forget about firmware, then you can enable auto-upgrade feature and RouterBOOT will upgrade itself upon the next reboot when RouterOS will be upgraded - RouterOS upgrade, reboot, one more reboot in order to upgrade RouterBOOT.

thx for your response

and thx for releasing 6.40.8 so soon

Posted: **Tue Apr 24, 2018 6:23 pm**

Can we move this double reboot discussion to a separate thread plz...

More than we exchanged was the maximum we could put in from our side to Mikrotik. Unless it was mentioned again. Which you did.

Posted: **Tue Apr 24, 2018 7:52 pm**

Jotne, msatter, Pea, Kraken2k - This is how RouterBOOT upgrade been working since always. You need to reboot device manually after you have performed upgrade feature. Since RouterBOOT mainly is responsible for booting process we do not want to make fully automatical RouterBOOT upgrade process or force it because it rarely has any updates for already released products and automated upgrade/reboot might lead up to more problems than bring anything good into equation.

What has changed, is that now every new release of RouterOS the version of the RouterBOOT has incremented as well, even when RouterBOOT has not changed (most of the time!).
SO while before you just went to Routerboard and checked that the "upgrade version" is the same as the "installed version" and if so, just closed the window, NOW the "upgrade version" is always higher than the installed version, and you have to click upgrade and reboot an extra time. Even when actually nothing was updated.

However, if you want to forget about firmware, then you can enable auto-upgrade feature and RouterBOOT will upgrade itself upon the next reboot when RouterOS will be upgraded - RouterOS upgrade, reboot, one more reboot in order to upgrade RouterBOOT.

Ok, but please change it so that it requires the second reboot ONLY when there was actually an upgrade.
Maybe it would be better to change policy back to incrementing RouterBOOT version ONLY when there was a change.
The version numbers are now aligned, less confusing, so you can set the versions equal at any time when there is an actual update.

Posted: **Tue Apr 24, 2018 8:07 pm**

My PC Bios is not 10 as in Windows 10
Our Cisco 3650 switches at work is on Hw version 3.56 and IOS-XE is on 16.3.5b
I can make a long list where hw is not in sync with os.
But the list for where it is in sync will be short.

As of know, it's confusing and extra reboot for nothing?

Posted: **Tue Apr 24, 2018 8:13 pm**

pe1chl: yes, this is clear.
The report about problem in this version is due to missing feedback in log after pressing the Upgrade button.
This "Firmware upgraded successfully, please reboot for changes to take effect!" did not appear in log. And this is unusual.
This information line was always there after pressing the button but this time was missing. That is all.

Posted: **Tue Apr 24, 2018 10:26 pm**

stumbled upon a strange stuff after upgrade.

[me@hgw2] > /log print follow-only 
21:20:46 ssh,error Corrupt host's key, regenerating it! Reboot required!

it happens when i'm trying to access the router from my freebsd box

debug1: Local version string SSH-2.0-OpenSSH_7.2 FreeBSD-20160310
debug1: Remote protocol version 2.0, remote software version ROSSSH
debug1: no match: ROSSSH
debug1: Authenticating to 192.168.1.1:222 as 'me'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-dss
debug1: kex: server->client cipher: aes192-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes192-ctr MAC: hmac-sha2-256 compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
Received disconnect from 192.168.1.1 port 222:3: 
Disconnected from 192.168.1.1 port 222

whereas if i use my mac with a more recent SSH version, it just works. lucky me, otherwise i would be locked out.

debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version ROSSSH
debug1: no match: ROSSSH
debug1: Authenticating to 192.168.1.1:222 as 'me'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes192-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes192-ctr MAC: hmac-sha2-256 compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:N3zKod3ejAr1GLrtPPxf0ySdhQpwSVh3qo1tIdf88zU
debug1: Host '[192.168.1.1]:222' is known and matches the RSA host key.

the routerOS ssh config is as follows:

[me@hgw2] > /ip ssh print 
           forwarding-enabled: no
  always-allow-password-login: yes
                strong-crypto: yes
                host-key-size: 2048

and no, reboot doesn't fixes the stuff, opposed to what the log message states.

Posted: **Tue Apr 24, 2018 11:57 pm**

ARM upgrade from 6.42 to 6.42.1 will fail if another architecture package is also found on the flash... sometimes required to upgrade caps...

in the past it would upgrade correctly and just ignored the extra architecture packages. Is this a bug or just intentional now?

/system routerboard> /log print
22:41:35 system,info installed routeros-arm-6.42.1

/system resource print
uptime: 3m28s
version: 6.42 (stable)

Posted: **Wed Apr 25, 2018 12:27 am**

ARM upgrade from 6.42 to 6.42.1 will fail if another architecture package is also found on the flash... sometimes required to upgrade caps...

in the past it would upgrade correctly and just ignored the extra architecture packages. Is this a bug or just intentional now?

I haven't worked with caps, but working with /system upgrade I learned that if you put npks in a subfolder, they will show up as "available" for other MikroTiks to fetch to upgrade themselves, but will not appear as available to upgrade the host MikroTIk on reboot, nor be consumed in doing so. Perhaps if you put your caps npks in a subfolder, this would solve your issue.

Posted: **Wed Apr 25, 2018 2:01 am**

Just updated my RB2011UiAS-RM to 6.42.1
After updating and rebooting I go back and check for updates, it shows 6.42 instead of 6.42.1, this does not happen on any of my other routers.

Capture.PNG

Posted: **Wed Apr 25, 2018 3:24 am**

Just updated one of our Metal G-52SHPacn to new v6.42.1 RouterOS.

tools/netwatch does not work anymore. When the tested server is "up", we run [:global srvstat "up"] to set the variable srvstat. Did work with 6.41.2
Looks like up event is not working.
Version 6.42 has this changelog entry:
Code: Select all
*) netwatch - limit to read, write, test and reboot policies for Netwatch script execution;
I guess that breaks your use case.
Yes, netwatch is no longer usable to start scripts. Even to write to global variables fails. Only write to .txt files works. On up event, I need to write the server status up to a variable or file and start a script.

Still did not find a solution for that use. A high interval schedule is no option.

I haven't installed 6.42.x yet but I use Netwatch to run scripts on all my devices. I use local variables in these scripts, will they no longer work after this update?

Posted: **Wed Apr 25, 2018 3:50 am**

EoIP Ethernet Frame issue is still there (introduced in 6.42 breaking fragmenting big frames somehow broken) verified on RB2011 and sent supout to MT-support.

Posted: **Wed Apr 25, 2018 4:59 am**

I wanted to follow up... Yes my Netwatch is not working.. This is really annoying as its sets up my DDNS. we need a 42.2 that fixes this..

Im not sure what happened last night, but, somehow none of my scripts would run from scheduler. I could run them manually. Its like scheduler somehow was not running, or did not have permissions to run scripts.. I always use 2 partitions and flipped back to 41.3 and all was well. Netwatch also worked of course.

I copied over 41.3, overwriting the 42.1.. Then switched to that.. All was well.. Then upgraded 41.3 to 42.1.. I lost Netwatch but gained back scheduler.

Ive gained a even weirder issue... I cant get around this...

/system leds> add leds=user-led type=on
input does not match any value of type

I can do off,,, but not on.. It seems to have lost on...

Posted: **Wed Apr 25, 2018 5:30 am**

I can get on from Winbox,,, just not from command line or scripting..

Posted: **Wed Apr 25, 2018 7:46 am**

Im not sure what happened last night, but, somehow none of my scripts would run from scheduler. I could run them manually. Its like scheduler somehow was not running, or did not have permissions to run scripts.. I always use 2 partitions and flipped back to 41.3 and all was well.

You know, I’ve been working with Support on an issue exactly like this. I have discovered that scheduler will often not start a script anymore if you just use the name of the script in the action, but if you say /system script run scriptname, it runs fine. Try that.

Posted: **Wed Apr 25, 2018 7:49 am**

This change to Netwatch MUST BE REVERSED... Im REAALY UNHAPPY... I use this for a great many things. This change in what it can run seems, well, STUPID and POORLY THOUGHT OUT.. Mikrotik can't just take away features like that.

I cant even imagine a reason to do that.

Put this back ASAP or im gonna be REALLY VOCAL about this.

If your going to take away this big a feature that has been present in RouterOS for so many years at least provide a rationale for implimenting such a devastating reduction in functionality.

Posted: **Wed Apr 25, 2018 7:50 am**

Im not sure what happened last night, but, somehow none of my scripts would run from scheduler. I could run them manually. Its like scheduler somehow was not running, or did not have permissions to run scripts.. I always use 2 partitions and flipped back to 41.3 and all was well.
You know, I’ve been working with Support on an issue exactly like this. I have discovered that scheduler will often not start a script anymore if you just use the name of the script in the action, but if you say /system script run scriptname, it runs fine. Try that.

I will... Thank you

Posted: **Wed Apr 25, 2018 8:52 am**

We have two 912UAG-5HPnD in bridged configuration. All of them was upgraded yesterday from 41.4. Until the upgrade, i could switch between nv2 and Nstreme protocol without problems (the Nstreme is faster but high packet losses, I always try after upgrades with Nstreme if there is any changes with packet losses, and then I switch back to NV2).
After upgrade, when I tried to switch to Nstreme on local AP, the webfig connection lost (local side, with UTP cable between AP and local router), and I could not ping from the router the local AP's IP address (the Layer2 connection seemed to be OK, there was Ethernet link, connected with 1GBps). After a power cycle and 5-10 minutes the network came back and the AP was reachable. I tried to switch back to NV2, but the AP connection was lost again, and I had to make a new power cycle, but the AP stayed at Nstreme. I had to revert to the backup config, and after reboot the AP switched back to NV2. It seem there is some problem with the bridge, the radio and the ethernet port is in same bridge. The IP address is connecting to unknown interface and i cannott change it to the bridge, the interface switchbox is empty at the address config page.

PS: After I loaded back the config backup again, now the adress is belong to the right bridge. Strange, maybe unsuccessful restore at first time or the Webfig is sick.

Posted: **Wed Apr 25, 2018 9:17 am**

After upgrade to 6.42 (and the same after 6.42.1) found a problem with high sector writes values. More than 4000 writes for less than 24 hours.
Is it normal or not.

mikrotik_sector_writes.jpg

Posted: **Wed Apr 25, 2018 10:40 am**

Got 2 separate issues. One is verified and can be duplicated. Other is still being investigated:

When there is a AP Bridge / Station(Station Bridge) with a RB433 on either the AP or Station in 802.11 the station will not connect Rx rates whatsoever.
This is true regardless of password, connect list or access list settings. This is also true for bridged or non-bridged setups.
Will supply supout when available for the above.

Second issue is a PowerBox with a CPE connected to it. Lose all connection to the CPE. Still investigating the cause as we need to get on site to see what is causing this issue. Also don't see anything in particular in forums for RB750 issue. Could be unrelated.

Posted: **Wed Apr 25, 2018 11:45 am**

RouterOS version 6.42.1 has been released in public "current" channel!

*) led - added "dark-mode" functionality for hAP ac and hAP ac^2 devices;

Still can't turn off the port led indicators in the hap ac2, winbox returns error that the board doesn't have this functionality.

Posted: **Wed Apr 25, 2018 11:51 am**

Still can't turn off the port led indicators in the hap ac2, winbox returns error that the board doesn't have this functionality.

In mAP is the same. Is it possible to add such functionality also for this model?

Posted: **Wed Apr 25, 2018 12:31 pm**

I have upgraded my core routers CCR1036-12G-4S. Am running mpls,ospf and bgp within these routers. One ccr keeps rebooting after like 15-20 minutes.
the rest are ok. the router which keep rebooting is acting head of mpls traffic engineering tunnel and is pushing traffic via this tunnel. On tail side am not pushing traffic via the tunnel. Upload from client is following the normal path chosen by ospf. these routers are not rebooting
I remember we used to have similar problem in this router before mikrotik fixed mpls relating issue last year
Other routers are working fine. Downgraded this router to 41.4 and it is stable now

Posted: **Wed Apr 25, 2018 12:49 pm**

improved compatibility with BCM chipset devices

Looks huge improvement for mobile devices. 2.4G speed increased from ~10-20Mbit to 2-3x more. We use as endpoint devices for consumers. 2.4G had poor perfomance if several devices use traffic, much more better now so far.

Posted: **Wed Apr 25, 2018 1:27 pm**

Ive verified on 3 different models, with 6.42.1 I cannot turn on a LED from command line or script. I can turn it off however. I use the LED control to drive a relay to control power to another device. So this functionality is important to me. Its more then just a LED to me. Completely repeatable on any model of router I have tried.

add led=sfp-led type=on
input does not match any value of type

Posted: **Wed Apr 25, 2018 2:43 pm**

Just a small thing: when you change Comment of an item, it is really necessary to "disable and enable" ("device changed" message is logged) the commented item? For example when I change comment to IPsec policy or wireless interface, it gets restarted which is annoying, because clients will disconnect. For other settings I can understand it, but comment should not affect any item settings, right?

Posted: **Wed Apr 25, 2018 2:59 pm**

After upgrade to 6.42 (and the same after 6.42.1) found a problem with high sector writes values. More than 4000 writes for less than 24 hours.
Is it normal or not.
mikrotik_sector_writes.jpg

I have same issue on RB951Ui-2HnD (with ROS 6.42.1 upgraded just today). I can imagine there are writes if you are using it a lot (you have over 2M writes total so obviously writes are happening a lot). However, my total is 30k for whole lifetime and I own this device over 5 years. Something definitely must be wrong:

2018-04-25_2138.png

I noticed there are random writes each 1-2 minutes. after enabling debug log, some of these writes corresponds with "skip Router Advertisement sending on XXXX: no prefixes to send" (where XXXX is bridge / eth). Some writes appear without any log entry - cant figure out...

my whole "/export" config is following:

# apr/25/2018 21:22:42 by RouterOS 6.42.1
# software id = 0HA0-YFNN
#
# model = 951Ui-2HnD
# serial number = 4AC7024C3DBE
/interface bridge
add fast-forward=no name=bridge1
/interface wireless
set [ find default-name=wlan1 ] ssid=MikroTik
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether3
add bridge=bridge1 interface=ether4
add bridge=bridge1 interface=ether5
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=bridge1
/system clock
set time-zone-name=Australia/Hobart
/system logging
add topics=debug
/system routerboard settings
set silent-boot=no
/tool romon
set enabled=yes

edit: In addition I noticed missing "switch" menu in winbox connected to hAP ac^2 (last update added this menu to cAP, not quite sure why not hAP ac^2)

edit2: Just checked one another RB951 and noticed it has same issue with older ROS:

2018-04-25_2211.png

This one was AP in busy restaurant for over 2 years. Then about 5 month ago upgraded and deployed elsewhere ... Since deployment the ROS is same, so if last 18 days caused 70k writes, then it means those 660k writes would happen during approximately 5.6 month ... what a coincidence

This makes me believe that increased writes are happening since earlier ROS.

edit3: I believe I found culprit! default setting now enables "cloud - update time". so in default setting, mikrotik is sending request to cloud.mikrotik.com (seems unsuccessfully) and that is causing useless memory writes! (actually i noticed that those queries often fail so it is better to enable SNTP client)
edit4: nope. requests to cloud are just part of those writes. writing rate decreased significantly but it is still happening (around 3k within last 9 hours)

Posted: **Wed Apr 25, 2018 3:20 pm**

How can i check which interface support fast-path on 6.42.

Like on previous versions, i was getting that kind info from

interface pr detail fast-path=yes/no ................. "What about on 6.42? how can i check?

Posted: **Wed Apr 25, 2018 3:21 pm**

add led=sfp-led type=on
input does not match any value of type

Confirm, that type=on is not recognisable( 4 changed via winbox to type - on):
/system leds> print
Flags: X - disabled, * - default
# TYPE INTERFACE
0 * interface-activity ether1
1 * interface-activity ether2
2 * interface-activity ether3
3 * interface-activity ether4
4 * (unknown)

Second question: we use custom startup script(easy modified), earlier QuickSet showed Dual Home AP mode, now it detects WISP AP mode and only one 5G wifi in QuickSet. I understand QuickSet is used rarely, but sometimes it is useful. Just question, how QuickSet identifies work mode? Totaly same exported scripts when QuickSet selected Home AP Dual and WISP AP.
It could be usefull option to disable QuickSet somewere at all. Just add option QuickSet=1 or 0. User can control by script if there are several bridges or specific firewall, QuickSet could be disabled.

Posted: **Wed Apr 25, 2018 3:42 pm**

in the winbox, BRIDGE section is showing NOTHING in PORTS section.

If you select Detail Mode - ports are showing.

Winbox - last verstion, RouterOS 6.42.1 .
On the 6.42 version everything was ok.

Any ideas???

Posted: **Wed Apr 25, 2018 3:52 pm**

When I just open and immediately close without saving the quick settings, the configuration on the device changes. hap ac^2

Posted: **Wed Apr 25, 2018 3:58 pm**

in the winbox, BRIDGE section is showing NOTHING in PORTS section.

I reported that before and the report was acknowledged and they are investigating.

Posted: **Wed Apr 25, 2018 4:06 pm**

I'm not sure if this issue happened after upgrading to v6.42.1, but on my hAP ac^2 the write-sect-since-reboot and the write-sect-total is missing in Winbox v3.13 / System Resources screen. /system resource print shows the values. Routerboard firmware is v6.42.1

Posted: **Wed Apr 25, 2018 4:21 pm**

Hello,

I upgrade to v 6.42.1 SXT 5 ac, but not work > BRIDGE > Filter, until v6.41.3 is working well .
/interface bridge filter

Please FIX this bug.

Thank so much

Posted: **Wed Apr 25, 2018 5:23 pm**

I assume someone is keeping track of this epic list of serious faults with a production "stable" release ?

Does Mikrotik have any bug tracker web URL ?

I have a suggestion, apply the security patch to 6.41.3 and lets roll back to 6.41 and skip 6.42.. There are really serious issues covered and confined in this thread, its time to take a serious stand and get things fixed.

Ive been doing Mikrotik a LONG time and ive never seen a mess like this. Normally even the Release Candidates are way more stable then this.

Im also really unhappy they took away the ability to use netwatch to monitor things and send a email alert.. This loss of functionality is honestly unfathomable. I want a official response here on the forum please.

Posted: **Wed Apr 25, 2018 6:05 pm**

edit3: I believe I found culprit! default setting now enables "cloud - update time". so in default setting, mikrotik is sending request to cloud.mikrotik.com (seems unsuccessfully) and that is causing useless memory writes! (actually i noticed that those queries often fail so it is better to enable SNTP client)

You mean if you set the SNTP client to a NTP server then "Cloud update-time" must be set to "YES" ?

Posted: **Wed Apr 25, 2018 6:11 pm**

@bennyh: I assume that you have RB's IP address set on bridge. Do you have admin-mac statically set and auto-mac=no?
If not, bridge will assume mac address from one of member interfaces and if that member interface (momentarily) drops from bridge (I can imagine that happening when you change properties of wifi device), anything can happen.

Posted: **Wed Apr 25, 2018 6:14 pm**

Do not update the time from cloud. Use reliable time server instead.

Posted: **Wed Apr 25, 2018 6:22 pm**

tried it on metal 52ac international and wireless became almost useless on 24ghz and clients dropping every few mins, reverted to 6.41.4

not to mention still waiting for the day when ill be able to see current tx power table as well be able to set tx power mode to card rates or manual

Posted: **Wed Apr 25, 2018 6:22 pm**

Do not update the time from cloud. Use reliable time server instead.

So "Cloud update-time" must be set to "No" right?

Posted: **Wed Apr 25, 2018 6:43 pm**

I checked this on all our routers upgraded to 6.42 or 6.41 ...
And In ROS 6.41 and 6.42 Mikrotik Neighbor Discovery protocol outgoing traffic is actually allowed to bypass firewall altogether and cannot be caught in any chain, not something that any process should be IMHO ...
And for me this is actually pretty serious issue because I used firewall (as I should with any outgoing traffic) to control this on all of our routers ...

Not related to Winbox security issue, but seems like a bug ...
On 6.41.x and 6.42.x MNDP trafic is not visible anymore in firewall output chain ...
For example I am using this rules

/ip firewall raw> print 
Flags: X - disabled, I - invalid, D - dynamic
 0    chain=output action=passthrough log=yes log-prefix="" protocol=udp
 1    ;;; MT discovery
      chain=prerouting action=notrack dst-port=5678 log=no log-prefix="" protocol=udp dst-address=255.255.255.255 
 2    ;;; MT discovery
      chain=output action=notrack dst-port=5678 log=no log-prefix="" protocol=udp dst-address=255.255.255.255

And on 6.40.x it works as expected

print stats
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                                                                                                                                                                         ACTION                            BYTES         PACKETS
 0  D ;;; special dummy rule to show fasttrack counters
      prerouting                                                                                                                                                                                    passthrough                  55 903 342         279 167
 1    prerouting                                                                                                                                                                                    notrack                         295 008           2 176
 2    output                                                                                                                                                                                        notrack                          25 870             195

But on 6.41.x and 6.42.x no packet is ever detected in output chain

 print stats
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                                                                                                                                                                         ACTION                            BYTES         PACKETS
 0    output                                                                                                                                                                                        passthrough                     226 965           1 663
 1    ;;; MT discovery
      prerouting                                                                                                                                                                                    notrack                          99 706             724
 2    ;;; MT discovery
      output                                                                                                                                                                                        notrack                               0               0

So is this some undocumented new feature and if so what is the benefit, or is it just a bug?

Regards

Posted: **Wed Apr 25, 2018 7:48 pm**

After upgrade to 6.42 (and the same after 6.42.1) found a problem with high sector writes values. More than 4000 writes for less than 24 hours.
Is it normal or not.

I have too high write value. What is this and how to diagnose it ?

Posted: **Wed Apr 25, 2018 8:18 pm**

I checked this on all our routers upgraded to 6.42 or 6.41 ...
And In ROS 6.41 and 6.42 Mikrotik Neighbor Discovery protocol outgoing traffic is actually allowed to bypass firewall altogether and cannot be caught in any chain, not something that any process should be IMHO ...
And for me this is actually pretty serious issue because I used firewall (as I should with any outgoing traffic) to control this on all of our routers ...

Not related to Winbox security issue, but seems like a bug ...
On 6.41.x and 6.42.x MNDP trafic is not visible anymore in firewall output chain ...
For example I am using this rules

/ip firewall raw> print 
Flags: X - disabled, I - invalid, D - dynamic
 0    chain=output action=passthrough log=yes log-prefix="" protocol=udp
 1    ;;; MT discovery
      chain=prerouting action=notrack dst-port=5678 log=no log-prefix="" protocol=udp dst-address=255.255.255.255 
 2    ;;; MT discovery
      chain=output action=notrack dst-port=5678 log=no log-prefix="" protocol=udp dst-address=255.255.255.255

And on 6.40.x it works as expected

print stats
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                                                                                                                                                                         ACTION                            BYTES         PACKETS
 0  D ;;; special dummy rule to show fasttrack counters
      prerouting                                                                                                                                                                                    passthrough                  55 903 342         279 167
 1    prerouting                                                                                                                                                                                    notrack                         295 008           2 176
 2    output                                                                                                                                                                                        notrack                          25 870             195

But on 6.41.x and 6.42.x no packet is ever detected in output chain

 print stats
Flags: X - disabled, I - invalid, D - dynamic 
 #    CHAIN                                                                                                                                                                                         ACTION                            BYTES         PACKETS
 0    output                                                                                                                                                                                        passthrough                     226 965           1 663
 1    ;;; MT discovery
      prerouting                                                                                                                                                                                    notrack                          99 706             724
 2    ;;; MT discovery
      output                                                                                                                                                                                        notrack                               0               0

So is this some undocumented new feature and if so what is the benefit, or is it just a bug?

Regards

It was discussed in a closed thread:

viewtopic.php?f=21&t=133533&start=150#p656843

It seem to be feature.

Posted: **Wed Apr 25, 2018 8:19 pm**

Having same issue with alot sector writes but here is catch - I've tried solution mentioned by vecernik87 but simply IP > Cloud setting is not there on x86 or am I missing something here?

x86_sector_writes.PNG

Posted: **Wed Apr 25, 2018 8:25 pm**

Updated a CRS125 to 6.42.1.

Broke a few things.
Bridge changed.
Arp disabled
DHCP server moved to wrong interface.
etc
etc

Took a bit... but got it back on line.

Posted: **Wed Apr 25, 2018 8:32 pm**

I know that updating from 6.40 or below to 6.41 automatically reconfigures the ethernet master-port config to a bridge with ports and hw accel on.
Could it be that this upgrading support has been dropped from 6.42? When I upgraded a router from an older release (I think 6.39.2) immediately to 6.42.1 the master port config was deleted but it wasn't converted to a bridge, I had to do that manually.

Posted: **Wed Apr 25, 2018 10:01 pm**

I'm seeing two things:

1. ssh keys are being regenerated as part of the upgrade.
2. Looks like netwatch is gone. Was this planned, or part of vulnerability mitigation?

Posted: **Wed Apr 25, 2018 10:20 pm**

Im not sure what happened last night, but, somehow none of my scripts would run from scheduler. I could run them manually. Its like scheduler somehow was not running, or did not have permissions to run scripts.. I always use 2 partitions and flipped back to 41.3 and all was well.
You know, I’ve been working with Support on an issue exactly like this. I have discovered that scheduler will often not start a script anymore if you just use the name of the script in the action, but if you say /system script run scriptname, it runs fine. Try that.
I will... Thank you

Let us know if this works for you. Support is still nonplussed, and it never hurts to make them aware that multiple people are seeing the same problem.

Posted: **Wed Apr 25, 2018 10:36 pm**

6.42.1 has caused a noticeable bump in disk usage on CCR1009-7G-1C.
Is that normal (expected?)

ros_s.png

Posted: **Wed Apr 25, 2018 11:17 pm**

Upgraded to 6.42.1 and for some reason almost all switch ports were removed from bridges (luckily admin. bridge remained w. 1 port attached so I regained access to the router).
Device is RB2011iL-IN.

Posted: **Wed Apr 25, 2018 11:41 pm**

Upgraded to 6.42.1 and for some reason almost all switch ports were removed from bridges (luckily admin. bridge remained w. 1 port attached so I regained access to the router).
Device is RB2011iL-IN.

Did you upgrade from a pre-6.40 version? The you may be seeing the same thing as I mentioned in message #93 above. Like you, I was lucky I could recover the router.

Posted: **Thu Apr 26, 2018 1:02 am**

Having same issue with alot sector writes but here is catch - I've tried solution mentioned by vecernik87 but simply IP > Cloud setting is not there on x86 or am I missing something here?
x86_sector_writes.PNG

Hi,
Not quite sure why you dont see it. I believe it should be accessible through console as well:

# to see what is currently set
/ip cloud print  
# to disable update time from mikrotik cloud
/ip cloud set update-time=no

today morning i checked my both RB951. On both, write-rate decreased a bit (but still many times higher than pre-update)
Before i disabled update-time, first router was showing around 1000 writes per hour and second was showing 161 writes per hour.
Currently, one shows about 300 writes per hour and second shows 50 writes per hour.

I am well aware that according to viewtopic.php?t=128904#p634198 , this write rate is not going to cause any issues, however, I have to wonder why there is such increase after update. Both those RB were in use for several years without any significant writes while using some older ROS. After I took care of both and upgraded them, suddenly, they need to write so much...

Do not update the time from cloud. Use reliable time server instead.

Sure thing

trick is, that not everyone knows about this feature and it is by default enabled (even after reset config with no-defaults). Everyone has to manually disable this.

I'm not sure if this issue happened after upgrading to v6.42.1, but on my hAP ac^2 the write-sect-since-reboot and the write-sect-total is missing in Winbox v3.13 / System Resources screen. /system resource print shows the values. Routerboard firmware is v6.42.1

I can confirm that it is not visible on 6.42 as well. Unfortunately I don't have any of my devices on older ROS so I can't check right now if it was missing earlier.
Also, the switch menu is not visible for hAP ac^2

I can see plenty of "bugreports" in this topic. Is there some summary or are we expected to report each of them to support@mikrotik ? Obviously, same bug will get reported many times by multiple people.

Posted: **Thu Apr 26, 2018 1:43 am**

6.42.1 has caused a noticeable bump in disk usage on CCR1009-7G-1C.
Is that normal (expected?)

Can see the same on RB600, big jump in disk usage:

weekly.gif

Used automatic download from packages in Winbox to update it.

Posted: **Thu Apr 26, 2018 4:05 am**

edit3: I believe I found culprit! default setting now enables "cloud - update time". so in default setting, mikrotik is sending request to cloud.mikrotik.com (seems unsuccessfully) and that is causing useless memory writes! (actually i noticed that those queries often fail so it is better to enable SNTP client)

You mean if you set the SNTP client to a NTP server then "Cloud update-time" must be set to "YES" ?

Nice one that is the source of rewrites! Thank you

Posted: **Thu Apr 26, 2018 8:39 am**

my hAP(hAP AC) have 1 meterouter. upgrade 6.42.1,
reboot system, deleted metarouter PKG file in nand.
this is bug?

erased file openwrt-mr-mips-rootfs.tar.gz　

Posted: **Thu Apr 26, 2018 8:42 am**

Hi,

I ‘ve installed the latest version 6.42.1 in my RB3011 UiAS-RM and suddenly my router started to do cyclic reboots.
I ‘ve tried to netinstall but I cannot see the router.

In the console I can see a message “kernel not found or data is corrupted”.

Does anyone has the same problem ?

Before the update i didnt have any problem, do you think that the update crashed the router ?

Posted: **Thu Apr 26, 2018 10:08 am**

No significant change in disk usage nor disk writes on RB2011, Upgraded from 6.41 to 6.42.1

Posted: **Thu Apr 26, 2018 10:11 am**

@bennyh: I assume that you have RB's IP address set on bridge. Do you have admin-mac statically set and auto-mac=no?
If not, bridge will assume mac address from one of member interfaces and if that member interface (momentarily) drops from bridge (I can imagine that happening when you change properties of wifi device), anything can happen.

I sent a reply in the morning, but disappered. So, Thats true what you wrote, there was not static admin MAC address, but with this config I doesnt have similar problem till v6.42.1. I dont find auto-mac section at the bridge properties, only the static admin MAC. Which MAC address range should I use?

Posted: **Thu Apr 26, 2018 1:04 pm**

Integration services for hyper-v completely broke CHR, router refuses to communicate after 10GBs of routed data. Reverted back to 6.41.4

More here: viewtopic.php?f=2&t=133716

Posted: **Thu Apr 26, 2018 1:39 pm**

WAN IP Lease expires on daily basis

Since upgrading to 6.42.1, I noticed that on a daily basis I get the following log entries

apr/24 15:16:35 dhcp,critical,error dhcp-client on ether1 lost IP address <WAN IP> - lease expired
12:28:52 dhcp,critical,error dhcp-client on ether1 lost IP address <WAN IP> - lease expired

Is DHCP not suppose to already start renewing from about 50% of lease time?
Is this related to the update or is my service provider stuffing up?

Posted: **Thu Apr 26, 2018 2:06 pm**

Is DHCP not suppose to already start renewing from about 50% of lease time?
Is this related to the update or is my service provider stuffing up?

Probably a combination of the two. I would start by running a packet sniffer for DHCP traffic on your link and save it in a file, download the file and examine in detail using wireshark or mail it to support.

Posted: **Thu Apr 26, 2018 2:26 pm**

I would start by running a packet sniffer for DHCP traffic on your link and save it in a file, download the file and examine in detail using wireshark

I was thinking about the same, but there is an issue - sniffing on an interface breaks fasttracking so throughput falls down. So port mirroring on a switch and sniffing externally is needed.

Posted: **Thu Apr 26, 2018 3:43 pm**

Stupid question. Where do I get 6.41.4 ?

Im moving all my clients back to a stable release. 42.1 just looks way to unstable to me.

Posted: **Thu Apr 26, 2018 3:44 pm**

NVM, I found it.. https://mikrotik.com/download/archive

Posted: **Thu Apr 26, 2018 3:52 pm**

I guess new kid control function is not working full yet. Added device with MAC, kid, and nothing happening when pause or resume user. No firewall rules appears. When I Pause it shows Paused, when I Resume it shows Blocked, still full access from this MAC.

Posted: **Thu Apr 26, 2018 4:00 pm**

6.41.4 needs the security patch and 42.x needs to be reverted to RC.

Posted: **Thu Apr 26, 2018 4:06 pm**

No problems with 6.42.1 over here, tnx for the great work MT !

Posted: **Thu Apr 26, 2018 4:07 pm**

I would start by running a packet sniffer for DHCP traffic on your link and save it in a file, download the file and examine in detail using wireshark
I was thinking about the same, but there is an issue - sniffing on an interface breaks fasttracking so throughput falls down. So port mirroring on a switch and sniffing externally is needed.

You don't need traffic on the link. You can sniff it during the night when you are sleeping.

Posted: **Thu Apr 26, 2018 5:35 pm**

I have OpenVPN (ovpn) set up on my MikroTik home router (RB951G-2HnD), and I just updated to 6.42.1.

I'm noticing entries in my log:

ovpn, info TCP connection established form 125.212.217.215

That's an example of one of the IP addresses.

I may not have noticed these prior to updating, but I'm definitely seeing the afterwards.

Does this indicate that my OVPN has been compromised??? I've disabled my ovpn in the meantime.

Posted: **Thu Apr 26, 2018 5:53 pm**

Does this indicate that my OVPN has been compromised??? I've disabled my ovpn in the meantime.

nope just service scanners

Posted: **Thu Apr 26, 2018 6:03 pm**

Does this indicate that my OVPN has been compromised??? I've disabled my ovpn in the meantime.
nope just service scanners

Thank you very much for the response.

So I'm seeing a port scanner attempt? I guess I'm worried about the "established" part. Do you believe the connections are rejected ultimately? I can't see an indication either way.

I'm newer to Mikrotik, so I'm just trying to understand.

Posted: **Thu Apr 26, 2018 6:21 pm**

You should be worried when you see OVPn user logged in message

Posted: **Thu Apr 26, 2018 6:43 pm**

You should be worried when you see OVPn user logged in message

Thank you

Posted: **Thu Apr 26, 2018 8:03 pm**

Ive spent the morning downgrading all my clients from 6.42.1 to 6.41.4.. Over the last few days ive seen a number of weird things on client systems that are previously reported on this thread. I do not consider 42.1 "stable"... The other BIG deciding factor to revert to 41.4 is Netwatch. I use this extensively to monitor lots of gear on the clinet network and send email alerts & update DDNS or take other network actions. As Mikrotik decided to take away Netwatch without any reason or notice I have been forced back to a insecure version of RouterOS. I also use the on/off functions of the LED controls to control a relay that I can do various things with like power cycle the modem. As ON does not work from command line or scripting I also need to roll back. bugs and issues.

Ive been doing Mikrotik a LONG time, back when they only had PC boards, and ive never seen a stable release this riddled with bugs and issues like 42.1 is. I would hope Mikrotik is working very hard to correct this issue. Its cost me a bunch of time and money.

Posted: **Thu Apr 26, 2018 9:28 pm**

Is DHCP not suppose to already start renewing from about 50% of lease time?
Is this related to the update or is my service provider stuffing up?
Probably a combination of the two. I would start by running a packet sniffer for DHCP traffic on your link and save it in a file, download the file and examine in detail using wireshark or mail it to support.

----

I would start by running a packet sniffer for DHCP traffic on your link and save it in a file, download the file and examine in detail using wireshark
I was thinking about the same, but there is an issue - sniffing on an interface breaks fasttracking so throughput falls down. So port mirroring on a switch and sniffing externally is needed.

Thx both, I have configured the sniffing tool in Mikrotik for bootps and bootpc for both directions, filter option to or and interface on ether1 and to be saved to a file. created a schedule to start this tomorrow morning at 03:00 so it does not affect performance through the evening while streaming movies, etc

Posted: **Thu Apr 26, 2018 9:36 pm**

@bennyh: I assume that you have RB's IP address set on bridge. Do you have admin-mac statically set and auto-mac=no?
If not, bridge will assume mac address from one of member interfaces and if that member interface (momentarily) drops from bridge (I can imagine that happening when you change properties of wifi device), anything can happen.

After I set static MAC address there is no difference. The router showed the neighbor AP with the new MAC address, but when I changed the the wireless protocol on AP, the webfig had beeen unreachable. After power cycle and config restore, now working again.

Posted: **Fri Apr 27, 2018 9:17 am**

Hi,

I ‘ve installed the latest version 6.42.1 in my RB3011 UiAS-RM and suddenly my router started to do cyclic reboots.
I ‘ve tried to netinstall but I cannot see the router.

In the console I can see a message “kernel not found or data is corrupted”.

Does anyone has the same problem ?

Before the update i didnt have any problem, do you think that the update crashed the router ?

Hi All,

What steps can i perform to check if the RB3011 is not bricked ?

Thanks

Posted: **Fri Apr 27, 2018 10:12 am**

Hi All,

What steps can i perform to check if the RB3011 is not bricked ?

Thanks

Maybe usefull for 3011 too:
viewtopic.php?t=132483

Posted: **Fri Apr 27, 2018 1:14 pm**

I ‘ve installed the latest version 6.42.1(sw and fw) in my RB3011 UiAS-RM and suddenly my router started to act strange. All ports are in one vpn bridge and some stopped to translate web and misticly random shares, if i put in diff port same pc problem is gone. One port refuses to translate any grafics(MC for example) only text mode. Winbox is not working any more through SSTP tunel(hangs on plugin download).It seems that this update killed a lot of RB3011's(QCA 8337).

Posted: **Fri Apr 27, 2018 1:17 pm**

I switched from 6.42 version to 6.42.1 I have a wisp pppoe connection I have this error

Schermata del 2018-04-27 11.37.55.png

.
Default Route Distance 0, should mean route type 0, connected,then the value should be corrected.
Because instead it is highlighted in red as error or missing?
Somebody knows something?
Does it happen to you too?

Posted: **Fri Apr 27, 2018 2:18 pm**

Default route distance should be 1 or more. It used to be 0 and upgrade magic doesn't fix it.

Posted: **Fri Apr 27, 2018 3:56 pm**

When I upgraded a router from an older release (I think 6.39.2) immediately to 6.42.1 the master port config was deleted but it wasn't converted to a bridge, I had to do that manually.

Hi,
this could happen if master port is not part of any bridge.
e.g. I have ether1 as gateway, ether2 as master port, ether3-5 slave to ether2. No bridges. All config (ip, firewall, dhcp etc) done to ether1 or ether2. Everything working, ports 2-5 swithcing, routing between ether1 and switchgroup ether2-5.

After upgrade to 6.41 and above it eliminatete master/port, but don't create new bridges. So I have only ether1 and ether2 working (routing), but ether3-5 are unconfigured and not working.

You have to create new bridge, add ports, reconfigure other things (ip, dhcp etc).

I'd be scared of upgrading some CRS's which could have more switch groups without bridges, and after upgrade I will get only few ports working.

So if you are using master-port, then before upgrade always check, that every master port is added to some bridge.

Posted: **Fri Apr 27, 2018 4:16 pm**

Is DHCP not suppose to already start renewing from about 50% of lease time?
Is this related to the update or is my service provider stuffing up?
Probably a combination of the two. I would start by running a packet sniffer for DHCP traffic on your link and save it in a file, download the file and examine in detail using wireshark or mail it to support.
----

I would start by running a packet sniffer for DHCP traffic on your link and save it in a file, download the file and examine in detail using wireshark
I was thinking about the same, but there is an issue - sniffing on an interface breaks fasttracking so throughput falls down. So port mirroring on a switch and sniffing externally is needed.

Thx both, I have configured the sniffing tool in Mikrotik for bootps and bootpc for both directions, filter option to or and interface on ether1 and to be saved to a file. created a schedule to start this tomorrow morning at 03:00 so it does not affect performance through the evening while streaming movies, etc

Ok, seems Mikrotik / 6.42.1 is in the clear here

At 05:00 I can see router requesting new IP from previous DHCP server with no response from ISP
At 09:29 router WAN address starts broadcasting for new IP
At 12:29 router starts DHCP Discover process and ISP responds

Seems ISP is stuffing up

Posted: **Fri Apr 27, 2018 5:11 pm**

Default route distance should be 1 or more. It used to be 0 and upgrade magic doesn't fix it.

I changed from 0 to 1 the value and it seems to work. the manual indicates distance :0 connection 1 static address . (I have no static but dynamic address though??)

Posted: **Fri Apr 27, 2018 5:18 pm**

Everywhere RB OmniTIK U-5HnD, NSTREME, fail

client disconnect with "disconnected, too many poll timeouts". Sometimes all client, sometimes only part disconnected.
Sometimes they connect back, sometimes not.

Switching to NV2 is ok.

apr/27/2018 01:29:49 system,error,critical router was rebooted without proper shutdown
apr/27/2018 01:29:49 system,error,critical kernel failure in previous boot
apr/27/2018 01:29:49 system,error,critical out of memory condition was detected

Posted: **Fri Apr 27, 2018 6:01 pm**

Mikrotik DHCP client request for ip not in 50% expires time but in 10-15% expires time?

mk dhcp-client

Flags: X - disabled, I - invalid, D - dynamic
# INTERFACE USE-PEER-DNS ADD-DEFAULT-ROUTE STATUS ADDRESS
0 bridge1 yes yes renewing... 192.168.0.22/24

10 minutes leases time. In 5 minutes expires renewing ip and in 1 minutes 15 second expires bound ip.

Posted: **Fri Apr 27, 2018 6:04 pm**

Default route distance should be 1 or more. It used to be 0 and upgrade magic doesn't fix it.
I changed from 0 to 1 the value and it seems to work. the manual indicates distance :0 connection 1 static address . (I have no static but dynamic address though??)

No, the manual says:
0 - Connected "Routes" - Meaning directly attached, i.e. interface on router
1 - Static "Routes" - i.e. Default Gateway Route, not static / dynamic IP Addresses

Posted: **Fri Apr 27, 2018 6:20 pm**

Default route distance should be 1 or more. It used to be 0 and upgrade magic doesn't fix it.
I changed from 0 to 1 the value and it seems to work. the manual indicates distance :0 connection 1 static address . (I have no static but dynamic address though??)
No, the manual says:
0 - Connected "Routes" - Meaning directly attached, i.e. interface on router
1 - Static "Routes" - i.e. Default Gateway Route, not static / dynamic IP Addresses

now it is clear to me.
thanks Czfan

Posted: **Fri Apr 27, 2018 6:57 pm**

When I upgraded a router from an older release (I think 6.39.2) immediately to 6.42.1 the master port config was deleted but it wasn't converted to a bridge, I had to do that manually.
Hi,
this could happen if master port is not part of any bridge.
e.g. I have ether1 as gateway, ether2 as master port, ether3-5 slave to ether2. No bridges. All config (ip, firewall, dhcp etc) done to ether1 or ether2. Everything working, ports 2-5 swithcing, routing between ether1 and switchgroup ether2-5.

After upgrade to 6.41 and above it eliminatete master/port, but don't create new bridges. So I have only ether1 and ether2 working (routing), but ether3-5 are unconfigured and not working.

In my experience, when I updated configs like that (e.g. on a RB750) from 6.39 or 6.40 to 6.41 they got converted into a bridge config just fine.
However now I upgraded a similar system fro 6.39 immediately to 6.42.1 it did not happen. The ether2 was still configured but the ports 3-5 became detached from it.
I had to create a bridge, put ports 2-5 into it, and move the IP address from ether2 to the bridge for good measure (it works either way).
Therefore I wonder if the "masterport to bridge migration" may be only in 6.41 and not in 6.42

Posted: **Fri Apr 27, 2018 7:10 pm**

@Xymox

Ive spent the morning downgrading all my clients from 6.42.1 to 6.41.4.. Over the last few days ive seen a number of weird things on client systems that are previously reported on this thread. I do not consider 42.1 "stable"... The other BIG deciding factor to revert to 41.4 is Netwatch.

Should you be using Release (Current) branch instead of Bugfix (Stable) branch for business of any kind?

Posted: **Fri Apr 27, 2018 7:29 pm**

It looks like netwatch is in the advanced-tools package.

Posted: **Sat Apr 28, 2018 12:05 am**

We're seeing RB2011UiAS-2HnD's on version 6.32.2 upgraded to 6.42.1 by using winbox>packages>check for updates then download and install and reboot are missing the wireless interface and menue when they come back online. They end up with three separate wireless NPK files in the files section. wireless, wireless cm2, and wirelessfp. To fix it, we're deleting the cm2 and fp wireless npk files, rebooting, and then reconfiguring the wireless interface. It will come back as disabled, a client instead of an ap bridge, and the frequencies, protocol, and security profile set incorrectly. The SSID is also changed to the system identity. Plus, the port in the local bridge that used to to be wlan1 shows up as unknown and needs to be changed back to wlan1.

If we drag and drop the upgrade package into it via Winbox or use /tool fetch url="https://download.mikrotik.com/routeros/ ... 6.42.1.npk" mode=http the wireless issue doesn't occur.

Same thing happens with 6.32.2 to 6.40.8 bugfix

Posted: **Sat Apr 28, 2018 8:11 am**

Finding these changes introduced back in 6.41 to be most inconvenient

*) lte - automatically add "/ip dhcp-client" configuration on interface;
Can we have a way to turn off this behavior completely?

*) lte - changed default values to "add-default-route=yes", "use-peer-dns=yes" and "default-route-distance=2";
OR ability to adjust the dynamic options to set use-peer-dns=no and default-route-distance to a higher numbered route of our choosing.

I know 6.42 introduced the following setting. But suddenly having routers with unexpected IP Addresses and routes that were not there before is annoying.
*) lte - do not add DHCP client on LTE modems that doesn't use DHCP;

Andy

Posted: **Sat Apr 28, 2018 8:15 am**

@Xymox

Ive spent the morning downgrading all my clients from 6.42.1 to 6.41.4.. Over the last few days ive seen a number of weird things on client systems that are previously reported on this thread. I do not consider 42.1 "stable"... The other BIG deciding factor to revert to 41.4 is Netwatch.

Should you be using Release (Current) branch instead of Bugfix (Stable) branch for business of any kind?

When the Release (Current) branch has the exploit patch available, and the Bugfix (Stable) branch still does not... sometimes you do. But never again, my friend.

Posted: **Sat Apr 28, 2018 8:20 am**

Hi,

do you have any news about the eoip issue?

best regards, Gabor

EoIP Ethernet Frame issue is still there (introduced in 6.42 breaking fragmenting big frames somehow broken) verified on RB2011 and sent supout to MT-support.

Posted: **Sat Apr 28, 2018 8:21 am**

A big problem with devices that have a 32MB ram.

Posted: **Sat Apr 28, 2018 2:49 pm**

WAN IP Lease expires on daily basis

Since upgrading to 6.42.1, I noticed that on a daily basis I get the following log entries

apr/24 15:16:35 dhcp,critical,error dhcp-client on ether1 lost IP address <WAN IP> - lease expired
12:28:52 dhcp,critical,error dhcp-client on ether1 lost IP address <WAN IP> - lease expired

Is DHCP not suppose to already start renewing from about 50% of lease time?
Is this related to the update or is my service provider stuffing up?

I am seeing the same issue.

It gets the DHCP Lease information but doesn't rebind at the specified time.

I just downgraded to 6.40.8. and it's working as expected.

UGHHHHH

Posted: **Sat Apr 28, 2018 3:48 pm**

A big problem with devices that have a 32MB ram.

What exactly?

Posted: **Sat Apr 28, 2018 4:10 pm**

There is a problem with dude fonts in this release. I have some font files placed in dude/files directory and now it's impossible to select these fonts in dude settings, it only shows fonts from dude/files/default directory (which is read-only). Earlier everything was great, and it was possible to select the fonts from dude/files. Can you fix this?

Posted: **Sat Apr 28, 2018 6:51 pm**

After some of the above messages I checked a router that has DHCP client on LTE stick and I find the client in state "renewing...".
There is definitely something wrong there.

Posted: **Sat Apr 28, 2018 8:09 pm**

It's happening to me on all routers (RB2011,HEX2,CRS125) running 6.42.1.

The DHCP client is stuck on renewing until the lease expires.

I opened a support ticket lets see what they say.

Posted: **Sat Apr 28, 2018 8:13 pm**

After some of the above messages I checked a router that has DHCP client on LTE stick and I find the client in state "renewing...".
There is definitely something wrong there.

Sometimes I get this on my RB2011 (6.42.1, but think I it was same on 6.41.4) connected to ONT (Fibre) also. when I then manually release / renew, it changes to bound

Posted: **Sat Apr 28, 2018 10:07 pm**

My box also got owned ... phew.

Posted: **Sat Apr 28, 2018 10:24 pm**

A big problem with devices that have a 32MB ram.
What exactly?

Disconnect WiFi client. Disconnect capsman clie

Everywhere RB OmniTIK U-5HnD, NSTREME, fail

client disconnect with "disconnected, too many poll timeouts". Sometimes all client, sometimes only part disconnected.
Sometimes they connect back, sometimes not.

Switching to NV2 is ok.

apr/27/2018 01:29:49 system,error,critical router was rebooted without proper shutdown
apr/27/2018 01:29:49 system,error,critical kernel failure in previous boot
apr/27/2018 01:29:49 system,error,critical out of memory condition was detected

nt...

Several omnitik. All of them had to switch to nv2 otherwise clients refused to join.

Posted: **Sat Apr 28, 2018 10:29 pm**

WAN IP Lease expires on daily basis

Since upgrading to 6.42.1, I noticed that on a daily basis I get the following log entries

apr/24 15:16:35 dhcp,critical,error dhcp-client on ether1 lost IP address <WAN IP> - lease expired
12:28:52 dhcp,critical,error dhcp-client on ether1 lost IP address <WAN IP> - lease expired

Is DHCP not suppose to already start renewing from about 50% of lease time?
Is this related to the update or is my service provider stuffing up?
I am seeing the same issue.

It gets the DHCP Lease information but doesn't rebind at the specified time.

I just downgraded to 6.40.8. and it's working as expected.

UGHHHHH

Does not seem to be same problem as mine then, mine requests, but does not get back until lease has expired, see screenshot from packet analyzer

DHCPFail.jpg

Posted: **Sat Apr 28, 2018 10:30 pm**

this broke UPNP for me. it worked before I upgraded

Posted: **Sat Apr 28, 2018 10:58 pm**

@Xymox

Ive spent the morning downgrading all my clients from 6.42.1 to 6.41.4.. Over the last few days ive seen a number of weird things on client systems that are previously reported on this thread. I do not consider 42.1 "stable"... The other BIG deciding factor to revert to 41.4 is Netwatch.

Should you be using Release (Current) branch instead of Bugfix (Stable) branch for business of any kind?
When the Release (Current) branch has the exploit patch available, and the Bugfix (Stable) branch still does not... sometimes you do. But never again, my friend.

I have only been using stable. 42.x is not stable. 41.x is stable but not secure now. 43.x does not have Netwatch or a fixed LED ON script command.

I made sure the routers are not available to the outside world, so the security issue should not effect me.

I now wait for a solution to the debacle.

Posted: **Sat Apr 28, 2018 11:09 pm**

Ive got 2 older routers I can't downgrade. There is not enough disc space. 42.1 seems to have taken up so much space I cant transfer firmware in. I will have to go on site and Netinstall them.. Thats annoying.. Both are RB1000AHx2

Looking thru the thread,, jeeze,, I think this "stable" 42.1 broke, well, everything. It even broke UPnP.. Killed off Netwatch... Caused DHCP to not work.. Everyday there is a new post here about something completly different that is broken..

Also, so far, there are no official Mikrotik posts about this faceplant and what they are going to do about it.

Ive never seen a RC this bad,, and this is a STABLE release... What a mess...

I am happy tho on 41.4.. Ive disabled everything but WInbox and put that on a random port and restricted it LAN side use only. So I guess im mostly safe from the security issue..

Posted: **Sat Apr 28, 2018 11:20 pm**

Yea I had to do that also, 6.42.1 broke a lot of things, namely it completely broke the router on the Hyper-V platform, so this is a no go for me.

Posted: **Sat Apr 28, 2018 11:21 pm**

Downgrading a RB1100AHx2 from 6.42.1 to 6.40.8 bricked it. Will have to make a trip to the mountain to fix that one. At least I had a backup router in place!

Posted: **Sat Apr 28, 2018 11:45 pm**

This has cost a lot of people time and money..

BUT.. We should all step back and think about how stable RouterOS has been for many years. For me its like 10 years of very stable and very reliable operation. So in my mind, its OK to have a accidental mess like this. Its just fine as long as they work hard to fix it very quickly. Its also important to step forward and admit the mistake and provide a plan on what they are going to do to fix the issue.

Why did they cripple Netwatch ? This needs to be put back in any fix they are working on now. It was crazy to remove this.

My 2 cents on what should happen.. Take 41.4 and apply a security patch for this new issue. Turn that into stable release 44.0.. Push that out right away.. Make RC 43.x into 45.1 and FIX IT. Then release 45 once its at like RC45.30 and all these issues are worked out...

Posted: **Sat Apr 28, 2018 11:51 pm**

hi
i use this construction

/interface list
add name=ISP_1
add name=ISP_2
add include=ISP_1,ISP_2 name=ISP
/interface list member
add interface=ether1 list=ISP_1
add interface=vrrp-mts-ISP1 list=ISP_1
add interface=vrrp-rt-ISP2 list=ISP_2
add interface=ether2 list=ISP_2

I used list ISP for firewall rules in filter

if router rebooted, rules not action = not working
if you edit a list, for example, add a comment

/interface list
set  comment=aaa ISP

The rules begin to work
problem only list = ISP

Posted: **Sun Apr 29, 2018 3:16 am**

WAN IP Lease expires on daily basis

Since upgrading to 6.42.1, I noticed that on a daily basis I get the following log entries

apr/24 15:16:35 dhcp,critical,error dhcp-client on ether1 lost IP address <WAN IP> - lease expired
12:28:52 dhcp,critical,error dhcp-client on ether1 lost IP address <WAN IP> - lease expired

Is DHCP not suppose to already start renewing from about 50% of lease time?
Is this related to the update or is my service provider stuffing up?
I am seeing the same issue.

It gets the DHCP Lease information but doesn't rebind at the specified time.

I just downgraded to 6.40.8. and it's working as expected.

UGHHHHH

Does not seem to be same problem as mine then, mine requests, but does not get back until lease has expired, see screenshot from packet analyzer

DHCPFail.jpg

That's the same problem as you are seeing it mirrors your cap. I notice that it only accepts the request when the source address is 0.0.0.0, not the public IP.

Posted: **Sun Apr 29, 2018 2:01 pm**

WAN IP Lease expires on daily basis

Since upgrading to 6.42.1, I noticed that on a daily basis I get the following log entries

apr/24 15:16:35 dhcp,critical,error dhcp-client on ether1 lost IP address <WAN IP> - lease expired
12:28:52 dhcp,critical,error dhcp-client on ether1 lost IP address <WAN IP> - lease expired

Is DHCP not suppose to already start renewing from about 50% of lease time?
Is this related to the update or is my service provider stuffing up?
I am seeing the same issue.

It gets the DHCP Lease information but doesn't rebind at the specified time.

I just downgraded to 6.40.8. and it's working as expected.

UGHHHHH

Does not seem to be same problem as mine then, mine requests, but does not get back until lease has expired, see screenshot from packet analyzer

DHCPFail.jpg
That's the same problem as you are seeing it mirrors your cap. I notice that it only accepts the request when the source address is 0.0.0.0, not the public IP.

Hi
Would be interesting to see more details in this capture: how does transaction look like, flags set, mac addresses etc etc.
Seems, DHCP server is not happy with unicast requests (renewal messages) sent from mikrotik router if these are sent out.

So far this DHCP issue seems to be quite serious defect in 6.42.1

Posted: **Sun Apr 29, 2018 6:25 pm**

Would be interesting to see more details in this capture: how does transaction look like, flags set, mac addresses etc etc.
Seems, DHCP server is not happy with unicast requests (renewal messages) sent from mikrotik router if these are sent out.

I did few DHCP tests with CHR versions 6.42, 6.42.1, 6.40.5 and cisco soapbox.
MT routers running 6.42, 6.42. send out all DHCP renewal requests towards specific DHCP server with wrong destination MAC address (namely, own MT router MAC address). Only following broadcast requests are sent to "all 1". No surprise, DHCP server would not receive such renewal requests until broadcasts arrive.
When broadcast domain is large and contains devices with ARP proxy feature, some more side effects may be observed.
DHCP renewal on Cisco and MT router running 6.40.5 works as expected.

Mikrotik engineers may want tolook into DHCP client behaviour at least on 6.42 and 6.42.1.

Posted: **Sun Apr 29, 2018 6:33 pm**

Would be interesting to see more details in this capture: how does transaction look like, flags set, mac addresses etc etc.
Seems, DHCP server is not happy with unicast requests (renewal messages) sent from mikrotik router if these are sent out.

I did few DHCP tests with CHR versions 6.42, 6.42.1, 6.40.5 and cisco soapbox.
MT routers running 6.42, 6.42. send out all DHCP renewal requests towards specific DHCP server with wrong destination MAC address (namely, own MT router MAC address). Only following broadcast requests are sent to "all 1". No surprise, DHCP server would not receive such renewal requests until broadcasts arrive.
When broadcast domain is large and contains devices with ARP proxy feature, some more side effects may be observed.
DHCP renewal on Cisco and MT router running 6.40.5 works as expected.

Mikrotik engineers may want tolook into DHCP client behaviour at least on 6.42 and 6.42.1.

Please send the above to support@mikrotik.com (or shout loud, you're closer to Mikrotik premises than most of us

), but don't rely on Mikrotik staff picking this information from this forum.

Posted: **Sun Apr 29, 2018 7:26 pm**

Please send the above to support@mikrotik.com (or shout loud, you're closer to Mikrotik premises than most of us ), but don't rely on Mikrotik staff picking this information from this forum.

I have no formal support contract with Mikrotik, but will try to do so.
Anyway, there was once SW defect in new version when router was not able to boot due to certain line in configuration. I wrote in this forum and Mikrotik engineers responded promptly.
Here are my lab captures if someone is interested.

Posted: **Sun Apr 29, 2018 7:47 pm**

I have no formal support contract with Mikrotik, but will try to do so.

After some discussion with @strods in one of these "current" or "rc" topics here, my understanding of the repelling sentence regarding support contract is that Mikrotik is not obliged to assist you in resolving simple configuration issues or alike but always welcomes meaningful bug reports such as this one. After all, the worst what can happen to you is that they won't answer.

Posted: **Sun Apr 29, 2018 7:51 pm**

I have no formal support contract with Mikrotik, but will try to do so.

MikroTIk is not like Cisco. Anyone can write a mail to support, no need for a formal support contract.

Posted: **Sun Apr 29, 2018 8:18 pm**

Does 6.42.1 force SSH host key renewal on first login after the upgrade? The SSH host keys are changing on every router I upgrade and I want to rule out the unlikely MITM.

It would be nice to see ***Router SSH host keys will change after upgrade*** in the change logs of the next revision if this is expected behavior.

It would also be helpful if you uploaded all of the release files to virustotal.com under a Mikrotik account so we have an independent verification that your servers are providing a valid file. The hashes on the download page are really useful, router verification of the packages is too, and using SSL on the site is also most welcome, but when there is a major hole in the OS it's nice to have independent sources to verify the authenticity of the files. This is especially important when re-flashing a potentially compromised router. Thanks!

Posted: **Sun Apr 29, 2018 10:47 pm**

Does 6.42.1 force SSH host key renewal on first login after the upgrade? The SSH host keys are changing on every router I upgrade and I want to rule out the unlikely MITM.

A few of my devices have changed keys, many of them retained the old key. I did not find motive to rebuild key in some and not in others.

Posted: **Sun Apr 29, 2018 10:54 pm**

A few of my devices have changed keys, many of them retained the old key. I did not find motive to rebuild key in some and not in others.

As I update more devices I am seeing the same thing. Some change keys, others don't. The ones that change keys take longer to respond to SSH. I assume that is because they were generating the new keys when the connection was initiated. Other than that, I haven't noticed a pattern.

Posted: **Sun Apr 29, 2018 11:40 pm**

Some versions ago, the upgrade forced the new SSH key. Don't remember why, but it did. And the key was generated on the first reconnection, not just after the reboot. Perhaps You have some units with older versions, and some with newer?

Posted: **Mon Apr 30, 2018 5:12 am**

Perhaps You have some units with older versions, and some with newer?

Here is a random sampling of a few recent updates to 6.42.1:
1. 6.41: New key generated
2. 6.42: Key not changed
3-10. 6.41: Key not changed
11-14. 6.40.4 Key not changed
15-16. 6.40.4 New key generated

I suppose this might be caused by the router generating a different key type (like only having DSA and then generating RSA). Nope. #15 and 16 started off as an RSA key and finished as a new RSA key. This just happened to me locally so it's not likely MITM. Anyone have any idea why this is happening?

Posted: **Mon Apr 30, 2018 11:53 am**

Two problems with 6.42.1:

IP Neighbour discovery settings in Winbox are shown correctly as !external (ie negate 'external' list; aka all interfaces which are not a member of the 'external' interface list) but 'export' does not include the negate (exclamation mark):

Second problem is that the interface list in Winbox keeps on reloading. This most probably relates to a CCR1036-8G-2S+ router where we have more than 1000 interfaces defined. This occurs in Winbox 3.12 and 3.13, even after clearing cache.

PS: Yes, we have submitted emails to support@mikrotik.com

Posted: **Mon Apr 30, 2018 3:19 pm**

Would be interesting to see more details in this capture: how does transaction look like, flags set, mac addresses etc etc.
Seems, DHCP server is not happy with unicast requests (renewal messages) sent from mikrotik router if these are sent out.

I did few DHCP tests with CHR versions 6.42, 6.42.1, 6.40.5 and cisco soapbox.
MT routers running 6.42, 6.42. send out all DHCP renewal requests towards specific DHCP server with wrong destination MAC address (namely, own MT router MAC address). Only following broadcast requests are sent to "all 1". No surprise, DHCP server would not receive such renewal requests until broadcasts arrive.
When broadcast domain is large and contains devices with ARP proxy feature, some more side effects may be observed.
DHCP renewal on Cisco and MT router running 6.40.5 works as expected.

Mikrotik engineers may want tolook into DHCP client behaviour at least on 6.42 and 6.42.1.
Please send the above to support@mikrotik.com (or shout loud, you're closer to Mikrotik premises than most of us ), but don't rely on Mikrotik staff picking this information from this forum.

Ticket#2018043022003403 sent sniffed data and suppout file

Posted: **Mon Apr 30, 2018 3:40 pm**

Same here lets hope they fix soon.

Posted: **Mon Apr 30, 2018 6:38 pm**

Also interested. I had missed 6.42, but upon upgrading to 6.42.1 EOIP started falling over. This issues isn't highly referenced, so I missed it in any notes I looked for. Had to downgrade but would like to get back to running on the latest releases.

Hi,

do you have any news about the eoip issue?

best regards, Gabor

EoIP Ethernet Frame issue is still there (introduced in 6.42 breaking fragmenting big frames somehow broken) verified on RB2011 and sent supout to MT-support.

Posted: **Mon Apr 30, 2018 7:33 pm**

After having given up on 42.1 for all my clients and moved back to 41.4 I have decided to try out the RC. 43.5.. As Mikrotik has not responded to any of the issues listed in this thread that i know of, I think we might want to assume 42.1 is dead and that the next step will be 43.x ... So I suggest if you can you give that a test and see if that helps or ressolves any of the issues in 42.1..

I moved my home router, a CCR1009 over to 43.5.. As expected Netwatch is still dead and the LED On script command does not work. But I dont seem to be having any immd issues with a simple home router setup. Its been up for 3 days and seems to be doing OK so far in my limited home use.. NAT, some firewall rules, DHCP client and server. NTP client and server.. All that seems to be working OK.

So that was a upgrade from 41.4 to RC43.5 and everything seemed to move over well. BUT, its a very limited SOHO use.

Posted: **Tue May 01, 2018 5:53 am**

After upgrade to 6.42.1 from 6.40.1 I experience strange behavior with our RB2011UiAS.
Some of connected devices can ping default gateway (which is on router) and some - can not. Those who can not, can ping another IP address on the same interface?!?
I'm experiencing strange things like: half of internet sites are unreachable, including many of google sites (but not all).

After many hours of testing I can not determine a reason for all weird things that happened after upgrade.

I'm going to downgrade the router and then will investigate issues, with a second router. Can i downgrade from 6.42.1 to 6.40.1 (that was my previous version) without losing my config? I have no use of master/slave ports (which I know are major change, reflecting configuration of bridges). I know that I can backup and restore config, but I hope to be able to do downgrade from remote site, not having to travel 50 km. for that...

Posted: **Tue May 01, 2018 11:50 am**

6.42.1 killed my metal2..package was updated and every time I upgrade the routerboard to current version, the rb simply stops and doesn't reboot anymore...will just go back to 6.41.3 and forget 6.42..it broke everything

Posted: **Tue May 01, 2018 2:34 pm**

I have the dude problems, is this correct place for announcing this ?

However the dude device box does not recognize snmp -> interface, snmp -> ip, snmp -> routing, snmp -> storage for Linux, and Cisco ASA devices.
I have a parallel run with dude 3.x and the new 6.42.1 version, in old dude it works but not in the new, please see link below:

viewtopic.php?f=8&t=133884

It was solved by using snmp v.2 for the troublesome devices, dude default is snmp v.1 which it always has been.
Something has changed regarding snmp in the dude, snmp discovery is very slow in comparison to the legacy versions 3.x and 4.x (which had a nasty aggressive snmp that could overload devices).

Posted: **Tue May 01, 2018 2:37 pm**

Don't forget to send your finding to the support@mikrotik.com directly.

Posted: **Wed May 02, 2018 12:12 am**

I saw that now I can download automatically the new RB firmware with "Auto upgrade", there's also a way to auto reboot?

Posted: **Wed May 02, 2018 2:12 am**

I saw that now I can download automatically the new RB firmware with "Auto upgrade", there's also a way to auto reboot?

Not at this time must reboot a second time after updating RoS version, then a reboot second time after firmware for firmware update...

Posted: **Wed May 02, 2018 2:13 am**

Post doubled itself

Posted: **Wed May 02, 2018 2:16 am**

I saw that now I can download automatically the new RB firmware with "Auto upgrade", there's also a way to auto reboot?

Also there was talk of perhaps suppressing the firmware reboot message if not needed.

Posted: **Wed May 02, 2018 2:30 am**

I saw that now I can download automatically the new RB firmware with "Auto upgrade", there's also a way to auto reboot?
Also there was talk of perhaps suppressing the firmware reboot message if not needed.

There was also talk of v7

Posted: **Wed May 02, 2018 3:12 am**

Downgrading a RB1100AHx2 from 6.42.1 to 6.40.8 bricked it. Will have to make a trip to the mountain to fix that one. At least I had a backup router in place!

Indeed, every router I have attempted to downgrade from 6.42.1 to 6.39.3 (what we were running fine two weeks ago) gets bricked, regardless of how carefully the downgrade is prepared, and whether it is done via the Dude or completely by hand. In most cases, it comes up without the wireless package installed (my guess is because one of them has an @ in its name for some mysterious reason, and the other one doesn't)... but an attempt to correct by adding the wireless package and rebooting has generally resulted in a router that flaps its ether port forever and has to be replaced, since it is no longer reachable by any method short of a netinstall (and that means a roof climb anyway, so we just replace).

The 6.42.1 caused many of my subscribers with older, single-pol units to go offline, and we had to replace all of them with dual-pol units because I couldn't downgrade. Now I am stuck in a mixed network with no recourse -- I cannot go backwards, and I cannot move forwards.

This upgrade has been a disaster for us. We are still not back to the subscriber speeds we had ten days ago. I am never moving off the stable release again, I don't care what security holes there are. I doubt that a hacker attack could have cost me more time and effort than this hacker patch already has.

Posted: **Wed May 02, 2018 3:16 am**

6.42.1 killed my metal2..package was updated and every time I upgrade the routerboard to current version, the rb simply stops and doesn't reboot anymore...will just go back to 6.41.3 and forget 6.42..it broke everything

My experience indicates that this release does not get along well with single-pol devices -- it trashed a dozen units on our network and every one of them has been single pol. In a network with only about 16 single pol units, that's pretty definitive.

Posted: **Wed May 02, 2018 4:59 pm**

I think a bunch of the same issues we are seeing in 42 are also present in the RC 43. In my test in my own SOHO arrangement at home my ccr1009 is clearly having DHCP issues with my ISP cable modem. It was showing renewing when there did not appear to be any reason to, This issue was previously covered in the this thread.

So ive moved by to 41.4, which for me is stable.

If your device has enough room to have 2 partitions, I recommend copying a known good config and saving the config to it. Activate that partition and then play with 42 or 43. That way its easy to swap back to your known stable state.

I am dissapointed that Mikrotik has not commented on this thread and let us all know what they are doing. They have not provided a plan. In all my time doing Mikrotik ive never see this. We really need a official response from Mikrotik and a plan of action.

Posted: **Wed May 02, 2018 5:13 pm**

We have had 3 instances today alone of routers rebooting themselves with the following message:

14:20:40 system,info router rebooted
14:20:40 system,error,critical router rebooted because some critical program crashed

Please would MikroTik consider backporting the Winbox security fix and releasing 6.41.5?

PS: We run two CCR1036-8G-2S+ as a highly available pair. The issue occurred on 'A' first which shifted traffic to 'B'. 'B' then had the same problem about 1:15 hours later, at which 'A' again became primary. Problem occurred a third time on 'A'. ie: This does not appear to be hardware related...

We have provided support@mikrotik.com with the autosupout.rif file from all 3 instances.

NB: Downgrading from 6.42.1 to 6.41.4 resulted in sfp-sfpplus1 dissapearing. Needed to do a '/sys reset-configuration no-defaults=yes' and reconfigure HA thereafter. We'll force a failover to the router now running 6.41.4 later tonight, if it doesn't happen earlier and downgrade the other router thereafter...

Posted: **Wed May 02, 2018 5:47 pm**

When is the .2???????

disconnected, group key exchange timeout

Were a municipal ISP btw; I seeing this error on every hAP AC I've upgraded across spectrum of devices primarily cell phone from what I've been able to glean.

the update interval is 1h

Posted: **Wed May 02, 2018 6:56 pm**

So the DHCP issue will be addressed in the next RC as per support's replies.

Posted: **Wed May 02, 2018 8:32 pm**

So the next RC is what will address the long list of issues discussed in this thread ? So no security patched 41.4 ? What issues will be addressed ? WIll Netwatch be put back ? When is the scheduled next RC going to be released ? Does 42.1 stay as the current stable ? Or does it get withdrawn ?

Posted: **Wed May 02, 2018 10:03 pm**

So the next RC is what will address the long list of issues discussed in this thread ? So no security patched 41.4 ? What issues will be addressed ? WIll Netwatch be put back ? When is the scheduled next RC going to be released ? Does 42.1 stay as the current stable ? Or does it get withdrawn ?

Have you sent emails to support@mikrotik.com to report the issues you have picked up?

Posted: **Wed May 02, 2018 10:59 pm**

What issues will be addressed ? WIll Netwatch be put back ?

Netwatch is available as always. What has been removed is the capability of Netwatch to call scripts that perform actions that require write permission.
I use Netwatch with scripts that do only a /log action and it still works.

Posted: **Wed May 02, 2018 11:07 pm**

What issues will be addressed ? WIll Netwatch be put back ?
Netwatch is available as always. What has been removed is the capability of Netwatch to call scripts that perform actions that require write permission.
I use Netwatch with scripts that do only a /log action and it still works.

I've run into an issue with the newest releases where the scheduler will not invoke a script if given only its name, but will invoke it if given a full command line of /system script run... I'm still working this issue with support.

I've never used netwatch with a script (just with single command lines), so bear with me if I'm off-target, but is it possible you're running into the same bug? If you have specified only the name of the script, have you tried substituting the full "run" command line? If that doesn't work, have you tried invoking an intermediate script that doesn't require write, and having that script invoke the full command line to run the other script that does? (I think that currently does an end-run around the permission chain, as long as the use actually HAS that permission himself.)

Hope one of these suggestions works for you.

Posted: **Wed May 02, 2018 11:08 pm**

Some new issues Ive discovered today.

We have seen many international hAP AC with disappearing 5g

We set all of them to to country="united states3" frequency-mode=regulatory-domain.
We thought they were not following the country so we have been testing a manual scan-list

Turns out there is a problem with 5775000
was running a scan list of 5180-5240,5745-5805 (IE UNII-1 and UNII-3)

Had a user call saying his Iphone and chromecast couldn't see the 5g
His wlan2 was at 5775, should be fine. remove 5745-5805 Boom he connects.
OK, test it to 5180-5240,5745-5765; Hap chooses 5765000 he connects fine.
Kind of odd but OK, so it set 5180-5240,5745-5765,5785. Hap chooses 5785000 and the devices connect
Confirmed 5775 has issues..
To be sure I down and up the interface a couple of times. Low and behold it ends up on 5775 anyway and nothing will connect.
go back to 5180-5240,5745-5765 and all is well.

I'm now quite sure this is the underlying issue, not the regulatory setting.

Posted: **Thu May 03, 2018 10:31 am**

Some new issues Ive discovered today.

We have seen many international hAP AC with disappearing 5g

We set all of them to to country="united states3" frequency-mode=regulatory-domain.
We thought they were not following the country so we have been testing a manual scan-list

Turns out there is a problem with 5775000
was running a scan list of 5180-5240,5745-5805 (IE UNII-1 and UNII-3)

Had a user call saying his Iphone and chromecast couldn't see the 5g
His wlan2 was at 5775, should be fine. remove 5745-5805 Boom he connects.
OK, test it to 5180-5240,5745-5765; Hap chooses 5765000 he connects fine.
Kind of odd but OK, so it set 5180-5240,5745-5765,5785. Hap chooses 5785000 and the devices connect
Confirmed 5775 has issues..
To be sure I down and up the interface a couple of times. Low and behold it ends up on 5775 anyway and nothing will connect.
go back to 5180-5240,5745-5765 and all is well.

I'm now quite sure this is the underlying issue, not the regulatory setting.

Maybe it detects radar? Check for 5.8G state. It is common issue in noisy environment. I had this problem earlier, autoselect channel works strange even in 2.4G. If there are many other wifi ap's, it selects same channel, because there is no load, but usualy load may rise and mikrotik would not change its channel until reboot.

Posted: **Thu May 03, 2018 2:46 pm**

DHCP client updates acting as not supposed normaly. With 6.40 version, DHCP request is send after 50% lease time. With 6.42.1 version i.e. lease time is 48h, request is send after 42h.

Posted: **Thu May 03, 2018 4:08 pm**

SNMP: Looks like running Dude (on CCR1009-7G-1C-1S+, v6.42.1) and enabling IPv6 (in addition to IPv4) on it makes Dude unable to SNMP poll IPv4 agents (any make and model), however snmpwalk (from Dude) on same agent works (presumably uses / defaults to IPv4, which is obviously also wrong). Once you disable IPv6 on Dude (or enable IPv6 on agents) it works again normally, not firewall rules, single subnet LAN only.

Posted: **Thu May 03, 2018 4:36 pm**

So the DHCP issue will be addressed in the next RC as per support's replies.

Just curious, how this issue was introduced?

Posted: **Thu May 03, 2018 8:36 pm**

RB2011UiAS-2HnD
I get the Internet by DHCP
After upgrade to 6.42.1 :

001.jpg

002.jpg

On 6.42.0 work fine...

MikroTik

v6.42.1 [current]

v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]

Re: v6.42.1 [current]