Re: ***SPAM*** Re: nmap on routed ip4 networks, openbsd/pf or package/port issue?
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?
Re: nmap on routed ip4 networks, openbsd/pf or package/port issue?
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.
Re: nmap on routed ip4 networks, openbsd/pf or package/port issue?
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.
nmap on routed ip4 networks, openbsd/pf or package/port issue?
Hi. I very rarely post on these lists, so please go easy on me. Not sure on what list to post, since I don't know what causes the issue, so I thought I would start here and maybe get directed elsewhere. So I set up a new 6.3 with the sole purpose of nmapping, since my older OpenBSDs is coremapping on me with nmap. A very clean setup; 2 interfaces: em0: 192.168.1.200/24 em1: 10.10.10.200/26 mygate: 192.168.1.1 route: 10/8 -> 10.10.10.193 resolv.conf: 8.8.8.8 pf.conf: set skip on lo block return pass sysctl is default out of the box except for machdep.allowaperture=2 nmap is from 6.3 packages: nmap-7.60p0 Can ping and communicate everywhere essential, so network on both ifs seems fine. 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. For some reason, I also tried it again against 10.20.30.193-254, but no luck. Still stops after a minute or two and just does nothing. Worth mentioning is it starts off fine, giving me loads of information about open ports and completed SYN stealth scans against hosts. I am well aware that this might not be perfectly suited for misc, but I recall having several issues in the past with the combination OpenBSD/pf/nmap, so I thought I would give it a shot here first. "Hardware" under this OpenBSD is VMWare Workstation Pro 14.1 on Windows 10, where the 2 vm-nics are bridged to 2 VLAN configured virtual Intel (I219-LM) NICs on my Windows host. I don't think that is what's causing the issue I am having, but thought I should mention it. "dmesg" output is at the bottom. Best Regards, Henrik Engmark My food poops of your food ### dmesg ### OpenBSD 6.3 (GENERIC.MP) #107: Sat Mar 24 14:21:59 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17162960896 (16367MB) avail mem = 16635740160 (15865MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (248 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 05/19/2017 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S17F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz, 2592.13 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache acpitimer0: recalibrated TSC frequency 2591813105 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 65MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz, 2591.88 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz, 2591.94 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz, 2591.88 MHz cpu3:
