Re: nmap ?

[Daniel Miller <bonsaiviking () gmail com>]

Michael,

Please keep dev () nmap org CC'd on replies so that other users can see the
answers. Response inline below:

On Mon, Jan 11, 2016 at 2:16 PM, Michael Chrisco <MChrisco () jackhenry com>
wrote:

> Thank you so much for a response.
>
>
>
> So my original issue with udp 68 seems like a vmware issue. If you scan a
> guest OS the host OS responds for it on udp 68. The –reason let me know it
> was the other IP that responded. I will ask vmware about that.
>
> Try it on a VM and look at response. nmap -sU -p 68 -Pn --reason
I'm glad you got that solved. --reason is a handy option, which is why we
recently enabled it for -v2 and higher.

> Now since you responded the first time I have another question. I always
> used nmap -sn -n -Pn -PR to do a pure ARP scan and could verify with wire
> shark that ARP packets are the only thing that is transmitted. I upgraded
> to nmap 7.01 and that command doesn’t send any packets on the wire and
> comes back with the entire range is active/up. Ex. /24 = 256 host.
>
>
>
> I went back to ver 6.47 and it behaves like it used to. So is this a bug?
> Depreciated options? Is there a new way to do a ARP scan with no other
> packets being transmitted at all?

I had forgotten about this change, r33334 [1]. Now -Pn *does* override -PR,
and in fact overrides all -P* options. Previously, it could override them
*if* it occurred "later" in the options list, so the behavior was dependent
on the order of the options. Your command will still work if you just
remove -Pn from the options list. -PR will force an ARP ping, and if the
host is not directly connected it will show as down without any packets
sent (except for a forward DNS lookup if necessary).

Dan

[1]
https://github.com/nmap/nmap/commit/e525388f36de525225ffef8463c67a0047670542

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/