Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Markus Lude (markus.ludegmx.de)
Date: Thu May 23 2013 - 14:39:55 CDT
On Thu, May 23, 2013 at 03:09:55PM +0200, Giovanni Bechis wrote:
> On 05/23/13 12:04, Stuart Henderson wrote:
> > On 2013/05/23 10:09, Stuart Henderson wrote:
> >> On 2013/05/23 10:35, Giovanni Bechis wrote:
> >>> On 05/17/13 20:01, Rodolfo Gouveia wrote:
> >>>> Hello,
> >>>> I've noticed that nmap is rather slow when scanning with -sS
> >>>> in contrast to -sT and also to -sS in Linux.
> >>>> With a clean 5.2 install and pf disabled, running a scan of
> >>>> this type takes 329.10s while for the same host but with instead
> >>>> -sT is 0.46s!
> >>> maybe the slowness could be related to the fact that struct bpf_timeval (in net/bpf.h) is different from struct timeval.
> >>> Cheers
> >>> Giovanni
> >> I don't think this is the problem - i386 is affected too, but
> >> bpf_timeval and timeval are the same size (32 bits) there.
> >> It does seem like some problem with the dynamic timing.
> >> If I force "--min-rate 3000" I get around 2650 packets/s, but if
> >> I use dynamic timing, even with -T 5 (aggressive), I only get
> >> 48 packets/s.
> >> Has anyone talked to upstream about this?
> > ...
> > the patches to NmapOps.cc, EchoServer.cc, ProbeMode.cc, nsock_core.c
> > and maybe some others need fixing - they mix bpf_timeval with timeval
> > (returned from gettimeofday). at the moment this "works" on 32-bit arch,
> > but it will break everywhere when we move time_t to long and tv_sec
> > to time_t.
> what about teduing bpf_timeval from net/bpf.h ? (the only consumers
> seems to be net/nmap, libpcap and tcpdump.
net/daq used by snort also has a patch which use that header.
snort / daq were patched to fix similar issues in the way describeed