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.
Cheers
Giovanni
