Community discussions

 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1232
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: v6.42.1 [current]

Sat Apr 28, 2018 10:29 pm

WAN IP Lease expires on daily basis

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

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

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

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

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

UGHHHHH

Does not seem to be same problem as mine then, mine requests, but does not get back until lease has expired, see screenshot from packet analyzer
DHCPFail.jpg
You do not have the required permissions to view the files attached to this post.
MTCNA, MTCTCE, MTCRE & MTCINE
 
itmethod
newbie
Posts: 26
Joined: Tue Feb 18, 2014 8:44 pm

Re: v6.42.1 [current]

Sat Apr 28, 2018 10:30 pm

this broke UPNP for me. it worked before I upgraded
 
User avatar
Xymox
Member
Member
Posts: 381
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.42.1 [current]

Sat Apr 28, 2018 10:58 pm

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

Should you be using Release (Current) branch instead of Bugfix (Stable) branch for business of any kind?
When the Release (Current) branch has the exploit patch available, and the Bugfix (Stable) branch still does not... sometimes you do. But never again, my friend.
I have only been using stable. 42.x is not stable. 41.x is stable but not secure now. 43.x does not have Netwatch or a fixed LED ON script command.

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

I now wait for a solution to the debacle.
 
User avatar
Xymox
Member
Member
Posts: 381
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.42.1 [current]

Sat Apr 28, 2018 11:09 pm

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

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

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

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

I am happy tho on 41.4.. Ive disabled everything but WInbox and put that on a random port and restricted it LAN side use only. So I guess im mostly safe from the security issue..
 
SnakeSK
just joined
Posts: 16
Joined: Fri Mar 09, 2018 1:30 am

Re: v6.42.1 [current]

Sat Apr 28, 2018 11:20 pm

Yea I had to do that also, 6.42.1 broke a lot of things, namely it completely broke the router on the Hyper-V platform, so this is a no go for me.
 
User avatar
jspool
Member
Member
Posts: 386
Joined: Sun Oct 04, 2009 4:06 am
Location: Oregon

Re: v6.42.1 [current]

Sat Apr 28, 2018 11:21 pm

Downgrading a RB1100AHx2 from 6.42.1 to 6.40.8 bricked it. Will have to make a trip to the mountain to fix that one. At least I had a backup router in place!
 
User avatar
Xymox
Member
Member
Posts: 381
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.42.1 [current]

Sat Apr 28, 2018 11:45 pm

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

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

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

My 2 cents on what should happen.. Take 41.4 and apply a security patch for this new issue. Turn that into stable release 44.0.. Push that out right away.. Make RC 43.x into 45.1 and FIX IT. Then release 45 once its at like RC45.30 and all these issues are worked out...
 
User avatar
vasilevkirill
Trainer
Trainer
Posts: 46
Joined: Tue May 22, 2012 7:38 am
Location: Russian, Saint-Petersburg
Contact:

Re: v6.42.1 [current]

Sat Apr 28, 2018 11:51 pm

hi
i use this construction
/interface list
add name=ISP_1
add name=ISP_2
add include=ISP_1,ISP_2 name=ISP
/interface list member
add interface=ether1 list=ISP_1
add interface=vrrp-mts-ISP1 list=ISP_1
add interface=vrrp-rt-ISP2 list=ISP_2
add interface=ether2 list=ISP_2
I used list ISP for firewall rules in filter

if router rebooted, rules not action = not working
if you edit a list, for example, add a comment
/interface list
set  comment=aaa ISP
The rules begin to work
problem only list = ISP
Vasilev Kirill
( MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME, MTCINE, MTCIPv6E, MTCSE )
MikroTik Certified Trainer & Consultant
Trainer Сertificate Number TR0417
https://www.mikrotik.me
Cell:+7 (905) 207-35-78
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Wed Jun 05, 2013 5:54 am

Re: v6.42.1 [current]

Sun Apr 29, 2018 3:16 am

WAN IP Lease expires on daily basis

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

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

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

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

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

UGHHHHH

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

DHCPFail.jpg
That's the same problem as you are seeing it mirrors your cap. I notice that it only accepts the request when the source address is 0.0.0.0, not the public IP.
You do not have the required permissions to view the files attached to this post.
 
Modestas
just joined
Posts: 18
Joined: Mon Jul 16, 2012 10:59 am
Location: Vilnius, Lithuania

Re: v6.42.1 [current]

Sun Apr 29, 2018 2:01 pm

WAN IP Lease expires on daily basis

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

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

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

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

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

UGHHHHH

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

DHCPFail.jpg
That's the same problem as you are seeing it mirrors your cap. I notice that it only accepts the request when the source address is 0.0.0.0, not the public IP.
Hi
Would be interesting to see more details in this capture: how does transaction look like, flags set, mac addresses etc etc.
Seems, DHCP server is not happy with unicast requests (renewal messages) sent from mikrotik router if these are sent out.

So far this DHCP issue seems to be quite serious defect in 6.42.1
 
Modestas
just joined
Posts: 18
Joined: Mon Jul 16, 2012 10:59 am
Location: Vilnius, Lithuania

Re: v6.42.1 [current]

Sun Apr 29, 2018 6:25 pm

Would be interesting to see more details in this capture: how does transaction look like, flags set, mac addresses etc etc.
Seems, DHCP server is not happy with unicast requests (renewal messages) sent from mikrotik router if these are sent out.
I did few DHCP tests with CHR versions 6.42, 6.42.1, 6.40.5 and cisco soapbox.
MT routers running 6.42, 6.42. send out all DHCP renewal requests towards specific DHCP server with wrong destination MAC address (namely, own MT router MAC address). Only following broadcast requests are sent to "all 1". No surprise, DHCP server would not receive such renewal requests until broadcasts arrive.
When broadcast domain is large and contains devices with ARP proxy feature, some more side effects may be observed.
DHCP renewal on Cisco and MT router running 6.40.5 works as expected.

Mikrotik engineers may want tolook into DHCP client behaviour at least on 6.42 and 6.42.1.
 
sindy
Forum Guru
Forum Guru
Posts: 3287
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.42.1 [current]

Sun Apr 29, 2018 6:33 pm

Would be interesting to see more details in this capture: how does transaction look like, flags set, mac addresses etc etc.
Seems, DHCP server is not happy with unicast requests (renewal messages) sent from mikrotik router if these are sent out.
I did few DHCP tests with CHR versions 6.42, 6.42.1, 6.40.5 and cisco soapbox.
MT routers running 6.42, 6.42. send out all DHCP renewal requests towards specific DHCP server with wrong destination MAC address (namely, own MT router MAC address). Only following broadcast requests are sent to "all 1". No surprise, DHCP server would not receive such renewal requests until broadcasts arrive.
When broadcast domain is large and contains devices with ARP proxy feature, some more side effects may be observed.
DHCP renewal on Cisco and MT router running 6.40.5 works as expected.

Mikrotik engineers may want tolook into DHCP client behaviour at least on 6.42 and 6.42.1.
Please send the above to support@mikrotik.com (or shout loud, you're closer to Mikrotik premises than most of us :-) ), but don't rely on Mikrotik staff picking this information from this forum.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Modestas
just joined
Posts: 18
Joined: Mon Jul 16, 2012 10:59 am
Location: Vilnius, Lithuania

Re: v6.42.1 [current]

Sun Apr 29, 2018 7:26 pm

Please send the above to support@mikrotik.com (or shout loud, you're closer to Mikrotik premises than most of us :-) ), but don't rely on Mikrotik staff picking this information from this forum.
I have no formal support contract with Mikrotik, but will try to do so.
Anyway, there was once SW defect in new version when router was not able to boot due to certain line in configuration. I wrote in this forum and Mikrotik engineers responded promptly.
Here are my lab captures if someone is interested.
You do not have the required permissions to view the files attached to this post.
 
sindy
Forum Guru
Forum Guru
Posts: 3287
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.42.1 [current]

Sun Apr 29, 2018 7:47 pm

I have no formal support contract with Mikrotik, but will try to do so.
After some discussion with @strods in one of these "current" or "rc" topics here, my understanding of the repelling sentence regarding support contract is that Mikrotik is not obliged to assist you in resolving simple configuration issues or alike but always welcomes meaningful bug reports such as this one. After all, the worst what can happen to you is that they won't answer.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5291
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.42.1 [current]

Sun Apr 29, 2018 7:51 pm

I have no formal support contract with Mikrotik, but will try to do so.
MikroTIk is not like Cisco. Anyone can write a mail to support, no need for a formal support contract.
 
User avatar
typicalwisp
just joined
Posts: 10
Joined: Fri Jan 05, 2018 8:45 pm

Re: v6.42.1 [current]

Sun Apr 29, 2018 8:18 pm

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

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

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

Re: v6.42.1 [current]

Sun Apr 29, 2018 10:47 pm

Does 6.42.1 force SSH host key renewal on first login after the upgrade? The SSH host keys are changing on every router I upgrade and I want to rule out the unlikely MITM.
A few of my devices have changed keys, many of them retained the old key. I did not find motive to rebuild key in some and not in others.
 
User avatar
typicalwisp
just joined
Posts: 10
Joined: Fri Jan 05, 2018 8:45 pm

Re: v6.42.1 [current]

Sun Apr 29, 2018 10:54 pm

A few of my devices have changed keys, many of them retained the old key. I did not find motive to rebuild key in some and not in others.
As I update more devices I am seeing the same thing. Some change keys, others don't. The ones that change keys take longer to respond to SSH. I assume that is because they were generating the new keys when the connection was initiated. Other than that, I haven't noticed a pattern.
 
Paternot
Long time Member
Long time Member
Posts: 570
Joined: Thu Jun 02, 2016 4:01 am
Location: Niterói / Brazil

Re: v6.42.1 [current]

Sun Apr 29, 2018 11:40 pm

Some versions ago, the upgrade forced the new SSH key. Don't remember why, but it did. And the key was generated on the first reconnection, not just after the reboot. Perhaps You have some units with older versions, and some with newer?
 
User avatar
typicalwisp
just joined
Posts: 10
Joined: Fri Jan 05, 2018 8:45 pm

Re: v6.42.1 [current]

Mon Apr 30, 2018 5:12 am

Perhaps You have some units with older versions, and some with newer?
Here is a random sampling of a few recent updates to 6.42.1:
1. 6.41: New key generated
2. 6.42: Key not changed
3-10. 6.41: Key not changed
11-14. 6.40.4 Key not changed
15-16. 6.40.4 New key generated

I suppose this might be caused by the router generating a different key type (like only having DSA and then generating RSA). Nope. #15 and 16 started off as an RSA key and finished as a new RSA key. This just happened to me locally so it's not likely MITM. Anyone have any idea why this is happening?
 
bbs2web
Member Candidate
Member Candidate
Posts: 193
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: v6.42.1 [current]

Mon Apr 30, 2018 11:53 am

Two problems with 6.42.1:

IP Neighbour discovery settings in Winbox are shown correctly as !external (ie negate 'external' list; aka all interfaces which are not a member of the 'external' interface list) but 'export' does not include the negate (exclamation mark):
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
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1232
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: v6.42.1 [current]

Mon Apr 30, 2018 3:19 pm

Would be interesting to see more details in this capture: how does transaction look like, flags set, mac addresses etc etc.
Seems, DHCP server is not happy with unicast requests (renewal messages) sent from mikrotik router if these are sent out.
I did few DHCP tests with CHR versions 6.42, 6.42.1, 6.40.5 and cisco soapbox.
MT routers running 6.42, 6.42. send out all DHCP renewal requests towards specific DHCP server with wrong destination MAC address (namely, own MT router MAC address). Only following broadcast requests are sent to "all 1". No surprise, DHCP server would not receive such renewal requests until broadcasts arrive.
When broadcast domain is large and contains devices with ARP proxy feature, some more side effects may be observed.
DHCP renewal on Cisco and MT router running 6.40.5 works as expected.

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

Ticket#2018043022003403 sent sniffed data and suppout file
MTCNA, MTCTCE, MTCRE & MTCINE
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Wed Jun 05, 2013 5:54 am

Re: v6.42.1 [current]

Mon Apr 30, 2018 3:40 pm

Same here lets hope they fix soon.
 
Alloca
just joined
Posts: 3
Joined: Mon Oct 02, 2017 8:58 pm

Re: v6.42.1 [current]

Mon Apr 30, 2018 6:38 pm

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

do you have any news about the eoip issue?

best regards, Gabor
EoIP Ethernet Frame issue is still there (introduced in 6.42 breaking fragmenting big frames somehow broken) verified on RB2011 and sent supout to MT-support.
 
User avatar
Xymox
Member
Member
Posts: 381
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.42.1 [current]

Mon Apr 30, 2018 7:33 pm

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

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

So that was a upgrade from 41.4 to RC43.5 and everything seemed to move over well. BUT, its a very limited SOHO use.
 
gkostov
just joined
Posts: 2
Joined: Tue Feb 16, 2016 7:07 pm

Re: v6.42.1 [current]

Tue May 01, 2018 5:53 am

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

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

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

Re: v6.42.1 [current]

Tue May 01, 2018 11:50 am

6.42.1 killed my metal2..package was updated and every time I upgrade the routerboard to current version, the rb simply stops and doesn't reboot anymore...will just go back to 6.41.3 and forget 6.42..it broke everything
 
steen
Member
Member
Posts: 469
Joined: Sat Oct 23, 2010 2:15 am
Location: Sweden
Contact:

Re: v6.42.1 [current]

Tue May 01, 2018 2:34 pm

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

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

viewtopic.php?f=8&t=133884

It was solved by using snmp v.2 for the troublesome devices, dude default is snmp v.1 which it always has been.
Something has changed regarding snmp in the dude, snmp discovery is very slow in comparison to the legacy versions 3.x and 4.x (which had a nasty aggressive snmp that could overload devices).
Last edited by steen on Tue May 01, 2018 10:47 pm, edited 1 time in total.
 
jarda
Forum Guru
Forum Guru
Posts: 7575
Joined: Mon Oct 22, 2012 4:46 pm

Re: v6.42.1 [current]

Tue May 01, 2018 2:37 pm

Don't forget to send your finding to the support@mikrotik.com directly.
 
Redmor
Member Candidate
Member Candidate
Posts: 248
Joined: Wed May 31, 2017 7:40 pm
Location: Italy

Re: v6.42.1 [current]

Wed May 02, 2018 12:12 am

I saw that now I can download automatically the new RB firmware with "Auto upgrade", there's also a way to auto reboot?
ImageImage
 
105547111
Member Candidate
Member Candidate
Posts: 130
Joined: Fri Jun 22, 2012 9:46 pm

Re: v6.42.1 [current]

Wed May 02, 2018 2:12 am

I saw that now I can download automatically the new RB firmware with "Auto upgrade", there's also a way to auto reboot?
Not at this time must reboot a second time after updating RoS version, then a reboot second time after firmware for firmware update...
 
105547111
Member Candidate
Member Candidate
Posts: 130
Joined: Fri Jun 22, 2012 9:46 pm

Re: v6.42.1 [current]

Wed May 02, 2018 2:13 am

Post doubled itself :-(
Last edited by 105547111 on Wed May 02, 2018 2:17 am, edited 1 time in total.
 
105547111
Member Candidate
Member Candidate
Posts: 130
Joined: Fri Jun 22, 2012 9:46 pm

Re: v6.42.1 [current]

Wed May 02, 2018 2:16 am

I saw that now I can download automatically the new RB firmware with "Auto upgrade", there's also a way to auto reboot?
Also there was talk of perhaps suppressing the firmware reboot message if not needed.
 
User avatar
jspool
Member
Member
Posts: 386
Joined: Sun Oct 04, 2009 4:06 am
Location: Oregon

Re: v6.42.1 [current]

Wed May 02, 2018 2:30 am

I saw that now I can download automatically the new RB firmware with "Auto upgrade", there's also a way to auto reboot?
Also there was talk of perhaps suppressing the firmware reboot message if not needed.
There was also talk of v7
 
User avatar
macsrwe
Long time Member
Long time Member
Posts: 644
Joined: Mon Apr 02, 2007 5:43 am
Location: Arizona, USA
Contact:

Re: v6.42.1 [current]

Wed May 02, 2018 3:12 am

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

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

This upgrade has been a disaster for us. We are still not back to the subscriber speeds we had ten days ago. I am never moving off the stable release again, I don't care what security holes there are. I doubt that a hacker attack could have cost me more time and effort than this hacker patch already has.
 
User avatar
macsrwe
Long time Member
Long time Member
Posts: 644
Joined: Mon Apr 02, 2007 5:43 am
Location: Arizona, USA
Contact:

Re: v6.42.1 [current]

Wed May 02, 2018 3:16 am

6.42.1 killed my metal2..package was updated and every time I upgrade the routerboard to current version, the rb simply stops and doesn't reboot anymore...will just go back to 6.41.3 and forget 6.42..it broke everything
My experience indicates that this release does not get along well with single-pol devices -- it trashed a dozen units on our network and every one of them has been single pol. In a network with only about 16 single pol units, that's pretty definitive.
 
User avatar
Xymox
Member
Member
Posts: 381
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.42.1 [current]

Wed May 02, 2018 4:59 pm

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

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

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

I am dissapointed that Mikrotik has not commented on this thread and let us all know what they are doing. They have not provided a plan. In all my time doing Mikrotik ive never see this. We really need a official response from Mikrotik and a plan of action.
 
bbs2web
Member Candidate
Member Candidate
Posts: 193
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: v6.42.1 [current]

Wed May 02, 2018 5:13 pm

We have had 3 instances today alone of routers rebooting themselves with the following message:
14:20:40 system,info router rebooted
14:20:40 system,error,critical router rebooted because some critical program crashed
Please would MikroTik consider backporting the Winbox security fix and releasing 6.41.5?

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

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

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

Re: v6.42.1 [current]

Wed May 02, 2018 5:47 pm

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

disconnected, group key exchange timeout

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

the update interval is 1h
 
jrpaz
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Wed Jun 05, 2013 5:54 am

Re: v6.42.1 [current]

Wed May 02, 2018 6:56 pm

So the DHCP issue will be addressed in the next RC as per support's replies.
 
User avatar
Xymox
Member
Member
Posts: 381
Joined: Thu Jan 21, 2010 5:04 pm
Location: Phoenix, Arizona US
Contact:

Re: v6.42.1 [current]

Wed May 02, 2018 8:32 pm

So the next RC is what will address the long list of issues discussed in this thread ? So no security patched 41.4 ? What issues will be addressed ? WIll Netwatch be put back ? When is the scheduled next RC going to be released ? Does 42.1 stay as the current stable ? Or does it get withdrawn ?
 
dasvos
newbie
Posts: 29
Joined: Sat Mar 14, 2015 7:10 pm

Re: v6.42.1 [current]

Wed May 02, 2018 10:03 pm

So the next RC is what will address the long list of issues discussed in this thread ? So no security patched 41.4 ? What issues will be addressed ? WIll Netwatch be put back ? When is the scheduled next RC going to be released ? Does 42.1 stay as the current stable ? Or does it get withdrawn ?
Have you sent emails to support@mikrotik.com to report the issues you have picked up?
 
pe1chl
Forum Guru
Forum Guru
Posts: 5291
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.42.1 [current]

Wed May 02, 2018 10:59 pm

What issues will be addressed ? WIll Netwatch be put back ?
Netwatch is available as always. What has been removed is the capability of Netwatch to call scripts that perform actions that require write permission.
I use Netwatch with scripts that do only a /log action and it still works.
 
User avatar
macsrwe
Long time Member
Long time Member
Posts: 644
Joined: Mon Apr 02, 2007 5:43 am
Location: Arizona, USA
Contact:

Re: v6.42.1 [current]

Wed May 02, 2018 11:07 pm

What issues will be addressed ? WIll Netwatch be put back ?
Netwatch is available as always. What has been removed is the capability of Netwatch to call scripts that perform actions that require write permission.
I use Netwatch with scripts that do only a /log action and it still works.
I've run into an issue with the newest releases where the scheduler will not invoke a script if given only its name, but will invoke it if given a full command line of /system script run... I'm still working this issue with support.

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

Hope one of these suggestions works for you.
 
dougunder
newbie
Posts: 37
Joined: Tue May 01, 2018 10:53 pm

Re: v6.42.1 [current]

Wed May 02, 2018 11:08 pm

Some new issues Ive discovered today.

We have seen many international hAP AC with disappearing 5g

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

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

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

I'm now quite sure this is the underlying issue, not the regulatory setting.
 
vytuz
just joined
Posts: 16
Joined: Mon Jul 31, 2017 3:12 pm

Re: v6.42.1 [current]

Thu May 03, 2018 10:31 am

Some new issues Ive discovered today.

We have seen many international hAP AC with disappearing 5g

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

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

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

I'm now quite sure this is the underlying issue, not the regulatory setting.
Maybe it detects radar? Check for 5.8G state. It is common issue in noisy environment. I had this problem earlier, autoselect channel works strange even in 2.4G. If there are many other wifi ap's, it selects same channel, because there is no load, but usualy load may rise and mikrotik would not change its channel until reboot.
 
vytuz
just joined
Posts: 16
Joined: Mon Jul 31, 2017 3:12 pm

Re: v6.42.1 [current]

Thu May 03, 2018 2:46 pm

DHCP client updates acting as not supposed normaly. With 6.40 version, DHCP request is send after 50% lease time. With 6.42.1 version i.e. lease time is 48h, request is send after 42h.
 
User avatar
Joni
Frequent Visitor
Frequent Visitor
Posts: 70
Joined: Fri Mar 20, 2015 2:46 pm
Contact:

SNMP

Thu May 03, 2018 4:08 pm

SNMP: Looks like running Dude (on CCR1009-7G-1C-1S+, v6.42.1) and enabling IPv6 (in addition to IPv4) on it makes Dude unable to SNMP poll IPv4 agents (any make and model), however snmpwalk (from Dude) on same agent works (presumably uses / defaults to IPv4, which is obviously also wrong). Once you disable IPv6 on Dude (or enable IPv6 on agents) it works again normally, not firewall rules, single subnet LAN only.
 
User avatar
juliokato
Member Candidate
Member Candidate
Posts: 227
Joined: Mon Oct 26, 2015 4:27 pm
Location: Brazil

Re: v6.42.1 [current]

Thu May 03, 2018 4:36 pm

So the DHCP issue will be addressed in the next RC as per support's replies.
Just curious, how this issue was introduced?
I apologize my grammatical errors, my english not so good, I am not a native speaker.
Wiki is maintained in English. I use Google translator. 8)
 
netmouse
just joined
Posts: 2
Joined: Wed May 02, 2018 6:43 pm

Re: v6.42.1 [current]

Thu May 03, 2018 8:36 pm

RB2011UiAS-2HnD
I get the Internet by DHCP
After upgrade to 6.42.1 :
001.jpg
002.jpg
On 6.42.0 work fine...
You do not have the required permissions to view the files attached to this post.

Who is online

Users browsing this forum: No registered users and 10 guests