Unrealistic Min RTT (with --rate)

[kim0]

This does not happen every time, but happens quite often. The below is for a host that I access over WAN. The min RTT below is unrealistic

$ sudo nping --tcp 82.129.131.170 -p 123 -c 10 --rate 10

Starting Nping 0.7.12 ( https://nmap.org/nping ) at 2016-04-09 16:54 EET
SENT (0.0057s) TCP 192.168.1.12:55679 > 82.129.131.170:123 S ttl=64 id=32010 iplen=40  seq=357387181 win=1480
RCVD (0.0784s) TCP 82.129.131.170:123 > 192.168.1.12:55679 SA ttl=51 id=0 iplen=44  seq=237315656 win=14600 <mss 1412>
SENT (0.1063s) TCP 192.168.1.12:55679 > 82.129.131.170:123 S ttl=64 id=32010 iplen=40  seq=357387181 win=1480
RCVD (0.1989s) TCP 82.129.131.170:123 > 192.168.1.12:55679 SA ttl=51 id=0 iplen=44  seq=238909168 win=14600 <mss 1412>
SENT (0.2068s) TCP 192.168.1.12:55679 > 82.129.131.170:123 S ttl=64 id=32010 iplen=40  seq=357387181 win=1480
SENT (0.3113s) TCP 192.168.1.12:55679 > 82.129.131.170:123 S ttl=64 id=32010 iplen=40  seq=357387181 win=1480
RCVD (0.3145s) TCP 82.129.131.170:123 > 192.168.1.12:55679 SA ttl=51 id=0 iplen=44  seq=240460782 win=14600 <mss 1412>
SENT (0.4158s) TCP 192.168.1.12:55679 > 82.129.131.170:123 S ttl=64 id=32010 iplen=40  seq=357387181 win=1480
SENT (0.5177s) TCP 192.168.1.12:55679 > 82.129.131.170:123 S ttl=64 id=32010 iplen=40  seq=357387181 win=1480
RCVD (0.5475s) TCP 82.129.131.170:123 > 192.168.1.12:55679 SA ttl=51 id=0 iplen=44  seq=240460782 win=14600 <mss 1412>
RCVD (0.5521s) TCP 82.129.131.170:123 > 192.168.1.12:55679 SA ttl=51 id=0 iplen=44  seq=243742136 win=14600 <mss 1412>
SENT (0.6191s) TCP 192.168.1.12:55679 > 82.129.131.170:123 S ttl=64 id=32010 iplen=40  seq=357387181 win=1480
RCVD (0.6194s) TCP 82.129.131.170:123 > 192.168.1.12:55679 SA ttl=51 id=0 iplen=44  seq=243742136 win=14600 <mss 1412>
RCVD (0.6631s) TCP 82.129.131.170:123 > 192.168.1.12:55679 SA ttl=51 id=0 iplen=44  seq=246898232 win=14600 <mss 1412>
SENT (0.7236s) TCP 192.168.1.12:55679 > 82.129.131.170:123 S ttl=64 id=32010 iplen=40  seq=357387181 win=1480
SENT (0.8280s) TCP 192.168.1.12:55679 > 82.129.131.170:123 S ttl=64 id=32010 iplen=40  seq=357387181 win=1480
RCVD (0.8741s) TCP 82.129.131.170:123 > 192.168.1.12:55679 SA ttl=51 id=0 iplen=44  seq=250192065 win=14600 <mss 1412>
SENT (0.9325s) TCP 192.168.1.12:55679 > 82.129.131.170:123 S ttl=64 id=32010 iplen=40  seq=357387181 win=1480

Max rtt: 92.479ms | Min rtt: 0.080ms | Avg rtt: 40.263ms
Raw packets sent: 10 (400B) | Rcvd: 8 (352B) | Lost: 2 (20.00%)
Nping done: 1 IP address pinged in 1.94 seconds

[capt2101akash]

@kim0 I think this bug is resolved as I have tested it and I didn't get any RTT which we can say is unrealistic.
@dmiller-nmap can you confirm this ?

[dmiller-nmap]

This is happening because Nping isn't incrementing any sequence number, and therefore cannot accurately map replies to the probe that provoked them. For ICMP, we increment the sequence number, and we should be doing the same with TCP, but we're not. So when the probe at 0.3113s goes out, we have not yet received a response to the probe at 0.2068s. That one gets a response at 0.3145s which should count as 107.7ms, but instead counts as 2.2ms. The pattern happens several times, leading to really messed up results.