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 above. Regards, Markus
