Re: Trace and reality differs

[Fyodor <fyodor () insecure org>]

On Thu, Jan 15, 2009 at 08:49:40PM -1100, Hans Nilsson wrote:
> Hello, I was just trying a scan as follows:
> nmap --send-ip -oA log -T2 -sS -n -P0 --randomize-hosts -p 139
> 231.211.XXX.122-124 --max-retries 0 -vvvvv --packet-trace
>
> (on a local network with the latest stable version)
> Now the output nmap gives me claims that it sends three syn packets to
> port 139 but according to my packet sniffing nmap still does it's
> arp-ping and only scans the host that replies to it. The reason I used
> --send-ip is because I don't want to use the ARP-ping,

With your command, Nmap is no longer doing the ARP ping.  Nmap just
hands the IP packet to your OS to send because you requested
--send-ip.  Then Nmap prints that packet in the packet trace logs.
But your OS still needs to do an ARP request because it can't send a
packet to the target without a destination MAC address.  Since the
target is down or otherwise not responding to the ARP request, your OS
can't send the packet.

If you really want the packets to be sent, you can try adding a static
entry to your system ARP table.  Maybe you can even get away with
adding a broadcast MAC address to the table (I don't know if that
works).

> to work like that. And anyways the claimed packet trace I'm getting from
> nmap doesn't fit with reality.

The Nmap packet trace only shows the packets Nmap sends or delivers to
the OS as well as the packets it receives.  Since packets can be
dropped or blocked at various points along their path, sniffer results
at any given point may differ.  So sniffing is definitely still useful
in addition to Nmap's --packet-trace when trying to figure out what is
really going on.

Cheers,
-F

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org