`/tool fetch` via HTTPS times out on CRS112

RouterOS Scripting
1

Hi everybody,

I have run across a weird problem. I am trying to download a file via HTTPS on all of my MikroTik devices. This works perfectly on most devices, but on three of them, I just run into a timeout. All those three devices happen to be CRS112-8P-4S.

So this is what happens:

[admin@Switch] > /tool fetch url="https://192.168.100.246/file"
  status: failed

failure: connection timeout

The irritating thing is, if I use FTP instead, it works perfectly. Other devices with identical network setups (except for the actual IP address of the device, of course) have no problem whatsoever, so I tend to think there is not network problem.

I did a tcpdump on the web server, and from the perspective of that server, everything is fine: Network packets from the switch arrive and are answered properly.

Anyone have a clue where to look?

THX & Cheers,
Toby.

2

Can this same device ping this server?
Does this file actually exist?
Does this specific switch have access to this server? Maybe the other routers are connected differently?

3

I have dozen of this model, no problem.

RouterOS version?

try full url (remove the spaces):

https : //download.mikrotik.com/routeros/6.47.9/routeros-mipsbe-6.47.9.npk

ptrobably there are some firewall rules somewhere

4

Hi,

sorry, I just realized I should have been more verbose.

So the CRS112-8P-4S is running RouterOS 6.47.9.

  • The device can ping the server perfectly. I can transfer the file via FTP and HTTP just fine.
  • The file does exist (as a side note, I would hope that the resulting error code would be different for a 404 than for a timeout).
  • The switch can access the server via all other means I have tried. In fact, some of the other MT devices that can download via HTTPS are connected through the switch.
  • No local firewall rules on the switch whatsoever.
  • Downloading, say, /graphs/cpu/daily.gif from the switch to the web server works perfectly (even when I disable the web server and use port 443 as source port), so I really don’t think there is a firewalling or network problem.
  • I can download via HTTPS from other servers just fine.

Maybe some cipher issue? Keylength? Supported TLS cipher suites? The thing that irritates me is that just these three devices seem to have that problem. All other MT devices I run don’t seem to have the problem even though they are running the same ROS version.

I’m a bit stymied.

Cheers,
Toby.

5

Ecliptic Key instead of RSA?
MikroTik supports only TLS 1.2

6

Nope. No EC cert. RSA with 4096 bits.

Besides, all my other MikroTik devices can download this very same file just fine.

Cheers,
Toby.

7

ops…

full export without omit anything except username and password of working and non-working?

probably hidden firewall rules between devices, also on web server?

8

Non-working (switch):

[admin@Switch] > /ip firewall export
# apr/29/2021 15:57:23 by RouterOS 6.47.9
# software id = ###
#
# model = CRS112-8P-4S
# serial number = ###
[admin@Switch] > /ip firewall export

Working (AP behind the switch):

[admin@AP] > /ip firewall export
# apr/29/2021 15:58:48 by RouterOS 6.47.9
# software id = ###
#
# model = RouterBOARD wsAP 5Hac2nD
# serial number = ###
[admin@AP] >

No firewall rules whatsover. Same on the server.

Besides, I can access the server. If I turn off HTTPS on port 443 and turn on HTTP on port 443, I can download just fine:

[admin@Switch] > /tool fetch url="http://192.168.100.246:443/FILE"
      status: finished
  downloaded: 3KiBC-z pause]
       total: 3KiB
    duration: 1s

[admin@Switch] >

If I turn TLS back on, the timeout strikes again:

[admin@Switch] > /tool fetch url="https://192.168.100.246/FILE"
  status: failed

failure: connection timeout
[admin@Switch] >

Cheers,
Toby.

9

…for full export I intend full export of devices, not only firewall filter section…



/certificate settings
set crl-download=no crl-store=ram crl-use=no

/tool fetch url="https://192.168.100.246//graphs/cpu/daily.gif" check-certificate=no
10

No particular settings on either the (non-working) switch or the (working) AP:

[admin@Switch] /certificate settings> print
  crl-download: no
       crl-use: no
     crl-store: ram
[admin@Switch] /certificate settings>

and:

[admin@AP] /certificate settings> print
  crl-download: no
       crl-use: no
     crl-store: ram
[admin@AP] /certificate settings>

Cheers,
Toby.

11

Have try?

/tool fetch url="https://192.168.100.246/graphs/cpu/daily.gif" check-certificate=no

dhcp and security package are active on “8P”?

I disable dhcp, security and other unused packages until 6.46.8, after that I leave that packages active…

12

No, I have not tried, because that IP is the IP of a web server that does not server this particular file. However, nothing has changed. I just posted the configuration for /certificate (which is boring because it is the same unchanged default values on all systems, whether they run into the timeout or not).

I do not see where you are going with this, to be honest?

Cheers,
Toby.

13

Both DHCP and Security are active on both the (non-working) switch and the (working) AP behind it.

Cheers,
Toby.

14

mmm...
Have try the option "check-certificate=no" on the right url?


Sorry, you're absolutely right, I'm just wasting time trying to help you.

Have a nice day.

15

What's the problem with trying what they recommend to you? You asked for help and immediately say yourself that this is not right and wrong, and that there is no point in trying. Then there is probably no point in asking for help, since you do not need it. Am I wrong?

16

Hi,

Yes, I have tried that. No difference.

Sorry, you're absolutely right, I'm just wasting time trying to help you.
Have a nice day.

Just to make sure you don't misunderstand: I am very grateful for your effort. I just don't understand why you have asked the questions you asked.

Cheers,
Toby.

17

Hi,

OK, I appear to have pushed some wrong buttons inadvertently. I am sorry, I did not mean to imply I am not grateful for help.

What I meant to say was: I have not re-tried downloading the file because nothing has changed. I have been asked whether the CRL handling configuration was identical on both systems, and I have answered that. I have not retried downloading the file again. I did not understand the reason for retrying to download that URL (particularly since it was not the one I had been talking about). That is all I meant to say. If I stepped on somebody’s toes, I apologize, that was not my intention.

I am, indeed, very grateful for any hints, and have tried very much, as you can see, to answer any question faithfully and correctly.

Cheers,
Toby.

18

Everything is ok, just try experimenting and follow all the recommendations. It happens that a seemingly meaningless action is a real solution to a problem.

19

Hi again,

I have had the chance to do some more testing with some more devices. It still looks very much like the CRS112-8P-4S has some sort of weird issue; a friend of mine happens to run one as well, and he confirms the very same behavior for his CRS112, while all his other MikroTik devices were able to download the file just fine.

So, as far as my observations go, I have seen four different CRS112s (three of which run ROS 6.47.9 on firmware 6.47.9, one running ROS 6.48.1 on firmware 6.46.1) that all fail to download the file but run into a timeout, while a number of other MikroTik devices were able to download the file without any issues (in particular, at least one each of CRS326-24G-2S+, Groove A-52HPn r2, RB760iGS, RB941-2nD, RB960PGS, RBD52G-5HacD2HnD, RB952Ui-5ac2nD, cAP Gi-5acD2nD, cAP L-2nD, mAP 2nD, mAP L-2nD, wAP 2nD r2, wAP G-HacT2HnD, wsAP 5Hac2nD, all running ROS 6.47.9/firmware 6.47.9).

I am certain that there is no network or firewall issue because if I change the protocol from HTTPS to HTTP (while staying on port 443), the CRS112 can also download the file without a problem. The issue must be with the HTTPS stack somewhere. Certificate validation seems to be no factor, because all of my devices are configure identically in this respect, and adding check-certificate=no to the fetch command does not make a difference.

Here was a concrete example of a five-byte file that the CRS112s cannot download: hXXps://www.XXXXX.de/.acme.sh/Test
(I have removed the file because I have implemented a workaround.)

I am completely out of ideas as to what is different on the CRS112s. Doesn’t seem to be the architecture (the wsAP, for example, is also mipsbe-based, albeit with a different processor version and speed), shouldn’t be the available RAM (the wsAP with 64 MB and 32 MB free works, while the CRS112s with 128 MB and 98 MB free do not), shouldn’t be the HDD size (again, wsAP with 16 MB/2 MB free works, CRS112s with 16 MB/2.5 MB free do not). About the only consistent observation I can make is that the CRS112s are the only devices with a MIPS 24Kc V8.5 CPU.

Any hints are greatly appreciated.

Cheers,
Toby.

20

Hi,

You are undoubtedly correct, but I am sure you agree that printing the current configuration is definitely not an example of a meaningless-but-actually-effective solution here? :wink:

Cheers,
Toby.