On 08-01 15:08, Henrik Engmark wrote:
>> So I set up a new 6.3 with the sole purpose of nmapping, since my older OpenBSDs is coremapping on me with nmap.
>>[....]
>> On to the problem, I scan my local LAN with the following:
>> nmap -Pn -A -v -v --send-eth -e em0 -stylesheet somestylesheet -oA
>>/tmp/nmapout 192.168.1.0/24 This works fine, every time i try. Takes about an hour. However, when I try it on a remote routed net like so:
>> nmap -Pn -A -v -v --send-eth -e em1 -stylesheet somestylesheet -oA
>>/tmp/nmapout 10.20.30.192/26
>>
>> nmap stops doing anything after a minute or so, it goes to 0% cpu and stays there. I waited at least 24 hours without any sign of life.
>> top tells me nmap is WAIT/bpf after those first couple of minutes. I am not sure what that means exactly, but I figured maybe something with pf, so I disabled pf alltogether and tried again, with the same result.
>
>I am curious what you learn as I have seen similar behavior. I've been nmapping a printer on my local network, trying different things, and nmap freezes for me after a short or long time.
>
>Strangely though, it seems to ~ "unfreeze" if I start another nmap instance, probing the same address, in a separate terminal window.
>Sometimes I have to kill and restart that other instance as it freezes too, but this workaround has allowed me to continue at least.
>
>I am on 6.3 stable with latest syspatch.
>
Indeed starting several nmap sessions against the same subnet seems to make things a lot better.
They somehow seem to keep eachother alive.
This might just be me who is too inexperienced with tweaking nmap, but I don't run in to this issue on other platforms.
Does anyone know where best to pursue this problem? The ports list, the maintainer directly or not at all perhaps?
No comments:
Post a Comment