I want to remotely examine if some servers are up.

I don't use the ping command because it gives a lot of wrong results like "destination host unreachable" and "request Timed out" due to bad networking infrastructure.

I try to use nmap command to examine servers by open ports. Nmap gives me the real opened ports, but when I turn off the server, nmap still reports it running.

The client logs into the internet through a usb modem, and the destination host that I examine is connected to the internet through a TP-Link Access point with usb modem and a static IP.

When I turn off the access point completely and I run this command:

nmap -p 80 -vv

Starting Nmap 7.01 ( https://nmap.org ) at 2017-01-31 11:54 EET

Initiating Ping Scan at 11:54

Scanning [2 ports]

Completed Ping Scan at 11:54, 0.61s elapsed (1 total hosts)

Initiating Parallel DNS resolution of 1 host. at 11:54

Completed Parallel DNS resolution of 1 host. at 11:54, 0.01s elapsed

Initiating Connect Scan at 11:54

Scanning [1 port]

Discovered open port 80/tcp on

Completed Connect Scan at 11:54, 0.09s elapsed (1 total ports)

Nmap scan report for

Host is up, received syn-ack (0.55s latency).

Scanned at 2017-01-31 11:54:17 EET for 0s


80/tcp open  http    syn-ack

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.78 seconds

And when put the ip in a browser it gives:

"This site can’t be reached"

"The connection was reset."

This happens in both situations when it is turned on and turned off.

traceroute when the access point is turned on gives:

traceroute to (, 30 hops max, 60 byte packets

 1 (  1.667 ms  1.768 ms  2.508 ms

 2  * * *

 3 (  759.425 ms  769.911 ms  770.401 ms

 4 (  770.142 ms  770.508 ms  770.871 ms

 5 (  771.866 ms  771.859 ms  779.227 ms

 6 (  780.458 ms  792.637 ms  792.453 ms

 7 (  803.571 ms  51.573 ms  41.250 ms

 8 (  49.261 ms  49.264 ms  49.384 ms

 9  * * *

10  * * *

11  * * *

12  * * *

13  * * *

14  * * *

15  * * *

16  * * *

17  * * *

18  * * *

19  * * *

20  * * *

21  * * *

22  * * *

23  * * *

24  * * *

25  * * *

26  * * *

27  * * *

28  * * *

29  * * *

30  * * *

running traceroute when the access point turned off gives the same result but the changes only in values of milli seconds ms.

So, what the explanation of this behaviour?

  • Thanks for the additional information, but I'm still not seeing this as a security issue. You say that ping is unreliable due to network issues, and you cannot access the server whether it is on or off. This looks more and more like a network troubleshooting issue than anything else. Has it ever worked? Are you sure that the mobile data provider allows incoming connections like that?
    – schroeder
    Jan 31, 2017 at 14:05

2 Answers 2


What do you have, network-wise, between you and your servers ?

Any active element (router, firewall, etc.) can modify your trafic, hence:

  1. the fact that ping does not work can be unrelated to your server state. ICMP trafic is often something completely filtered out
  2. your nmap case is stranger, but can still be explained the same way, it also depends if you use a name or an IP

In both cases to really monitor things you should use a service you control on the server (like ssh, http or something more specific), connect to it and verify that you get back what you expect (a specific result).


If the information you provided is correct it entirely possible you have been the victim of a so called 'man-in-the-middle' attack:


In computer security, a man-in-the-middle attack (often abbreviated mitm, or the same using all capital letters) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other. A man-in-the-middle attack can be used against many protocols. One example of man-in-the-middle attacks is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker.

Taking the info provided at face value this is a plausible explanation. The best course of action if you believe this to be the case would probably be to try nmapping (or pinging) the computer via a proxy. This may fix the problem, depending on the source and nature of the MitM.

  • 3
    Why do you think a mitm is happening? This is an awfully specific suggestion with very little data to go on.
    – schroeder
    Jan 30, 2017 at 22:20
  • Because the data reported appears to be inconsistant with the expected data. Are you covering something up, maybe? There's an awfully angry seeming downvote when the answer is completely logical given the question raised. Jan 30, 2017 at 23:37
  • 3
    @JustInTimeBerlake No, I'm not a sock, I just happen to agree with Schroeder. Blaming a MitM is quite a leap, and almost certainly incorrect. Definitely not "likely."
    – Xander
    Jan 31, 2017 at 0:04
  • Before jumping to the conclusions of there being a complex, malicious attack involved, you should always first ensure that the more mundane technical troubleshooting steps are covered first. It's always nice to think that you are doing battle with a shadowy government agency, and not so exciting to find out that you simply screwed up a basic networking concept.
    – schroeder
    Jan 31, 2017 at 7:34

Not the answer you're looking for? Browse other questions tagged .