Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: SYN scan running slower than Connect scan?
From: Fyodor <fyodor () insecure org>
Date: Sat, 18 Mar 2006 23:39:05 -0800

On Sat, Mar 18, 2006 at 11:50:50PM -0600, Ron wrote:

Well, with the advice of "kx," I will re-post this and try to sound a
little bit less abrupt.

Yeah, KX is pretty wise on these matters.

It may be debatable whether or not this is appropriate for the nmap-dev 
forum, but I suspect that this weirdness (that I will describe) stems 
from something weird in the implementation of Nmap.  Since this is the 
densest group of people who are knowledgeable in that area, it seems 
logical to post this here.

Yeah, general Nmap questions are OK here.  Maybe I'll create an
nmap-helpers list someday for users to help each other use Nmap.  But
for now this is the closest we have got.  The nice thing is that
questions (and the answers) here are archived so that (we can hope)
future people with similar questions will find them.

over a LAN.  So, a SYN scan sends 2 packets: SYN and RST, and receives 
1: SYN/ACK.  A Connect scan sends at least 3 packets: SYN, ACK, and RST, 
and receives 1: SYN/ACK.  Because it sends more packets, it is logical 
to me that a Connect scan would run slower on any system with open

This packet count is true for open ports, but that is only a handful.
In your 65K-port scan, probably at 99.9% of the ports are in the
closed state.  In that case, both scan types involve two packets: A
SYN to the target and a RST coming back.

Does anybody here know any reason why a SYN scan would run slower than a 
Connect scan, from Linux?  Is it just weirdness in the implementation? 
Or is there some networking reason?

First remember that we are talking about a very small time difference
here.  The 10.53 second run is 0.16 milleseconds per port and the
13.63 second scan is 0.21 milliseconds per port.  So we are talking a
difference of only one twentieth of a millisecond per port.  At these
speeds (you're obvilusly on a fast, reliable, low-latency network
without a firewally blocking any packets), issues like how many
context switches are required start making a big difference.  Both SYN
and connect() scan use basically the same algorithm (the ultra_scan()
function), so the differences mostly relate to how we interface with
the kernel:

Connect scan: Use the connect() call, then select() to determine which
file descriptors connected and which ones (the vast majority) didn't.

Syn scan: Use libpcap to listen for packets on the wire, react
appropriately when we see the RST's.

Which one is faster at these low levels depends on a lot of factors,
including the exact timing and especially what sort of system you are
running the scan on.  SYN scan is almost always faster than connect()
on Windows, for example, because there implementation is so lame (and
even intentionally inserts delays with SP2).  All in all, SYN scan is
the one to use unless you can't (aren't root, IPv6 scan, Windows
non-ethernet).  It's behavior against nonresponsive ports is much
better since it gives Nmap full control of retransmission times.
Also, Nmap is better able to interpret responses since it can read the
returned packet directly rather than having to divine what it might
have been based on the connection error.

Hope this helps,

Sent through the nmap-dev mailing list

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]