When auto updating, Error connection timed out

smilem · Sun Aug 17, 2014 12:11 am

Hello,

The advert seems nice
"

If you are already running RouterOS, upgrading to the latest version is simple. Just one click, and RouterOS will find the latest version, show you the changelog, and offer to upgrade. You can do this from Winbox, console, Webfig or QuickSet.

Simply click “Check for updates” in QuickSet, Webfig or Winbox packages menu.
"

But in reality when auto updating my mikrotik OS, I get this error: Error connection timed out
The router can't get the newest version and update

How to solve this? Do I need to make Firewall rule for updates to work, if so any details how?

rextended · Sun Aug 17, 2014 12:53 am

You do not provide any relevant details to help you.

smilem · Sun Aug 17, 2014 8:48 pm

You do not provide any relevant details to help you.

Sorry, this should be "one click auto update", what details you need?
As I said if I need to create any rules I'm all ears.

docmarius · Sun Aug 17, 2014 8:57 pm

First you need a full working internet connection on your router, including correctly set up DNS.
I update my routers in that way since the earliest 6 (even some latest 5 releases if I remember correctly) and never had any problems.

smilem · Sun Aug 17, 2014 9:35 pm

Well I have working internet connection, I had OS v6.4 now upgraded to v6.18 the manual way by uploading file using winbox

Now the router looses connection to winbox after I click the "check for updates" button.
The updates still never retrieved as the connection error still is shown.

How can I open ports for autoupdate to work? or create log rule to see what ports to open?

nacholibrev · Tue Feb 17, 2015 5:31 pm

I had the same problem, it was because of my firewall, I was dropping all connections from unknown sources.

Disable your custom firewall that drops (TCP) and try again.

lambert · Wed Feb 18, 2015 5:56 am

While all management traffic works to my RouterOS devices and I can ping and SSH to the general Internet from the RouterOS devices, the auto update checker timed out until I added the state checking rules to the firewall's input chain. Maybe it is using FTP underneath. I didn't dig into why it would not work without allows for established and related connections on input.

/ip firewall filter 
  add chain=input comment="allow established connections" connection-state=established
  add chain=input comment="allow related connections" connection-state=related

Just move them before the deny rules. Near the top of your allow rules is more performant.

xiliane · Sat Feb 28, 2015 6:09 pm

I just flush DNS cache

beef · Sat Apr 23, 2016 6:14 am

None of these suggestions work for me, and I don't see anything in my firewall (v4 or v6) trapping packets.

[admin@T-Bone] /system package update> check-for-updates
channel: current
current-version: 6.35
latest-version: 6.35
status: ERROR: connection timed out

[admin@T-Bone] /system package update>

 [admin@T-Bone] /ip firewall filter> print
Flags: X - disabled, I - invalid, D - dynamic 
0    ;;; VPN
      chain=input action=accept protocol=ipsec-ah log=no log-prefix="" 

 1    ;;; VPN
      chain=input action=accept protocol=ipsec-esp log=no log-prefix="" 

 2    ;;; VPN
      chain=input action=accept protocol=udp port=500,4500,1701 log=no log-prefix="" 

 3    ;;; Allow established connections
      chain=input action=accept connection-state=established log=no log-prefix="" 

 4    ;;; Accept related connections
      chain=input action=accept connection-state=related log=no log-prefix="" 

 5    ;;; Allow ICMP (ping)
      chain=input action=accept protocol=icmp limit=50/5s,2:packet log=no log-prefix="" 

 6    chain=input action=accept src-address=192.168.1.0/24 in-interface=!pppoe-out1 log=no log-prefix="" 

 7    ;;; Drop Invalid Connections
      chain=input action=drop connection-state=invalid log=no log-prefix="" 

 8    ;;; Drop everything else
      chain=input action=drop log=no log-prefix="IPV4 Firewall" 

 9 I  ;;; ToD Limits for DC:85:DE:2C:B3:5A "CJ_The_Second" (AzureWave Technology)
      ;;; inactive time
      chain=forward action=reject reject-with=icmp-admin-prohibited src-mac-address=DC:85:DE:2C:B3:5A time=1h-8h,sun,mon,tue,wed,thu,fri,sat log=no log-prefix="" 

10 I  ;;; ToD Limits for 94:DE:80:CE:5A:EA "CJ_the_Second" (Giga-Byte Technology Co,)
      ;;; inactive time
      chain=forward action=reject reject-with=icmp-admin-prohibited src-mac-address=94:DE:80:CE:5A:EA time=1h-8h,sun,mon,tue,wed,thu,fri,sat log=no log-prefix="" 

11 I  ;;; ToD Limits for 00:1F:5B:CA:53:2A "CJ" (Apple Inc)
      ;;; inactive time
      chain=forward action=reject reject-with=icmp-admin-prohibited src-mac-address=00:1F:5B:CA:53:2A time=1h-8h,sun,mon,tue,wed,thu,fri,sat log=no log-prefix="" 

12 I  ;;; ToD Limits for C0:CE:CD:36:97:41 "iPhone" (Apple Inc)
      ;;; inactive time
      chain=forward action=reject reject-with=icmp-admin-prohibited src-mac-address=C0:CE:CD:36:97:41 time=1h-7h,sun,mon,tue,wed,thu,fri,sat log=no log-prefix="" 

13    ;;; Allow already established connections
      chain=forward action=accept connection-state=established log=no log-prefix="" 

14    ;;; allow related connections
      chain=forward action=accept connection-state=related log=no log-prefix="" 

15    ;;; Drop invalid connections
      chain=forward action=drop connection-state=invalid protocol=tcp log=no log-prefix="" 

16    ;;; block bogon
      chain=forward action=drop src-address=0.0.0.0/8 log=no log-prefix="" 

17    ;;; block bogon
      chain=forward action=drop dst-address=0.0.0.0/8 log=no log-prefix="" 

18    ;;; block bogon
      chain=forward action=drop src-address=127.0.0.0/8 log=no log-prefix="" 

19    ;;; block bogon
      chain=forward action=drop dst-address=127.0.0.0/8 log=no log-prefix="" 

20    ;;; block bogon
      chain=forward action=drop src-address=224.0.0.0/3 log=no log-prefix="" 

21    ;;; block bogon
      chain=forward action=drop dst-address=224.0.0.0/3 log=no log-prefix="" 

22    chain=forward action=jump jump-target=tcp protocol=tcp log=no log-prefix="" 

23    chain=forward action=jump jump-target=udp protocol=udp log=no log-prefix="" 

24    chain=forward action=jump jump-target=icmp protocol=icmp log=no log-prefix="" 

25    ;;; deny TFTP
      chain=tcp action=drop protocol=tcp dst-port=69 log=no log-prefix="" 

26    ;;; deny RPC portmapper
      chain=tcp action=drop protocol=tcp dst-port=111 log=no log-prefix="" 

27    ;;; deny RPC portmapper
      chain=tcp action=drop protocol=tcp dst-port=135 log=no log-prefix="" 

28    ;;; deny NBT
      chain=tcp action=drop protocol=tcp dst-port=137-139 log=no log-prefix="" 

29    ;;; deny cifs
      chain=tcp action=drop protocol=tcp dst-port=445 log=no log-prefix="" 

30    ;;; deny NFS
      chain=tcp action=drop protocol=tcp dst-port=2049 log=no log-prefix="" 

31    ;;; deny NetBus
      chain=tcp action=drop protocol=tcp dst-port=12345-12346 log=no log-prefix="" 

32    ;;; deny NetBus
      chain=tcp action=drop protocol=tcp dst-port=20034 log=no log-prefix="" 

33    ;;; deny BackOriffice
      chain=tcp action=drop protocol=tcp dst-port=3133 log=no log-prefix="" 

34    ;;; deny DHCP
      chain=tcp action=drop protocol=tcp dst-port=67-68 log=no log-prefix="" 

35    ;;; deny TFTP
      chain=udp action=drop protocol=udp dst-port=69 log=no log-prefix="" 

36    ;;; deny PRC portmapper
      chain=udp action=drop protocol=udp dst-port=111 log=no log-prefix="" 

37    ;;; deny PRC portmapper
      chain=udp action=drop protocol=udp dst-port=135 log=no log-prefix="" 

38    ;;; deny NBT
      chain=udp action=drop protocol=udp dst-port=137-139 log=no log-prefix="" 

39    ;;; deny NFS
      chain=udp action=drop protocol=udp dst-port=2049 log=no log-prefix="" 

40    ;;; deny BackOriffice
      chain=udp action=drop protocol=udp dst-port=3133 log=no log-prefix="" 

41    ;;; echo reply
      chain=icmp action=accept protocol=icmp icmp-options=0:0 log=no log-prefix="" 

42    ;;; net unreachable
      chain=icmp action=accept protocol=icmp icmp-options=3:0 log=no log-prefix="" 

43    ;;; host unreachable
      chain=icmp action=accept protocol=icmp icmp-options=3:1 log=no log-prefix="" 

44    ;;; host unreachable fragmentation required
      chain=icmp action=accept protocol=icmp icmp-options=3:4 log=no log-prefix="" 

45    ;;; allow source quench
      chain=icmp action=accept protocol=icmp icmp-options=4:0 log=no log-prefix="" 

46    ;;; allow echo request
      chain=icmp action=accept protocol=icmp icmp-options=8:0 log=no log-prefix="" 

47    ;;; allow time exceed
      chain=icmp action=accept protocol=icmp icmp-options=11:0 log=no log-prefix="" 

48    ;;; allow parameter bad
      chain=icmp action=accept protocol=icmp icmp-options=12:0 log=no log-prefix="" 

49    ;;; deny all other types
      chain=icmp action=drop log=no log-prefix=""

beef · Sun Jun 05, 2016 7:52 pm

OK, I'm completely at a loss at this point. My certified Mikrotik dealer says my DNS is correctly configured, and I did a fresh net install on this recommendation but no luck. I even created a firewall rule on the input chain to accept all and put it at the top of the list.

pe1chl · Sun Jun 05, 2016 9:13 pm

My experience is that it does not work when the MTU of your internet connection is less than 1500 and you have
not configured the "clamp TCP MSS to MTU".
I think it is a bug in their update servers.

beef · Sun Jun 05, 2016 9:55 pm

MTU of your internet connection is less than 1500 and you have not configured the "clamp TCP MSS to MTU".

Hmm, that may be the most viable clue yet, thanks. My MTU is <1500 on my PPPoE interface (which itself is an MLPPP DSL connection)

I don't see the clamp option on any of my existing interfaces, however.

pe1chl · Sun Jun 05, 2016 10:33 pm

You can configure a rule in the postrouting chain on the Mangle page of the firewall that matches TCP traffic
to your PPPoE interface and that does the change MSS and then clamp MSS to PMTU action.

beef · Sun Jun 05, 2016 11:57 pm

You can configure a rule in the postrouting chain on the Mangle page of the firewall that matches TCP traffic
to your PPPoE interface and that does the change MSS and then clamp MSS to PMTU action.

ok, this is the closest I've come to solving this issue...I still get a couple time out messages but it seems to fumble it's way through successfully given enough time. Here's my rule:

chain=postrouting action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp log=no log-prefix=""

pe1chl · Mon Jun 06, 2016 9:40 am

Ok that is great!
No idea why it does not solve the entire problem.
I did not test if it works in postrouting, you could try to replace it by two separate rules, one in the output
chain (for the router itself) and one in the forward chain (for traffic from the users).

I noticed this problem when connecting a router to internet through a VPN. The MTU towards internet
is smaller than the local MTU at the router. In that case the router that provides the VPN (further upstream)
sends "packet too large" messages towards the update server, the update server decreases the packet
size and re-sends, which arrives at the router to be updated, but then it does not remember this new
packet size and the next packet is sent at full size again. As the "packet too large" messages are not
sent for every packet, this eventually lets the connection die and the router to be updated issues a timeout
message.
The "clamp MSS" method forces the update server to use the lower MSS all the time. However, IMO it
is a bug in the update server. That has been outsourced to cloudfront.net, so MikroTik may not have
that much influence on it.

markmuehlbauer · Fri Mar 10, 2017 7:24 pm

This is ABSOLUTELY a bug and has persisted for "ever".
Frankly, I gave up after numerous posts that it is a bug, which was several years back.
In my opinion, forget the feature exists (as it is completely unreliable).
Mikrotik is a great "do anything" black box, but in this one area of updating through the System/Packages has and is a complete joke.
Yes, I am just ranting, but toward the end of telling you to focus on something important and just forget this is a feature as it is broken without any interest to correct.

pe1chl · Sat Mar 11, 2017 10:58 am

This is ABSOLUTELY a bug and has persisted for "ever".
Mikrotik is a great "do anything" black box, but in this one area of updating through the System/Packages has and is a complete joke.

Wait a moment, it is a bug in the update server, a cloud webserver on the internet, not in the MikroTik router!

TedjeVanEs · Tue Mar 14, 2017 11:28 pm

I think it used to work, a while ago I used the auto-update to go from 5.x to 6.x
But now it is not working. When will this be fixed? A smooth auto-update makes the world a safer place

beef · Tue May 02, 2017 1:50 am

Well, well, turns out 6.39 fixed this long standing problems!! My guess it was "ppp - implemented internal algorithm for "change-mss", no mangle rules necessary;"

pe1chl · Tue May 02, 2017 10:46 am

That could well be! It sort of brushes the issue under the rug for most users.
Of course it does not help when you are using a VPN that does not use PPP as an intermediate layer.

It is quite astonishing that a cloud webservice (they are using cloudfront) can exist for so long with a
broken handling of ICMP "size exceeded" messages...

markmuehlbauer · Wed Jul 26, 2017 10:40 pm

This is ABSOLUTELY a bug and has persisted for "ever".
Mikrotik is a great "do anything" black box, but in this one area of updating through the System/Packages has and is a complete joke.
Wait a moment, it is a bug in the update server, a cloud webserver on the internet, not in the MikroTik router!

Incorrect. This is a problem with the Mikrotik device, not the Internet, not the update server. I have asked FOR YEARS for this to be resolved. Any correctly setup firewall/router (denying all the 'other') packets inbound except what is defined, does deny the update service from working. This alone is expected. So, then here is the exact question, timeless by now, laughable in lack of resolution.
1. WHAT PORT(S) SHOULD BE ALLOWED FOR THE UPDATE SERVICE TO FUNCTION?

The question is that simple to get this working. And I have come to the understanding there is a serious lack of competency in either the pros, or the platform, for this to remain unsolved. . .
Why is this so hard to simply answer? This is a port issue, as when I disable the drop all other packets, it updates fine. I have tried ports for absolutely just about everything.

IF IT IS NOT A PORT ALLOWANCE ISSUE??????????????????????????????

Then here is the simple question: 2. WHAT IS THE PACKET PATH DISABLING UPDATE COMMUNICATIONS?

This solution is either answering question 1 or 2. It is that simple, and that impossible to get a straight answer on. . . .

markmuehlbauer · Wed Jul 26, 2017 10:47 pm

OK, I'm completely at a loss at this point. My certified Mikrotik dealer says my DNS is correctly configured, and I did a fresh net install on this recommendation but no luck. I even created a firewall rule on the input chain to accept all and put it at the top of the list.

I have done back flips to get this to work, and it fails. My only work around, if you have setup your device correctly, to suspend the last 'drop everything else' rule. So, as a wide open useless firewall it updates the OS just fine. No one really knows why this won't work given allowed ports entered.
It is broken.

markmuehlbauer · Wed Jul 26, 2017 10:48 pm

I think it used to work, a while ago I used the auto-update to go from 5.x to 6.x
But now it is not working. When will this be fixed? A smooth auto-update makes the world a safer place

It did used to work without issue. Now it is the ugly step child.

csif18 · Fri Oct 13, 2017 10:16 am

In my case, this is a matter of static DNS. Mikrotik router has a static IP for upgrade.mikrotik.com, and its IP has changed recently from 54.192.217.80 to 54.230.62.145.

Just change this static address (IP > DNS > Static) and everything will be working again.

MariusL · Fri Apr 06, 2018 10:58 pm

The auto-updater accesses download.mikrotik.com using port 80. You'll need a firewall rule allowing your output chain internet access to destination port 80.

GeneralMarmite · Sun Jul 22, 2018 1:23 pm

There are several threads on this problem. I am inadvertently blocking the updates because of how my rules work. I wrote about it on one of the other threads here in the forums. It's possible someone else is doing what I did. viewtopic.php?f=2&t=111054&p=675438#p675438

saenito · Tue Oct 09, 2018 10:34 pm

Sames happen to my in hap lite SW version 6.42.6 under packages "download & install" or just "download" option

no firewall rules for output, i guess is because i have a latency of about 600ms because of the type of internet conection i have, so it creates a round trip time of about 1.2 seconds, maybe that's why i get the : ERROR: Connection timed out

saenito · Wed Oct 31, 2018 9:21 pm

I will try it on lab

try to reset your router

cipito · Sun Nov 25, 2018 11:44 pm

For me, the problem was that some IP download.mikrotik.com resolved to, was not accesible, maybe I was filtered.
I have fixed the problem by enetering a static DNS entry to another IP i have found on this topic.
Thank you!

When auto updating, Error connection timed out

When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out

Re: When auto updating, Error connection timed out