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. basically: whenever you fetch gettimeofday and want to use it in a bpf_timeval, you can't just cast it. the gettimeofday() call needs to be stored into a temporary variable, and then the individual members of the bpf_timeval (tv.tv_sec / tv.tv_usec) need to be set from the individual members of the temporary variable. and having looked at the set of patches, I think we should clean this stuff up before reporting this problem upstream..
