Hello,
Can you please tell me if it is possible with Mikrotik to ping a remote host using the tisipe protocol?
For example, on Cisco ASA, this can be done with the command:
ping tcp repeat
Thanks in advance for your help!
Oliver07, thank you for your answer.
You absolutely rightly noticed that the Ping command works according to the ICMP protocol, but not TCP. But the remote host, to which I want to check access, is not accessible via ICMP - only via TCP.
In Cisco, for example, when using the Ping command, I can select the protocol - by default, ICMP is used, but I can select the TCP and the number of the port to be checked. There are also programs for testing access by TCP, such as “Paping” (https://code.google.com/archive/p/paping/), or “PsPing” (https://docs.microsoft.com/en-us/sysinternals/downloads/psping).
In most cases Mikrotik is more flexible than Cisco. Is this case an exception?
If the remote host is running HTTPS, HTTP, SFTP, FTP, or TFTP, you can get the effect you want with:
/tool/fetch address=router.example.com src-path=/ mode=http
That command example is the minimal form: it can’t be made shorter without scripting. Depending on the mode parameter, further parameters might be required.
Despite what the docs say, the “mode” parameter does not default to http: you must give a value.
I couldn’t find a way to use this with other services. The tool appears to insist on interpreting the reply, so it’s hard to tell if it connected or not. It’d be better if there were a “verbose” mode where it just dumped what it got in response to the request. Alas.
Is that “tisipe” just phonetic for TCP ?
In Unix/Linux there is a difference for “traceroute”. While for Windows ICMP is used, in Unix/Linux UDP is used.
Mikrotik Traceroute tool can do both ICMP or UDP. It works between MT routers (other devices may not respond to UDP)
It’s based on repeated PING with different TTL. But at least you could have a UDP based PING test result if you want.
“tisipe” - it’s a typo after google translate, sorry. I meant TCP, of course.
For my case, it turned out to be a working command:
/tool/fetch address=<IP> src-path=/ mode=https
That said:
- if port 443 is open on the remote host, I get the message:
status: failed
failure: ssl connection error: handshake failed: error 609e09c (6)
- if port 443 is closed on the remote host, I get the message:
status: failed
failure: cannot open file
Thank you, problem solved.
That’s probably a result of using self-signed certificates. It’s possible you could import that certificate into the router you’re using as the source of the “TCP ping” and mark it as trusted to get a successful connection, resulting in a more easily interpreted status reply.