Is there a way, good or bad, to relax pf enough to let nmap do its OS
detection?
I am on 4.8.
El 07/03/2011 10:54, Henrik Engmark escribiC3:
Is there a way, good or bad, to relax pf enough to let nmap do its OS
detection?
I am on 4.8.
Way too vague question; you should at least describe the scenario.
On Mon, Mar 07, 2011 at 10:54:09AM +0100, Henrik Engmark wrote:
Is there a way, good or bad, to relax pf enough to let nmap do its
OS detection?
I am on 4.8.
You can always disable pf (pfctl -d). I'd also expect any sensible
configuration without scrub or (implicit) keep state to work, but I
On Mon, Mar 07, 2011 at 11:34:50AM +0100, Daniel Gracia wrote:
El 07/03/2011 10:54, Henrik Engmark escribiC3:
Is there a way, good or bad, to relax pf enough to let nmap do its OS
detection?
I am on 4.8.
Way too vague question; you should at least describe the scenario.
I'm pretty
That is correct. I noticed every try to do an OS detection with
nmap failed for incredibly strange reasons reported by nmap,
like no route to host even though the target was on the same
subnet. Nmap can't even ping on OpenBSD. At least not since 4.7.
And so I went on to really read the CAUTION
I tried that, with no success.
Also compiled 5.51 from source with the same result.
I get this:
sendto in send_ip_packet_sd: sendto(4, packet, 60, 0, ya.da.ya.da, 16)
= No route to host
Offending packet: TCP ya.da.ya.da:59268 ya.da.ya.da:80 ttl=55
id=27672 iplen=60 seq=3496514045 win=128
On Mon, Mar 07, 2011 at 01:36:31PM +0100, Henrik Engmark wrote:
I tried that, with no success.
Also compiled 5.51 from source with the same result.
I get this:
sendto in send_ip_packet_sd: sendto(4, packet, 60, 0, ya.da.ya.da,
16) = No route to host
Offending packet: TCP ya.da.ya.da:59268
On Mon, Mar 07, 2011 at 10:54:09AM +0100, Henrik Engmark wrote:
Is there a way, good or bad, to relax pf enough to let nmap do its
OS detection?
I am on 4.8.
Try --send-eth.
Worked like a charm.
I get a bunch of
adjust_timeouts2: packet supposedly had rtt of -301586 microseconds.
Ignoring time.
adjust_timeouts2: packet supposedly had rtt of -301586 microseconds.
Ignoring time.
which I don't get with pf disabled, otherwise just peachy.
Thank you everyone
On 2011-03-07, Henrik Engmark h...@tti.se wrote:
That is correct. I noticed every try to do an OS detection with
nmap failed for incredibly strange reasons reported by nmap,
like no route to host even though the target was on the same
subnet.
it's not intuitive, but EHOSTUNREACH (no route
10 matches
Mail list logo