Page 1 of 1

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 8:39 am
by gonyotuya
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 

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 8:42 am
by daras
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 ?

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 10:08 am
by whitbread
No significant change in disk usage nor disk writes on RB2011, Upgraded from 6.41 to 6.42.1

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 10:11 am
by bennyh
@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?

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 1:04 pm
by SnakeSK
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

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 1:39 pm
by CZFan
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?

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 2:06 pm
by pe1chl
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.

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 2:26 pm
by sindy
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.

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 3:43 pm
by Xymox
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.

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 3:44 pm
by Xymox

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 3:52 pm
by vytuz
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.

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 4:00 pm
by Xymox
6.41.4 needs the security patch and 42.x needs to be reverted to RC.

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 4:06 pm
by eddieb
No problems with 6.42.1 over here, tnx for the great work MT !

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 4:07 pm
by pe1chl
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.

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 5:35 pm
by aaronvonawesome
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.

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 5:53 pm
by td32

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

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 6:03 pm
by aaronvonawesome

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.

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 6:21 pm
by mrz
You should be worried when you see OVPn user logged in message :)

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 6:43 pm
by aaronvonawesome
You should be worried when you see OVPn user logged in message :)
Thank you :)

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 8:03 pm
by 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. 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.

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 9:28 pm
by CZFan
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

Re: v6.42.1 [current]

Posted: Thu Apr 26, 2018 9:36 pm
by bennyh
@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.

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 9:17 am
by daras
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

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 10:12 am
by bennyh

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

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 1:14 pm
by kaspi4
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).

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 1:17 pm
by frank333
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?

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 2:18 pm
by mkx
Default route distance should be 1 or more. It used to be 0 and upgrade magic doesn't fix it.

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 3:56 pm
by zichovsky
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.

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 4:16 pm
by CZFan
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

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 5:11 pm
by frank333
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??)

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 5:18 pm
by hapi
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

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 6:01 pm
by hapi
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.

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 6:04 pm
by CZFan
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

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 6:20 pm
by frank333
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

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 6:57 pm
by pe1chl
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

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 7:10 pm
by squeeze
@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?

Re: v6.42.1 [current]

Posted: Fri Apr 27, 2018 7:29 pm
by coylh
It looks like netwatch is in the advanced-tools package.

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 12:05 am
by IbleedDialtone
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

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 8:11 am
by aoakeley
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

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 8:15 am
by macsrwe
@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.

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 8:20 am
by gcsuri
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.

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 8:21 am
by hapi
A big problem with devices that have a 32MB ram.

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 2:49 pm
by jrpaz
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

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 3:48 pm
by jarda
A big problem with devices that have a 32MB ram.
What exactly?

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 4:10 pm
by teslasystems
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?

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 6:51 pm
by pe1chl
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.

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 8:09 pm
by jrpaz
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.

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 8:13 pm
by CZFan
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

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 10:07 pm
by coffee
My box also got owned ... phew.

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 10:24 pm
by hapi
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.

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 10:29 pm
by CZFan
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

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 10:30 pm
by itmethod
this broke UPNP for me. it worked before I upgraded

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 10:58 pm
by Xymox
@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.

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 11:09 pm
by Xymox
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..

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 11:20 pm
by SnakeSK
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.

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 11:21 pm
by jspool
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!

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 11:45 pm
by Xymox
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...

Re: v6.42.1 [current]

Posted: Sat Apr 28, 2018 11:51 pm
by vasilevkirill
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

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 3:16 am
by jrpaz
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.

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 2:01 pm
by Modestas
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

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 6:25 pm
by Modestas
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.

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 6:33 pm
by sindy
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.

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 7:26 pm
by Modestas
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.

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 7:47 pm
by sindy
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.

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 7:51 pm
by pe1chl
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.

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 8:18 pm
by typicalwisp
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!

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 10:47 pm
by ivanfm
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.

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 10:54 pm
by typicalwisp
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.

Re: v6.42.1 [current]

Posted: Sun Apr 29, 2018 11:40 pm
by Paternot
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?

Re: v6.42.1 [current]

Posted: Mon Apr 30, 2018 5:12 am
by typicalwisp
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?

Re: v6.42.1 [current]

Posted: Mon Apr 30, 2018 11:53 am
by bbs2web
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):
Image


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

Re: v6.42.1 [current]

Posted: Mon Apr 30, 2018 3:19 pm
by CZFan
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

Re: v6.42.1 [current]

Posted: Mon Apr 30, 2018 3:40 pm
by jrpaz
Same here lets hope they fix soon.

Re: v6.42.1 [current]

Posted: Mon Apr 30, 2018 6:38 pm
by Alloca
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.

Re: v6.42.1 [current]

Posted: Mon Apr 30, 2018 7:33 pm
by Xymox
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.

Re: v6.42.1 [current]

Posted: Tue May 01, 2018 5:53 am
by gkostov
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...

Re: v6.42.1 [current]

Posted: Tue May 01, 2018 11:50 am
by tristanedward
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

Re: v6.42.1 [current]

Posted: Tue May 01, 2018 2:34 pm
by steen
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).

Re: v6.42.1 [current]

Posted: Tue May 01, 2018 2:37 pm
by jarda
Don't forget to send your finding to the support@mikrotik.com directly.

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 12:12 am
by Redmor
I saw that now I can download automatically the new RB firmware with "Auto upgrade", there's also a way to auto reboot?

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 2:12 am
by 105547111
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...

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 2:13 am
by 105547111
Post doubled itself :-(

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 2:16 am
by 105547111
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.

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 2:30 am
by jspool
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

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 3:12 am
by macsrwe
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.

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 3:16 am
by macsrwe
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.

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 4:59 pm
by Xymox
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.

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 5:13 pm
by bbs2web
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...

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 5:47 pm
by dougunder
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

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 6:56 pm
by jrpaz
So the DHCP issue will be addressed in the next RC as per support's replies.

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 8:32 pm
by Xymox
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 ?

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 10:03 pm
by dasvos
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?

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 10:59 pm
by pe1chl
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.

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 11:07 pm
by macsrwe
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.

Re: v6.42.1 [current]

Posted: Wed May 02, 2018 11:08 pm
by dougunder
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.

Re: v6.42.1 [current]

Posted: Thu May 03, 2018 10:31 am
by vytuz
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.

Re: v6.42.1 [current]

Posted: Thu May 03, 2018 2:46 pm
by vytuz
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.

SNMP

Posted: Thu May 03, 2018 4:08 pm
by Joni
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.

Re: v6.42.1 [current]

Posted: Thu May 03, 2018 4:36 pm
by juliokato
So the DHCP issue will be addressed in the next RC as per support's replies.
Just curious, how this issue was introduced?

Re: v6.42.1 [current]

Posted: Thu May 03, 2018 8:36 pm
by netmouse
RB2011UiAS-2HnD
I get the Internet by DHCP
After upgrade to 6.42.1 :
001.jpg
002.jpg
On 6.42.0 work fine...

Re: v6.42.1 [current]

Posted: Thu May 03, 2018 11:51 pm
by dsnyder
You can add another unhappy customer to the Netwatch limitations. I was calling a script to failover to a secondary internet connection and disable/enable policies and rules for VPNs for the alternate IP address. This morning the primary internet went at an office and they went dead, no failover. So now I have to explain that this fancy contraption that I sold them really does work, just not this one time because they changed the way it works...

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 12:40 am
by pe1chl
There are better ways to do that than with Netwatch and scripts...

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 7:00 am
by Xymox
There may be better ways then Netwatch, but, Netwatch worked great for him and Mikrotik deprecated the functionality. I use it to send me alerts via email, is there a better way to do this ?
So the DHCP issue will be addressed in the next RC as per support's replies.
Just curious, how this issue was introduced?
Im curious how all these really varied issues were introduced, DHCP is just one of them. But YEA this DHCP one is really curious. Why would the DHCP code be played with for this stable version release ?

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 10:21 am
by vytuz
RB2011UiAS-2HnD
I get the Internet by DHCP
After upgrade to 6.42.1 :
On 6.42.0 work fine...
if ISP (or router before this) dhcp lease is short (i guess it is 5minutes in Your case), with 6.42.1 version mikrotik asks for ip ~30seconds before lease (not ~2min). If there are many dhcp users, a lot broadcast, that may be dropped and i guess it just has no time to repeat for another request.

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 12:48 pm
by netmouse
RB2011UiAS-2HnD
I get the Internet by DHCP
After upgrade to 6.42.1 :
On 6.42.0 work fine...
if ISP (or router before this) dhcp lease is short (i guess it is 5minutes in Your case), with 6.42.1 version mikrotik asks for ip ~30seconds before lease (not ~2min). If there are many dhcp users, a lot broadcast, that may be dropped and i guess it just has no time to repeat for another request.
I get real static IP address from provider DHCP

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 2:19 pm
by michnzee
After upgrade to RoS 6.42.1 crashed bonding (LACP, 802.3ad, 4 gigabit ports) with Synology DS1517+ (4 gigabit ports). All ports are online but without traffic, dhcp... restart not working :(

Solution - disable bonding interface, withdraw one port from bonding, disable bonding interface in bridge and make only one lan port active.

Any suggestion? do you use also LACP and bondig?

RB: CRS326-24G-2S+RM

LACP config:
lacp.png

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 2:51 pm
by mkx
RB2011UiAS-2HnD
I get the Internet by DHCP
After upgrade to 6.42.1 :
On 6.42.0 work fine...
if ISP (or router before this) dhcp lease is short (i guess it is 5minutes in Your case), with 6.42.1 version mikrotik asks for ip ~30seconds before lease (not ~2min). If there are many dhcp users, a lot broadcast, that may be dropped and i guess it just has no time to repeat for another request.
I get real static IP address from provider DHCP
If you get "real static IP address" from your ISP, then I wonder why you're configuring DHCP client - you should be configuring static address on your RB and be done with it.
If you're getting "pseudo static" IP address (is in: getting always the same IP address via DHCP lease), then all the DHCP woes still apply to your RB, including short lease times and what not ... Your RB has no way of knowing that it will get exactly the same IP address in next lease.

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 3:10 pm
by pe1chl
If you get "real static IP address" from your ISP, then I wonder why you're configuring DHCP client - you should be configuring static address on your RB and be done with it.
The advantage of using DHCP is that it configures the address, netmask, gateway (default route) and DNS resolvers (and maybe even NTP servers) automatically and without error.
So it is best to use DHCP when possible. However, to work around the current issue I would temporarily configure those items manually and disable the DHCP client until MikroTik fixes it.

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 3:23 pm
by mkx
The advantage of using DHCP is that it configures the address, netmask, gateway (default route) and DNS resolvers (and maybe even NTP servers) automatically and without error.
I understand the benefits of using DHCP in case of assigning "static" addresses. But there's a big gotcha: if customer changes router (different MAC address of its WAN port), this will break setup. Some ISPs just don't bother with static DHCP leases (my parents are victims of one of those) so one has to configure everything by hand.
As to my understanding of benefits: only recently I was bitten ... ISP decided to split their /16 customer network to two /17 parts ... and I'd have to change GW address. Which I didn't as I never received any announcement from them (and neither have my parents). Ended up with driving 50 km there and back one Sunday afternoon to fix the internet for my parents. In this case, DHCP would do miracles :wink:

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 4:08 pm
by pe1chl
I understand the benefits of using DHCP in case of assigning "static" addresses. But there's a big gotcha: if customer changes router (different MAC address of its WAN port), this will break setup.
This depends on the ISP configuration. It is also possible to assign the address to a "Circuit ID" instead of the MAC address. That is the wellknown DHCP option 82 that is always asked for in the feature request topics. But when the ISP doesn't use MikroTik, they can do it already.

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 4:15 pm
by Chupaka
That is the wellknown DHCP option 82 that is always asked for in the feature request topics. But when the ISP doesn't use MikroTik, they can do it already.
Just to be honest, we were using DHCP Option 82 on RouterOS since 2008 (up to 2017, when we sold our ISP) - so if you're large enough to allow you to run RADIUS - you can use Option82 on MikroTik DHCP Server :)

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 4:50 pm
by mkx
I understand the benefits of using DHCP in case of assigning "static" addresses. But there's a big gotcha: if customer changes router (different MAC address of its WAN port), this will break setup.
This depends on the ISP configuration. It is also possible to assign the address to a "Circuit ID" instead of the MAC address. That is the wellknown DHCP option 82 that is always asked for in the feature request topics. But when the ISP doesn't use MikroTik, they can do it already.
In the case of my parents I doubt they do anything fancy beyond simplest dynamic DHCP leases. They are running FTTH network (over own fibres) and xDSL (local-loop sharing). The equipment on customer premisses is simple (managed?) ethernet switch with one optical interface (in case of my parents optical port is fixed, not SFP) and many electrical RJ45 ports. It doesn't matter which RJ45 port is used. If there's other equipment (VoIP gateway, IPTV set-top box) it is connected to the same ethernet switch. I guess that I could plug in another device (e.g. laptop) and would get dynamic DHCP address just fine. They must know about "Circuit ID" though to enforce bandwidth limitations (when doing speed tests, it is obvious they are doing traffic shaping as throughput in uplink quickly increases above cap, but after a few seconds it settles at subscribed rate).
When my parents upgraded from VDSL (simple ethernet tunneling, no PPPoE or anything) to FTTH, they had dynamic address ... which didn't change as they continued to use same router. Which indicates that their core network infrastructure is quite flat. They never played any games about changing IP addresses after DHCP lease expired (to prevent customers from seting-up own internet servers) ...

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 5:30 pm
by sindudas
This issue is breaking some scripts. On terminal:
/system leds set numbers=0 type=
align-down align-right ap-cap flash-access interface-... modem-technology on poe-out wireless-status
align-left align-up fan-fault gps-valid modem-signal off poe-fault wireless-signal-strength
It show "on" as an option, but it refuses to use it:
/system leds set numbers=0 type=on
input does not match any value of type

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 5:52 pm
by Chupaka
Not sure what you mean, but "numbers=0" is incorrect in scripts.

Re: v6.42.1 [current]

Posted: Fri May 04, 2018 8:14 pm
by Xymox
This issue is breaking some scripts. On terminal:
/system leds set numbers=0 type=
align-down align-right ap-cap flash-access interface-... modem-technology on poe-out wireless-status
align-left align-up fan-fault gps-valid modem-signal off poe-fault wireless-signal-strength
It show "on" as an option, but it refuses to use it:
/system leds set numbers=0 type=on
input does not match any value of type
I believe this si what i already reported..

/system leds set leds=user-led type=on 1 does not work in scripting or from command line on 42.x RC43.x /system leds set leds=user-led type=off 1 does work.. You can however turn on/off LEDs from Winbox.

Re: v6.42.1 [current]

Posted: Sat May 05, 2018 2:48 am
by cocktail
I discovered that MikroTik hAP ac2's DHCP client on wlan1 in station mode cannot receive an IP address from a wireless router after upgrading to 6.42.1
DHCP client on wlan1 is stuck at `Status: searching...`
It takes a few minutes to renew DHCP client lease on ether1 which is the WAN interface.

Re: v6.42.1 [current]

Posted: Sat May 05, 2018 9:52 am
by steen
Hello Folks!

I have problem backing up configuration on practically all devices using ros 6.42 or bigger, just discovered it today.

The message I got is: "backup,critical error creating backup file: could not read all configuration files"

There is no full filesystems and other visible errors.

Re: v6.42.1 [current]

Posted: Sat May 05, 2018 12:25 pm
by tdw
I'm also seeing "backup,critical error creating backup file: could not read all configuration files" messages after upgrading on several devices.

2x RB750 v6.39.3 -> v6.42.1
2011UAS-2HnD v6.41.4 -> v6.42 (may also have produced the same message) -> v6.42.1

All appear to be operating fine, backup worked beforehand, /export verbose doesn't report any errors before or after.

Re: v6.42.1 [current]

Posted: Sat May 05, 2018 9:08 pm
by steen
Hello Folks!

I face another issue.... this time our wireless 802.11bgn office landscape is crippled.
Wireless speed drops down to nothing and they got disconnected all the time.
The various mikrotik devices CPU rushes up to 100% when wifi traffic starts to flow, and wifi speed drops to nothing.

There is also another issue, sometimes when a user copies some big files over wifi network, all seem fine, but when another user does the same the wifi crashes for both of them.
I some other situations CPU does not go sky high, but the wifi network behaves in the same way.

We never saw this issue from before ever, it has been _rock solid_ for years, this issue come directly after last upgrade...

The devices are multiple RB411, RB433, it started to happen after upgrading to 6.42.1 (also observed at 6.42 but it did not kill the networks like now).
Yes, they are old devices, but we have plenty in operation and in stock.

We tried by disabling snmp, but it did not make any difference.

Some addition, we took out one device and re-imaged it with 6.42.1, using netinstall and then restored back the original configuration.
Unfortunately it did not make any difference at all, wifi is still unstable.

Last addition for today, by rolling back to 6.41.3 stabilized the WiFi network, there has clearly happened something with WiFi between 6.41.3 and 6.42.1.
Other observations, the device boots up faster, response on command line is much faster in 6.43.1 than 6.42.1 which boot up is slower and command line is sluggish and lagging.

Currently I try to generate support files for mikrotik to take a look on, the support is generated and will be delivered to Mikrotik.

Anyone who have seen Wifi get killed from RoS 6.42-6.42.1 ?

Re: v6.42.1 [current]

Posted: Sat May 05, 2018 9:42 pm
by rzirzi
After update to 6.42.1 I have a BIG problem with x86 platform with additional Intel LAN i350 card. When I want to connect to MikroTik via that Intel i350 LAN - theMikroTik ROS is rebooting!! - EVERY TIME!! so - there is a problem with MikroTik ROS 6.42.x with Intel I350. There is no problem at ROS 6.41 - it works OK, but after update to 6.42.x - there is a problem! Please repair!

Re: v6.42.1 [current]

Posted: Sat May 05, 2018 10:00 pm
by eworm
Hello Folks!

I have problem backing up configuration on practically all devices using ros 6.42 or bigger, just discovered it today.

The message I got is: "backup,critical error creating backup file: could not read all configuration files"

There is no full filesystems and other visible errors.
I saw the same on three devices. Contacted support, they told me to netinstall. I did and restored the backup. Everything was there except system note and setting for auto-upgrade (which changed from 'yes' to default 'no').

Re: v6.42.1 [current]

Posted: Sat May 05, 2018 10:38 pm
by steen
Hello Folks!

I have problem backing up configuration on practically all devices using ros 6.42 or bigger, just discovered it today.

The message I got is: "backup,critical error creating backup file: could not read all configuration files"

There is no full filesystems and other visible errors.
I saw the same on three devices. Contacted support, they told me to netinstall. I did and restored the backup. Everything was there except system note and setting for auto-upgrade (which changed from 'yes' to default 'no').
Okidoki, we just reimaged one device using netinstall, and then the backup completed without the error message.

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 1:27 am
by tdw
Hello Folks!

I have problem backing up configuration on practically all devices using ros 6.42 or bigger, just discovered it today.

The message I got is: "backup,critical error creating backup file: could not read all configuration files"

There is no full filesystems and other visible errors.
I saw the same on three devices. Contacted support, they told me to netinstall. I did and restored the backup. Everything was there except system note and setting for auto-upgrade (which changed from 'yes' to default 'no').
Okidoki, we just reimaged one device using netinstall, and then the backup completed without the error message.
That's fine if the device is local, not much use if the tik is several hours drive away. As three out of three upgrades are exhibiting this behaviour I'm reluctant to upgrade ~25 others scattered around the country if backups can no longer be made successfully without visits to reinstall.

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 6:49 am
by Xymox
And the incredibly wide ranging and completely unrelated issues just keep coming. Backup issues, weird wifi issues and a different sort of DHCP issue.. I can confirm the backup issue and the wifi issue. I updated a mAP and im not sure of everything that failed, but I know wifi was really weird because it was not connecting with the same signal strenght by 75%, I could not get a IP from DHCP and it was not obtaining a IP on its wan side. I fact reset it and that got me connected to it, then I downgraded and restored the backup from just before the upgrade and it came right back to fully normal.

Apollo 13 mission: "Lets look at this from a standpoint of status.. What do we have on the spacecraft thats good ?"
https://www.youtube.com/watch?v=Z0h2Wk6-C_I

This problems people are seeing are serious, 42.x needs to be deprecated, 43 looks like mostly the same issues. As I keep saying 41.4 needs a security patch then make that the stable. Work on 43 and get it all fixes with this long list of issues and then release it in a month or 2 once its truly tested stable.

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 9:23 am
by steen
And the incredibly wide ranging and completely unrelated issues just keep coming. Backup issues, weird wifi issues and a different sort of DHCP issue.. I can confirm the backup issue and the wifi issue. I updated a mAP and im not sure of everything that failed, but I know wifi was really weird because it was not connecting with the same signal strenght by 75%, I could not get a IP from DHCP and it was not obtaining a IP on its wan side. I fact reset it and that got me connected to it, then I downgraded and restored the backup from just before the upgrade and it came right back to fully normal.

Apollo 13 mission: "Lets look at this from a standpoint of status.. What do we have on the spacecraft thats good ?"
https://www.youtube.com/watch?v=Z0h2Wk6-C_I

This problems people are seeing are serious, 42.x needs to be deprecated, 43 looks like mostly the same issues. As I keep saying 41.4 needs a security patch then make that the stable. Work on 43 and get it all fixes with this long list of issues and then release it in a month or 2 once its truly tested stable.
It took us whole Saturday evening finding out that a rollback was only option to stabilize the WiFi network and the platform.

I will also issue a direct warning, we could not downgrade the devices without netinstall, you will need to netinstall them to get back on track again.
In the serial console we would see the devices get stuck at boot, directly after generating some ssh-host-keys, with a message saying "to many nested links".
A good thing was at least backups worked, 6.42.1 claimed configuration files could not be read.

We have however a some devices not showing any signs of problems with this versions, but they all claim backup, "critical error creating backup fule: could not read all configuration files"

And yes, I finally managed to get some support file and made a report to Mikrotik who hopefully solves this issues quickly so we can get back on track again.

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 3:23 pm
by Modestas
RB2011UiAS-2HnD
I get the Internet by DHCP
After upgrade to 6.42.1 :
On 6.42.0 work fine...
if ISP (or router before this) dhcp lease is short (i guess it is 5minutes in Your case), with 6.42.1 version mikrotik asks for ip ~30seconds before lease (not ~2min). If there are many dhcp users, a lot broadcast, that may be dropped and i guess it just has no time to repeat for another request.
Hi
I don't share this view.
Please note that DHCP renewal use unicast messages (see example in https://www.cloudshark.org/captures/0009d5398f37 and appendix B at https://www.netmanias.com/en/?m=view&id ... cs&no=5998). While unicast communication with DHCP server is working properly binding will not expire and there will be no transition to rebinding phase with excessive broadcasts.
It's also DHCP server (let's say, network designer) decision to offer and approve certain lease time. Clients have not so much other options than respecting server policy.
I don't think single unicast request/ack transaction per 1 min can be considered as serious load in 2018.
However, Mikrotik releases 6.42.* seem to have something broken in DHCP client or maybe fastpath code. This affects DHCP renewal messages delivery to DHCP server and consequent transition to rebinding.

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 4:47 pm
by steen
And the incredibly wide ranging and completely unrelated issues just keep coming. Backup issues, weird wifi issues and a different sort of DHCP issue.. I can confirm the backup issue and the wifi issue. I updated a mAP and im not sure of everything that failed, but I know wifi was really weird because it was not connecting with the same signal strenght by 75%, I could not get a IP from DHCP and it was not obtaining a IP on its wan side. I fact reset it and that got me connected to it, then I downgraded and restored the backup from just before the upgrade and it came right back to fully normal.

Apollo 13 mission: "Lets look at this from a standpoint of status.. What do we have on the spacecraft thats good ?"
https://www.youtube.com/watch?v=Z0h2Wk6-C_I

This problems people are seeing are serious, 42.x needs to be deprecated, 43 looks like mostly the same issues. As I keep saying 41.4 needs a security patch then make that the stable. Work on 43 and get it all fixes with this long list of issues and then release it in a month or 2 once its truly tested stable.
It took us whole Saturday evening finding out that a rollback was only option to stabilize the WiFi network and the platform.

I will also issue a direct warning, we could not downgrade the devices without netinstall, you will need to netinstall them to get back on track again.
In the serial console we would see the devices get stuck at boot, directly after generating some ssh-host-keys, with a message saying "to many nested links".
A good thing was at least backups worked, 6.42.1 claimed configuration files could not be read.

We have however a some devices not showing any signs of problems with this versions, but they all claim backup, "critical error creating backup fule: could not read all configuration files"

!Correction!:
I have to correct myself, the devises not showing any signs of problems had the local WiFi disabled and acting as router for the wired network only.
So with that in mind, _all_ devices upgraded to 6.42.1 (starting with 6.42), has problems with WiFi. All of them had to be downgraded with netinstall, they all get stuck in the boot process.
It now goes for, rb411, rb433 and rb435., around 10 devices in total before we discovered it due to its creepiness nature. All actually look fine after an upgrade, problem comes when someone starts to use the WiFi, then the whole device is affected, CPU peaks in bursts making console sluggish ultimately the device ends up with 100% cpu all the time and hence becomes unresponsive.

And yes, I finally managed to get some support file and made a report to Mikrotik who hopefully solves this issues quickly so we can get back on track again.

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 7:45 pm
by sovaby
Hi ! in the wiki documentation for pptp
default-route-distance (byte [0..255]; Default: 1)	sets distance value applied to auto created default route, if add-default-route is also selected
Range of distance from 0 to
Image

And so it was before this version .
And after the upgrade to v6.42.1 , I get an error !
Image
Image

Dynamic routing stops working
And my ISP requires that you get the settings from DHCP. Not having received auto settings, the connection will not get the provider's authorization.
What to do ?

It's good that I had a stoped duplicate connection.
If you do not touch it, it will work with the old value default-route-distance = 0.
If in the settings of this connection, something to change you will not be able to save it!

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 8:19 pm
by sindy
I'd say change the default-route-distance parameter in your /ip dhcp-client settings to 2, and the pptp dynamic route will win with default-route-distance=1. It doesn't need to be exactly 0 for pptp and 1 for dhcp, it can be 5 and 7 and you're still good. Distance 0 is reserved for directly connected networks so the change was towards a more systematic behaviour.

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 8:27 pm
by sovaby
I was played with manual routing
distance 2 (3 ...) for ethernet and for the pptp client distance 1.
This does not work! The provider says, until you get the settings automatically from DHCP, you do not get the authorization for passing packets.
And from the provider the distance 0 is flying for ethernet!
pptp sets distance 1 for default route and does not work because the packets leave through the ethernet default route!

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 9:01 pm
by sindy
I was played with manual routing
distance 2 (3 ...) for ethernet and for the pptp client distance 1.
This does not work! The provider says, until you get the settings automatically from DHCP, you do not get the authorization for passing packets.
And from the provider the distance 0 is flying for ethernet!
pptp sets distance 1 for default route and does not work because the packets leave through the ethernet default route!
You have clarified enough that you have to use the DHCP client to get your WAN address, otherwise the provider won't enable your connection, that was crystal clear to me already before.

What I was trying to say was that the same setting which you were using on /interface pptp also exists on /ip dhcp-client and other interfaces/protocols with dynamic configuration. So instead of setting lower-than-default distance at pptp, you can set higher-than-default distance at dhcp-client.

Of course, distance 0 for the local subnet between you and the provider will always be there, but the default route is for 0.0.0.0/0 and its distance will be set according to the default-route-distance parameter. And you don't need to access the subnet between you and the ISP via the PPTP tunnel, do you?

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 9:20 pm
by sovaby
I'll try it! Thanks, I found =)

It works, thanks!
Image

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 10:17 pm
by eworm
Hello Folks!

I have problem backing up configuration on practically all devices using ros 6.42 or bigger, just discovered it today.

The message I got is: "backup,critical error creating backup file: could not read all configuration files"

There is no full filesystems and other visible errors.
I saw the same on three devices. Contacted support, they told me to netinstall. I did and restored the backup. Everything was there except system note and setting for auto-upgrade (which changed from 'yes' to default 'no').
Okidoki, we just reimaged one device using netinstall, and then the backup completed without the error message.
That's fine if the device is local, not much use if the tik is several hours drive away. As three out of three upgrades are exhibiting this behaviour I'm reluctant to upgrade ~25 others scattered around the country if backups can no longer be made successfully without visits to reinstall.
Whoever suffers this should consider to contact support as well. Perhaps they become aware that this is a real issue and fix the cause. If anybody wants to reference me... Ticket#2018041822006577

BTW, I saw this happen first time on 6.42rc52.

Re: v6.42.1 [current]

Posted: Sun May 06, 2018 10:31 pm
by macsrwe
The message I got is: "backup,critical error creating backup file: could not read all configuration files"
I saw the same on three devices. Contacted support, they told me to netinstall. I did and restored the backup. Everything was there except system note and setting for auto-upgrade (which changed from 'yes' to default 'no').
Okidoki, we just reimaged one device using netinstall, and then the backup completed without the error message.
That's fine if the device is local, not much use if the tik is several hours drive away. As three out of three upgrades are exhibiting this behaviour I'm reluctant to upgrade ~25 others
Whoever suffers this should consider to contact support as well. Perhaps they become aware that this is a real issue and fix the cause. If anybody wants to reference me... Ticket#2018041822006577

BTW, I saw this happen first time on 6.42rc52.
I’m pretty confident that MikroTik can correct this issue without forcing everyone in the world to netinstall their devices. This exact behavior and message was occurring on about a dozen CPEs on our network for a year after the SXT was introduced, which was around the time of ROS 5.25. I reported this in June 2013, ticket number 2013061466000351. Upon the advice of MT support, I netinstalled a handful of them, and the problem went away on those, though it reoccurred on some of them within weeks. After about a year, that message had totally disappeared from our network, and not because of anything we did, so it must’ve been fixed in ROS. It’s time to do that again.

Re: v6.42.1 [current]

Posted: Mon May 07, 2018 12:51 am
by S4bulba
Hi ,

I am a user of a 951Ui-2nD and i want to give some feedback regarding this update.

I ve bought the router few months ago as new and since i ve updated the default OS everytime a new version showed up , never paid attention to the firmware upgrade though ,untill this OS update - 6.42.1 .
I am using the device as a pppoe client to the ISP.
Default firmware was 3.36.

Prior to this update i was using 6.42.with firmware 3.36 (the factory one).With 6.42 i was having some rare timeouts (connnection was dropping) in aquiring the dynamic pppoe adress from the ISP, so i updated to 6.42.1 to see if this issue goes away and increase device security as well.
For one day the device run this update with firmware 3.36 and it looked ok , so i ve decided to upgrade the firmware as well from the winbox interface ,now it s 6.42.1 in the routerboard page .
After this the ISP drops would be 2-3 times at every 12 hours , so i wanted to roll back in some way and decided to roll back to the previous version , so i ve clicked the Downgrade button from Package list page ,nothing hapened , so again i ve decided to test the bugfix build from the package channel and i ve downgraded to 6.40.8.
Device rebooted , looked like working and i could log in via winbox ,but the router would push errors in log window ( was creating some Samba shares ?!? as per log for example) and would reboot after some minutes after each new boot , a delayed continuous loop .
As such i ve decided to go back to 6.42.1 right after a fresh reboot and i was lucky enough to do it :).Router did some automatic installation checking routine afterwards , corrected some errors and everythoing was and is now ok ,7 days with no ISP connection drop.
So maybe there is a realtion between the firmware used and OS used and /or maybe the firmware should be updated prior to the OS.
It s strange that the downgrade button did nothing. :)
No special issues for me with this build as a casual user

LE:
I would have a suggestion also
Maybe by default the firewall rule ""defconf: drop all from WAN not DSTNATed"" (for the INPUT chain) which by default is in the lower side of the page of the firewall, should be placed by default in the upper side of the ruleset ,after the dummy rule so the BAD traffic is dropped properly .Where it was put by default would not pick up any packets.

Re: v6.42.1 [current]

Posted: Mon May 07, 2018 9:15 am
by dynek
Regarding message poping up when generating a backup file, same problem, same answer (netinstall) but I don't feel like it honestly...
viewtopic.php?f=2&t=73610&p=658544#p658544

Re: v6.42.1 [current]

Posted: Mon May 07, 2018 9:47 am
by steen
Regarding message poping up when generating a backup file, same problem, same answer (netinstall) but I don't feel like it honestly...
viewtopic.php?f=2&t=73610&p=658544#p658544
We stopped rolling out 6.42.1 and the other with same problem 6.42, and rolled back by using netinstall.
netinstall is doable for few devices or in your private home network where you can reach all devices by simply walking around.
but in a bigger scale it is not an option, except in a disaster, in our case it is equivalent with start replacing customer devices including ladders, elevators and roof walks.
As anyone could understand it would be a very costly operation.

Re: v6.42.1 [current]

Posted: Mon May 07, 2018 9:53 am
by cocktail
My issue with 6.42.1 actually turned out to be an issue with another router from another manufacturer.

Re: v6.42.1 [current]

Posted: Tue May 08, 2018 7:51 am
by ricake24
im trying 2 upgrad on that lol

Re: v6.42.1 [current]

Posted: Tue May 08, 2018 8:26 am
by Jotne
No one else has this problem?
DHCP does not log to external server any more: viewtopic.php?f=2&t=134092&sid=345291ea ... d0515cef3e
Should I post a support ticket?

Re: v6.42.1 [current]

Posted: Tue May 08, 2018 8:46 am
by jarda
You always should.

Re: v6.42.1 [current]

Posted: Tue May 08, 2018 9:15 am
by dynek
No one else has this problem?
DHCP does not log to external server any more: viewtopic.php?f=2&t=134092&sid=345291ea ... d0515cef3e
Should I post a support ticket?
Answered your thread - It did work for me.

Re: v6.42.1 [current]

Posted: Tue May 08, 2018 11:32 am
by hapi
drop client and never connecting back.

Image

after reboot:

Image

Only NV2 is function. This is not the only case.

Re: v6.42.1 [current]

Posted: Wed May 09, 2018 9:46 am
by nkm
i had problem.
my throughput was low
so , i checked my config and i saw the fast forward in bridge interface goes "No" by default,
in the older versions and wiki site ( https://wiki.mikrotik.com/wiki/Manual:I ... Properties ), it's "Yes" by default.

Did change it in the new version?

Re: v6.42.1 [current]

Posted: Wed May 09, 2018 3:56 pm
by kaspi4
Got similar issue on my 3011, disabling hardware offload(new feature from your 6.40.1 version) on all bridge ports helped me.
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.

Re: v6.42.1 [current]

Posted: Wed May 09, 2018 5:31 pm
by adik777
Hi!
Problem with LEDs type on v6.42.1 with CCR1009,CCR1016,RB2011,RB3011:
LED "user-led"=off
[vadym@PPC-5_CCR1009] /system leds> :put [/system leds get [find where leds="user-led"] type]     
off

LED "user-led"=on]
[vadym@PPC-5_CCR1009] /system leds> :put [/system leds get [find where leds="user-led"] type]
(unknown)

set LED "user-led"=on
[vadym@PPC-5_CCR1009] /system leds> /system leds set [find where leds="user-led"] type=on     
input does not match any value of type


Re: v6.42.1 [current]

Posted: Wed May 09, 2018 5:43 pm
by Chezgendron
Hi,

I just updated my routerboard 2011UiAS-2HnD to the latest firmware 6.42.1 version. Before that it ran on factory firmware 3.22 and used the hotspotserver without any problem. After updating I get the message "Hotspot Setup - setup failed to setup dhcp server: failed to add DHCP server: can not run on slave interface (6) (8)" if I want to finish the hotspot setup in the webfig. Can anybody tell me why I get this message now and never before with the old firmware?

Thanks,

Alex

Re: v6.42.1 [current]

Posted: Thu May 10, 2018 11:45 am
by sovereignt
I use eoip to build L2 tunnel between two switches. In earlier than 6.41 version the bridge can receive LLDP, LACP, RSTP and transport to remote switch via eoip tunnel, it's working fine. But after upgrade ros to 6.41, all of the above packet is block. In the 6.42.1 version changelogs, I find it fixed LLDP packet receiving bug and it's working fine for LLDP when I upgrade ros. But LACP and RSTP is also block. I have already set /interface bridge protocol-mode=none.
Anyone can help?

Re: v6.42.1 [current]

Posted: Thu May 10, 2018 3:12 pm
by kodzikirus
-------------------------------------------------------------------------------------------------------------------
# may/10/2018 13:40:52 by RouterOS 6.42.1
# software id = VUPQ-V2AI
#
13:31:55 system,info router rebooted
13:31:56 system,error,critical router rebooted because some critical program crashed
----------------------------------------------------------------------------------------------------------------------
3 causes after upgrade to 6.42.1 ( CCR1036-8G-2S+ with 60-70 OVPN tunnels)
26-th of April, 4-th of May, 10-th of May

P.S.: Other CCR1036-8G-S+ taht is upgraded to 6.42.1 too, has no this problems (uptime and works 16 days), but he has'nt OVPN's - he is reserv with a 2 ISP's and main site works from him.
Have any ideas?

Re: v6.42.1 [current]

Posted: Thu May 10, 2018 7:22 pm
by Son1c
Returning to the increase of the parameter "Sector write since reboot" on 6.42.1, i have about 3k writes instead of about 700-800 on 6.43.rc3 after 12 hours uptime. Is it a bug or a feature?
RB951G-2HnD

Re: v6.42.1 [current]

Posted: Thu May 10, 2018 7:46 pm
by lomayani
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
I confirm this issue is fixed in 6.43rc11. I tested for couple of hours and am not seeing crashes

Re: v6.42.1 [current]

Posted: Fri May 11, 2018 9:13 am
by JimmyNyholm
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.
On a pure Router it is better to not enable the Firewall AT ALL and have Fastpath enabled still. IPRestrict IPSERVICES in their setting (Disable services that you will not use) and IPRESTRICT USERS login from in their setting. We don't need any firewall for that basic security.

Re: v6.42.1 [current]

Posted: Fri May 11, 2018 12:07 pm
by WirtelPL
Returning to the increase of the parameter "Sector write since reboot" on 6.42.1, i have about 3k writes instead of about 700-800 on 6.43.rc3 after 12 hours uptime. Is it a bug or a feature?
RB951G-2HnD
I reported the problem to Mikrotik ([Ticket#2018042722002867]). In response I got:
"...Sector write value which shows NAND lifetime, but more precisely you can read in these articles: https://wiki.mikrotik.com/wiki/Manual:R ... bad_blocks, https://wiki.mikrotik.com/wiki/Manual:S ... Properties ..."

My actually values are:

Re: v6.42.1 [current]

Posted: Fri May 11, 2018 12:45 pm
by leon84
Hi to all,
I updated RouterBoard 450 from 5.26 to 6.42.1 and now the routerboard doesn't boot. It reboot continously !
Can you help me?
Thanks

Re: v6.42.1 [current]

Posted: Fri May 11, 2018 1:23 pm
by maxfava
With 6.42.1 we noted the following issues:
a) Marking assured and related packet as fast track, after a while some SIP client is not able to receive the calls even if seems registered. The connection tracking table has the entry of the UDP packet, and it receive from the server SIP the call but seems that router NAT does not forward to internal host. I have removed the fast track rule (action fast track for packets that are assured and related in filter rule) and it solves the issue.
b) But after the fast track firewall rule disabled the UDP connections with dst-port 5060 are not marked as sip connection-type but as general UDP stream, applying on connection tracking table 3 minutes timeout instead of 60 minutes. I have not rebooted yet, since is a production router, I have planned reboot this night, hope can solve.

Re: v6.42.1 [current]

Posted: Fri May 11, 2018 4:47 pm
by TestCRS
Please answer: switch crs317 dont forwards the qinq packets at wire-speed, why ?

Re: v6.42.1 [current]

Posted: Fri May 11, 2018 4:59 pm
by Chupaka
Please answer: switch crs317 dont forwards the qinq packets at wire-speed, why ?
How do you check it? Was it working at wire-speed in previous versions?

Re: v6.42.1 [current]

Posted: Fri May 11, 2018 7:52 pm
by rzirzi
I think ROS 6.42.1 i VERY buggy version :( Many,many things not working or working randomly. For instance - next NOT working: Intel i350 miniPCIe cards at x86, working "randomly" Queues. Today I have had NOT working Simple Queues at one x86 machine. I was looking for a problem long time, and..... after disable and enable all Queues - they starded working again. VERY, very strange problems...with ROS 6.42.1

Re: v6.42.1 [current]

Posted: Fri May 11, 2018 8:06 pm
by TestCRS
Please answer: switch crs317 dont forwards the qinq packets at wire-speed, why ?
How do you check it? Was it working at wire-speed in previous versions?
You ask because you have such switch and everything works ? our switch crs317 never worked with qinq.
I will be glad to hear a confirmation that someone have working qinq on switch crs317.
But I think it is not.

Re: v6.42.1 [current]

Posted: Fri May 11, 2018 8:50 pm
by pe1chl
our switch crs317 never worked with qinq.
Then please don't discuss it in this topic!!! This topic is only for issues specific for 6.42.1
Open a new topic in another section and fully explain you problem and configuration.

Re: v6.42.1 [current]

Posted: Sat May 12, 2018 6:42 pm
by TestCRS
our switch crs317 never worked with qinq.
Then please don't discuss it in this topic!!! This topic is only for issues specific for 6.42.1
Open a new topic in another section and fully explain you problem and configuration.
viewtopic.php?f=1&t=134316#p661270

Re: v6.42.1 [current]

Posted: Sun May 13, 2018 3:06 pm
by Basdno
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
I have same problem on a RB2011UAS-2HnD!
Whatever kind of upgrade of ROS if Current 6.42.1 or RC version, the RB just seems to ignore that there is an update package downloaded in files and reboots to 6.42.

Has any1 else had this problem, and/or solved this?

Its kinda frustrating not getting it updated now since there actually is a voulnarability!

Re: v6.42.1 [current]

Posted: Sun May 13, 2018 3:43 pm
by maxfava
add more info
after playing with fast track and non fast track i confine i’m seeing the issue of packet marked sip and non sip wrongly.
After a reboot all work fine.

the issue we are seeing is the vpls interface associated to pppoe server are not listed. but i noted is going to be fixed since rc showing fixed dynamic interfaces

Re: v6.42.1 [current]

Posted: Mon May 14, 2018 12:11 am
by macsrwe
13:31:55 system,info router rebooted
13:31:56 system,error,critical router rebooted because some critical program crashed
----------------------------------------------------------------------------------------------------------------------
3 causes after upgrade to 6.42.1 ( CCR1036-8G-2S+ with 60-70 OVPN tunnels)
26-th of April, 4-th of May, 10-th of May
I am also experiencing a flood of supouts from previously content CPEs (SXT, 911) since installing 6.42.1 on April 24. Two examples:
Screen Shot 2018-05-13 at 2.06.06 PM.jpg
Screen Shot 2018-05-13 at 2.06.43 PM.jpg

Re: v6.42.1 [current]

Posted: Mon May 14, 2018 12:19 am
by macsrwe
I think ROS 6.42.1 i VERY buggy version :( Many,many things not working or working randomly. For instance - next NOT working: Intel i350 miniPCIe cards at x86, working "randomly" Queues. Today I have had NOT working Simple Queues at one x86 machine. I was looking for a problem long time, and..... after disable and enable all Queues - they starded working again. VERY, very strange problems...with ROS 6.42.1
Your report is believable, but the issue is not new to 6.42.1. For ten years I have been "solving" inexplicable queueing problems by exporting queues (both simple and tree), wiping out all queues, then reimporting. Someday I'm sure they will find this problem.

Re: v6.42.1 [current]

Posted: Mon May 14, 2018 11:41 am
by RN3QTB
Hello!
Help me please! After updating SXT 5nDr2 from version 6.40.8 to version 6.42.1, the router dies! I have to restore the firmware via netinstall! After restoring the firmware to the initial version 5.26, the update on the Internet is up to 6.40.8, the router reboots and offers to update to 6.42.1 current if you click "update" the router downloads the update, reboots and does not turn on again! Tried it 2 times. What to do?

Re: v6.42.1 [current]

Posted: Mon May 14, 2018 1:23 pm
by MartijnVdS
Hello!
Help me please! After updating SXT 5nDr2 from version 6.40.8 to version 6.42.1, the router dies! I have to restore the firmware via netinstall! After restoring the firmware to the initial version 5.26, the update on the Internet is up to 6.40.8, the router reboots and offers to update to 6.42.1 current if you click "update" the router downloads the update, reboots and does not turn on again! Tried it 2 times. What to do?
Have you tried netinstalling 6.42.1?

Re: v6.42.1 [current]

Posted: Mon May 14, 2018 5:14 pm
by akavousa
All good after upgrade on RB435G.
Keep checking for hickups.

Re: v6.42.1 [current]

Posted: Mon May 14, 2018 9:12 pm
by Xymox
Ive been testing 43RC11.. It addressed a huge number of issues posted in this thread. Good job Mikrotik.

It does not address the short sighted feature neutering of Netwatch tho. I still cannot send a alert or change a LED state based on a ping of a target. Because I use Netwatch for many things, I still cant use firmware past 41.5 because of this.

While im really impressed all the other bugs introduced in 42 have been so quickly addressed, I am upset Netwatch has not been addressed.

Re: v6.42.1 [current]

Posted: Mon May 14, 2018 11:16 pm
by marcin21
Image

wireleswire link ~150m, after upgrade rate/signal loss.
are there any options I should tweak after upg ?

Re: v6.42.1 [current]

Posted: Tue May 15, 2018 2:07 am
by mt99
Ive been testing 43RC11.. It addressed a huge number of issues posted in this thread. Good job Mikrotik.

It does not address the short sighted feature neutering of Netwatch tho. I still cannot send a alert or change a LED state based on a ping of a target. Because I use Netwatch for many things, I still cant use firmware past 41.5 because of this.

While im really impressed all the other bugs introduced in 42 have been so quickly addressed, I am upset Netwatch has not been addressed.
Mikrotik at the very least needs to explain what is and what isn't supported after 6.42 in their Netwatch documentation. It's not that much to ask. I got the sense that calling a script which requires certain permissions doesn't work anymore. But if you put the entire script in the Netwatch code block instead of simply calling the script, does that work? I haven't upgraded from 6.41.4 so haven't tested this. Apologies if you've already given this a try.

Re: v6.42.1 [current]

Posted: Thu May 17, 2018 3:35 pm
by strods
Version 6.42.2 has been released in current channel:

viewtopic.php?f=21&t=134522

Re: v6.42.1 [current]

Posted: Thu May 31, 2018 9:49 am
by strods
Everyone who complained about the Netwatch issue - Please see this topic viewtopic.php?f=2&t=134538