On 08-01 10:54, Luke A. Call wrote: > 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.
Also curiously, the 2nd nmap running, like the first instance it is intended to "unfreeze", also uses 90+% of a CPU (until it also freezes), even though I passed the "-T2" parameter to slow it down.
