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?
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.
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?
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.
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.
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.
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:
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.
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.
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
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;”
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…
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: