Have seen multiple reports of this, but have no info about which systems are affected. Please provide observations including:
nmap --version--packet-traceExisting reports:
nmap -sn)nmap -T5)Nmap version 7.40 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.3.3 openssl-1.1.0c libpcre-8.39 libpcap-1.8.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select
Options used: nmap -sP --packet-trace 192.168.1.1/24
This is reproducible with high probability on bare hardware; OS Linux 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux
Network is fairly generic, e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Relevant portions of output, with altered IPs/MACs:
```
nmap -sP --packet-trace 192.168.1.1/24
Starting Nmap 7.40 ( https://nmap.org ) at 2018-02-15 05:29 UTC
...
SENT (1.6851s) ARP who-has 192.168.1.10 tell 192.168.1.2
...
SENT (1.7859s) ARP who-has 192.168.1.10 tell 192.168.1.2
SENT (1.8860s) ARP who-has 192.168.1.11 tell 192.168.1.2
RCVD (1.6859s) ARP reply 192.168.1.10 is-at 40:40:40:40:40:40
RCVD (1.7866s) ARP reply 192.168.1.10 is-at 40:40:40:40:40:40
...
Nmap scan report for 192.168.1.10
Host is up (-0.100s latency).
MAC Address: 40:40:40:40:40:40 (Unknown)
````
Hi, I wonder why there is no progress here.
I can see negative latency values on my network when issuing nmap -sn -T5 ... with both versions: 7.40 and 7.70SVN. Isn't @szakharchenko's analysis correct?
@P4z : nobody seems to care:)
Most helpful comment
@P4z : nobody seems to care:)