Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: Nsock port scanning
From: Henri Doreau <henri.doreau () gmail com>
Date: Mon, 31 Mar 2014 16:29:58 +0200

2014-03-10 20:54 GMT+01:00 Jacek Wielemborek <d33tah () gmail com>:
06/01/2014 22:23:12 Jacek Wielemborek <d33tah () gmail com>:

On CCC we talked a bit about the scanning pipeline and if I understood it
correctly, one of the steps we have to take first is to implement port
scanning using Nsock. Yesterday I finally got around to that and created
nmap-nsock-scan branch, where I wanted to experiment with adding TCP
connect scanning using Nsock. I'm happy to announce that I've got a proof
of concept ready and I wanted to ask you guys what should I do next.

Currently, it's implement as a separate Nmap switch, -sD. This creates an
nsock pool and schedules TCP connections for all specified ports for all the
targets, then enters the nsock main loop, which ends when all connections
had been established. It definitely doesn't feel like the most elegant
solution - for example nmap -sD -p- localhost/24 will result in:

libnsock nsock_make_socket(): Socket trouble: Too many open files

I'm looking for a way to implement it in a more sane manner - one of my
ideas is to schedule the connect() for the first port only and then in the
connect handler schedule next connections. Another idea is to schedule,
say, 100 connections and if the 100th gets its handler fired, schedule
another bundle. BTW, I completely didn't worry about timing for now. Could
you guys give any hints on how would you expect that to work?

Jacek Wielemborek

Hi again,

I just submitted my GSoC about nsock port scanning. It can be found here:


I'd be happy to hear some feedback about this project :)

Jacek Wielemborek

Hi Jacek,

I should be ashamed for not having given you any feedback on this
work. I definitely support the idea of having nsock-based port
scanning but the first question I'd ask is whether we want it
implemented "raw" (i.e. a reimplementation of ultrascan that would use
nsock) or through NSE (that uses nsock already). Both have advantages
and drawbacks. I personally appreciate NSE's versatility and its
stable layers and libraries...

Concerning your question about scheduling connections: as you suggest,
a sliding window (or windowS, actually) algorithm is the way to go.
Implementation should offer proper hooks for congestion control and
speed limits.


Sent through the dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

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