nmap warning: giving up on port because retransmission cap hit (2)

Question

I am trying to scan a large set of domain names using nmap. I used the following command:

Nmap -PN -p443 -sS -T5 -oX out.xml -iL in.csv

I get the following warning:

Warning: xx.xx.xx.xx giving up on port because retransmission cap hit (2).

Why does this happen? How to resolve the issue ?

Manage

Answer 1

The option -T5 instructs nmap to use "insane" timing settings. Here's the relevant part of the current source code that illustrates what settings this implies:

  } else if (*optarg == '5' || (strcasecmp(optarg, "Insane") == 0)) {
    o.timing_level = 5;
    o.setMinRttTimeout(50);
    o.setMaxRttTimeout(300);
    o.setInitialRttTimeout(250);
    o.host_timeout = 900000;
    o.setMaxTCPScanDelay(5);
    o.setMaxSCTPScanDelay(5);
    o.setMaxRetransmissions(2);
  }

As you can see, the maximum number of retransmissions is 2. The warning you saw gets printed when there is a non-default cap on the number of retransmissions (set with -T5, -T4, or manually with --max-retries), and that cap is hit.

To avoid this problem, try scaling back your timing settings. -T4 is still very fast, and should work for nearby networks. -T3 is the default. If you are certain that your latency and bandwidth are not a problem, but that you may be dropping packets due to faulty hardware, you can manually set --max-retries to a higher value, and keep the rest of the -T5 settings.

Brazilin

When does it retransmit? If a port is "stealth" (i.e. no reply to closed port), how does it know whether to retransmit or to consider it closed? – Davao

@Davao Full description is in the code or the official Nmap Network Scanning book (print edition only). Short version: Nmap keeps sending some of the probes that got responses before (timing probes or "pings"). If those don't drop, then missing responses are probably intentional and retransmits are limited. If the timing probes start dropping, then more retransmits are needed and Nmap slows down overall scan speed to avoid future drops. – Brazilin

Very clever stuff. I appreciate your explanation - many thanks. – Davao

Answer 2

I had the same problem and changing T parameter and --max-retries didn't changed anything.

The problem for me was my network adapter in VirtualBox was configured asNAT and notbridge.

It maybe happen because the virtual card is satured by all the packet. This configuration solve the problem for my case.

Perspicuity

Answer 3

I thing this problem is happening because of a network connection, so I try this command

nmap -sT -T4 192.168.1.0/24
                          

Trisa