|
|
Nping Reference Guide (Man Page)
Namenping — Network packet generation tool / ping utility Synopsisnping [
<Probe Mode>
...] [
<Options>
] {
<target specification>
}
![[Note]](images/note.png) | Note |
|---|
This document describes the very latest version of
Nping available from http://nmap.org/nping Please
ensure you are using the latest version before reporting that a
feature doesn't work as described. |
Nping is an open source tool for network packet generation, response
analysis and response time measurement. Nping allows to generate network
packets of a wide range of protocols, letting users to tune virtually any
field of the protocol headers. While Nping can be used as a simple ping
utility to detect active hosts, it can also be used as a raw packet
generator for network stack stress tests, ARP poisoning, Denial of Service
attacks, route tracing, etc. The output from Nping is a list of the packets that are being sent
and received. The level of detail depends on the options used. ![[Warning]](images/warning.png) | Warning |
|---|
Nping was started as a "Google Summer of Code" Project in 2009.
While it is already useful for many purposes, it is still in an
early stage of development so it may contain bugs and some
functionality may have not been implemented yet. Please, make sure
you read this man page to fully understand Nping's usage before
you use it.
|
A typical Nping execution is shown in Example 1. The only Nping arguments used in
this example are -c, to specify the number of times to
target each host, --tcp to specify TCP Probe Mode,
-p 80,433 to specify the target ports; and then the two
target hostnames. Example 1. A representative Nping Execution # nping -c 1 --tcp -p 80,433 scanme.nmap.org google.com
Starting Nping V. 0.01a ( http://nmap.org/nping ) at 2009-08-04 13:48 CEST
SENT (0.0120s) TCP 96.16.226.135:50091 > 64.13.134.52:80 S ttl=64 id=52072 iplen=40 seq=1077657388 win=1480
RCVD (0.1810s) TCP 64.13.134.52:80 > 96.16.226.135:50091 SA ttl=53 id=0 iplen=44 seq=4158134847 win=5840 <mss 1460>
SENT (1.0140s) TCP 96.16.226.135:50091 > 74.125.45.100:80 S ttl=64 id=13932 iplen=40 seq=1077657388 win=1480
RCVD (1.1370s) TCP 74.125.45.100:80 > 96.16.226.135:50091 SA ttl=52 id=52913 iplen=44 seq=2650443864 win=5720 <mss 1430>
SENT (2.0140s) TCP 96.16.226.135:50091 > 64.13.134.52:433 S ttl=64 id=8373 iplen=40 seq=1077657388 win=1480
SENT (3.0140s) TCP 96.16.226.135:50091 > 74.125.45.100:433 S ttl=64 id=23624 iplen=40 seq=1077657388 win=1480
Statistics for host scanme.nmap.org (64.13.134.52):
| Probes Sent: 2 | Rcvd: 1 | Lost: 1 (50.00%)
|_ Max rtt: 169.720ms | Min rtt: 169.720ms | Avg rtt: 169.720ms
Statistics for host google.com (74.125.45.100):
| Probes Sent: 2 | Rcvd: 1 | Lost: 1 (50.00%)
|_ Max rtt: 122.686ms | Min rtt: 122.686ms | Avg rtt: 122.686ms
Raw packets sent: 4 (160B) | Rcvd: 2 (92B) | Lost: 2 (50.00%)
Tx time: 3.00296s | Tx bytes/s: 53.28 | Tx pkts/s: 1.33
Rx time: 3.00296s | Rx bytes/s: 30.64 | Rx pkts/s: 0.67
Nping done: 2 IP addresses pinged in 4.01 seconds
This options summary is printed when Nping is run
with no arguments. It helps people remember the most common options,
but is no substitute for the in-depth documentation in the rest of this manual.
Some obscure options aren't even included here. Nping 0.1BETA3 ( http://nmap.org/nping )
Usage: nping [Probe mode] [Options] {target specification}
TARGET SPECIFICATION:
Targets may be specified as hostnames, IP addresses, networks, etc.
Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254
-iL <inputfilename>: Read targets from list of hosts or networks
PROBE MODES:
--tcp-connect : Unprivileged TCP connect probe mode.
--tcp : TCP probe mode.
--upd : UPD probe mode.
--icmp : ICMP probe mode.
--arp : ARP/RARP probe mode.
--tr, --traceroute : Traceroute mode (can only be used with
TCP/UDP/ICMP modes.
TCP CONNECT MODE:
-p, --dest-port <port spec> : Set destination port(s).
TCP PROBE MODE:
-g, --source-port <portnumber> : Set source port.
-p, --dest-port <port spec> : Set destination port(s).
--seq <seqnumber> : Set sequence number.
--flags <flag list> : Set TCP flags (ACK,PSH,RST,SYN,FIN...)
--ack <acknumber> : Set ACK number.
--win <size> : Set window size.
--badsum : Use a random invalid checksum.
--mss <size> : Set maximum segment size.
--ws <n> : Set window scale.
--ts <echo,reply> : Set timestamp (echo and reply fields).
UDP PROBE MODE:
-g, --source-port <portnumber> : Set source port.
-p, --dest-port <port spec> : Set destination port(s).
--badsum : Use a random invalid checksum.
ICMP PROBE MODE:
--icmp-type <type> : ICMP type.
--icmp-code <code> : ICMP code.
--icmp-id <id> : Set identifier.
--icmp-seq <n> : Set sequence number.
--icmp-redirect-addr <addr> : Set redirect address.
--icmp-param-pointer <pnt> : Set parameter problem pointer.
--icmp-advert-lifetime <time> : Set router advertisement lifetime.
--icmp-advert-entry <IP,pref> : Add router advertisement entry.
--icmp-orig-time <timestamp> : Set originate timestamp.
--icmp-recv-time <timestamp> : Set receive timestamp.
--icmp-trans-time <timestamp> : Set transmit timestamp.
ARP/RARP PROBE MODE:
--arp-type <type> : Type: ARP, ARP-reply, RARP, RARP-reply.
--arp-sender-mac <mac> : Set sender MAC address.
--arp-sender-ip <addr> : Set sender IP address.
--arp-target-mac <mac> : Set target MAC address.
--arp-target-ip <addr> : Set target IP address.
IPv4 OPTIONS:
-S, --source-ip : Set source IP address.
--dest-ip <addr> : Set destination IP address (used as an
alternative to {target specification} ).
--tos <tos> : Set type of service field (8bits).
--id <id> : Set identification field (16 bits).
--df : Set Dont Fragment flag.
--mf : Set More Fragments flag.
--ttl <hops> : Set time to live [0-256].
--badsum-ip : Use a random invalid checksum.
--ip-options <S|R [route]|L [route]|T|U ...> : Set IP options
--ip-options <hex string> : Set IP options
--mtu <size> : Set MTU. Packets get fragmented if MTU is
small enough.
IPv6 OPTIONS:
-6, --IPv6 : Use IP version 6.
--dest-ip : Set destination IP address (used as an
alternative to {target specification}).
--hop-limit : Same as IPv4 TTL..
--traffic-class <class> : : Traffic class.
--flow <label> : Flow label.
ETHERNET OPTIONS:
--dest-mac <mac> : Set destination mac address. (disables
ARP resolution)
--source-mac <mac> : Set source MAC address.
--ether-type <type> : Set EtherType value.
PAYLOAD OPTIONS:
--data <hex string> : Include a custom payload .
--data-string <text> : Include a custom ASCII text.
--data-file <filename> : Include payload from specified file.
--data-length <len> : Include len random bytes as payload.
TIMING AND PERFORMANCE:
Options which take <time> are in milliseconds, unless you append 's'
(seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
--delay <time> : Adjust delay between probes.
--rate <rate> : Send num packets per second.
MISC:
-h, --help : Display help information on stdout.
-V, --version : Display Nping current version number.
-c, --count <n> : Stop after n rounds.
-e, --interface <name> : Use supplied network interface.
-H, --hide-sent : Do not display sent packets.
-N, --no-capture : Do not try to capture replies.
--privileged : Assume user is fully privileged.
--unprivileged : Assume user lacks raw socket privileges.
--send-eth : Send packets at the raw ethernet layer.
--send-ip : Send packets using raw IP sockets.
--bpf-filter <filter spec> : Specify custom BPF filter.
OUTPUT:
-v : Increment verbosity level by one.
-v[level] : Set verbosity level. E.g: -v4
-d : Increment debugging level by one.
-d[level] : Set debugging level. E.g: -d3
-q : Decrease verbosity level by one.
-q[N] : Decrease verbosity level N times
--quiet : Sets verbosity and debug level to zero.
--debug : Sets verbosity and debug to the max level.
EXAMPLES:
nping scanme.nmap.org
nping --tcp -p 80 --flags rst --ttl 2 192.168.1.1
nping --icmp --icmp-type mask --delay 500 192.168.254.254
SEE THE MAN PAGE FOR MANY MORE OPTIONS, DESCRIPTIONS, AND EXAMPLES
Nping provides support for multiple target specification. Basically,
everything on the Nping command-line that isn't an option (or an
option argument) is treated as a target host specification. The
simplest case is to specify a single target IP address or a hostname.
Sometimes you wish to ping a whole network of adjacent hosts.
For this, Nping supports CIDR-style
addressing. You can append /<numbits> to an
IPv4 address or hostname and Nping will send probes to every IP
address for which the first numbits are the same as for the
reference IP or hostname given. For example, 192.168.10.0/24 would
send probes to the 256 hosts between 192.168.10.0
11000000 10101000 00001010 00000000)
and 192.168.10.255
(binary: 11000000 10101000 00001010 11111111),
inclusive. 192.168.10.40/24 would ping exactly the same targets.
Given that the host scanme.nmap.org
is at the IP address 64.13.134.52, the specification
scanme.nmap.org/16 would send probes to the 65,536 IP addresses
between 64.13.0.0 and 64.13.255.255. The smallest allowed value is
/0, which targets the whole Internet. The largest value is /32,
which targets just the named host or IP address because all address
bits are fixed.
CIDR notation is short but not always flexible enough. For example,
you might want to send probes to 192.168.0.0/16 but skip any IPs
ending with .0 or .255 because they may be used as subnet network
and broadcast addresses. Nping supports this through octet range
addressing. Rather than specify a normal IP address, you can specify
a comma-separated list of numbers or ranges for each octet. For
example, 192.168.0-255.1-254 will skip all addresses in the range
that end in .0 or .255, and 192.168.3-5,7.1 will target the four
addresses 192.168.3.1, 192.168.4.1, 192.168.5.1, and 192.168.7.1.
Either side of a range may be omitted; the default values are 0 on
the left and 255 on the right. Using
- by itself is the same as 0-255,
but remember to use 0- in the first octet so the target
specification doesn't look like a command-line option. Ranges need
not be limited to the final octets: the specifier will send probes
to all IP addresses on the Internet ending in 13.37 This sort of
broad sampling can be useful for Internet surveys and research.
IPv6 addresses can only be specified by their fully qualified IPv6
address or hostname. CIDR and octet ranges aren't supported for
IPv6 because they are rarely useful. Nping accepts multiple host specifications on the command line,
and they don't need to be the same type. The command
nping scanme.nmap.org
192.168.0.0/8 10.0.0,1,3-7.- does what you would expect.
While targets are usually specified on the command lines, the
following options are also available to control target selection:
-
-iL <inputfilename> (Input from list)
Reads target specifications from
<inputfilename>. Passing a huge
list of hosts is often awkward on the command line, yet it
is a common desire. For example, your DHCP server might
export a list of 10,000 current leases that you wish to
ping. Simply generate the list
of hosts to ping and pass that filename to Nping as an
argument to the -iL option. Entries can be
in any of the formats accepted by Nping on the command line
(IP address, hostname, CIDR, IPv6, or octet ranges). Each
entry must be separated by one or more spaces, tabs, or
newlines. You can specify a hyphen (-)
as the filename if you want Nping to read hosts from standard
input rather than an actual file.
Unlike other ping and packet generation tools, Nping supports
multiple target host and multiple target port specification. While
this provides great flexibility, it is not obvious how Nping handles
situations where there is more than one host and/or more than one
port to send probes to. This section explains how Nping behaves in
these cases.
When multiple target hosts are specified, instead of sending all
probes to one target and then continue with the next one, Nping uses
Round Robin to select the next target host. This gives slow hosts
more time to send their responses before another probe is sent to
them.
Target ports are also scheduled using Round Robin so, unless only one
port is specified, Nping never sends two probes to the same target
host and port consecutively.
Basically it can be seen as if it was implemented using three
nested loops: one that iterates N times, where N is the number of
rounds ( see option --count for details), one that iterates over
the specified ports and one that iterates over the specified
targets. Obviously, if Nping is sending ICMP or ARP packets, there
is no loop that iterates over ports. Also, note that after a probe
has been sent, Nping waits a configurable amount of time called
"inter-probe delay" before sending the next probe (see option
--delay for details). This is how the loops look like:
loop( N rounds ){
loop( port range ){
loop ( specified targets ){
send_probe( current_target, current_port );
wait( inter-probe delay );
}
}
}
The following examples illustrate the described behaviour:
EXAMPLE 1: One target host, three target ports (100-102) and two rounds:
SENT (0.0000s) TCP 192.168.1.77 > 1.1.1.1:100
SENT (1.0000s) TCP 192.168.1.77 > 1.1.1.1:101
SENT (2.0000s) TCP 192.168.1.77 > 1.1.1.1:102
SENT (3.0000s) TCP 192.168.1.77 > 1.1.1.1:100
SENT (4.0000s) TCP 192.168.1.77 > 1.1.1.1:101
SENT (5.0000s) TCP 192.168.1.77 > 1.1.1.1:102
EXAMPLE 2: Three target hosts, one target port (8080), two rounds:
SENT (0.0000s) TCP 192.168.1.77 > 1.1.1.1:8080
SENT (1.0000s) TCP 192.168.1.77 > 2.2.2.2:8080
SENT (2.0000s) TCP 192.168.1.77 > 3.3.3.3:8080
SENT (3.0000s) TCP 192.168.1.77 > 1.1.1.1:8080
SENT (4.0000s) TCP 192.168.1.77 > 2.2.2.2:8080
SENT (5.0000s) TCP 192.168.1.77 > 3.3.3.3:8080
EXAMPLE 2: Three target hosts, three target ports (137-139),
one round, inter-probe delay of 500ms:
SENT (0.0000s) TCP 192.168.1.77 > 1.1.1.1:137
SENT (0.5000s) TCP 192.168.1.77 > 2.2.2.2:137
SENT (1.0000s) TCP 192.168.1.77 > 3.3.3.3:137
SENT (1.5000s) TCP 192.168.1.77 > 1.1.1.1:138
SENT (2.0000s) TCP 192.168.1.77 > 2.2.2.2:138
SENT (2.5000s) TCP 192.168.1.77 > 3.3.3.3:138
SENT (3.0000s) TCP 192.168.1.77 > 1.1.1.1:139
SENT (3.5000s) TCP 192.168.1.77 > 2.2.2.2:139
SENT (4.0000s) TCP 192.168.1.77 > 3.3.3.3:139
Nping supports a wide variety of protocols. . Altough in some cases
Nping can automatically determine the mode from the options used, it
is generally a good idea to specify it explicitly.
-
--tcp-connect (TCP Connect mode)
TCP connect mode is the default mode when a user does not have
raw packet privileges. Instead of writing raw packets as most
other modes do, Nping asks the underlying operating system to
establish a connection with the target machine and port by
issuing the connect() system call. This is the same high-level
system call that web browsers, P2P clients, and most other
network-enabled applications use to establish a connection.
It is part of a programming interface known as the Berkeley
Sockets API. Rather than read raw packet responses off the wire,
Nping uses this API to obtain status information on each
connection attempt. For this reason, you will not be able to
see the contents of the packets that are sent or received but
only status information about the TCP connection establishment
taking place.
-
--tcp (TCP mode)
TCP is the mode that lets users create and send any kind of TCP
packet. TCP packets are sent embedded in IP packets that
can also be tuned. This mode can be used for many different
purposes. For example you could try to discover open ports by
sending TCP-SYN messages without completing the three-way
handshake. This technique is often referred to as half-open
scanning, because you don't open a full TCP connection.
You send a SYN packet, as if you are going to open a real
connection and then wait for a response. A SYN/ACK indicates
the port is open, while a RST indicates it's closed. If no
response is received one could assume that some intermediate
network device is filtering the responses. Another use could be
to see how a remote TCP/IP stack behaves when it receives non
RFC-compliant packets, for example, a packet with both SYN and
RST flags set. One could also do some evil by creating custom
RST packets using an spoofed IP address with the intent of
closing an active TCP connection.
-
--udp (UDP mode)
UDP mode can have two different behaviours. Under normal
circumstances, it lets users create custom IP/UDP packets.
However, if Nping is run by a user without raw packet privileges
and no changes to the default protocol headers are requested,
then Nping enters the UDP-Unprivileged mode which basically sends
UDP packets to the specified target hosts and ports using the
sendto() system call. Note that in this unprivileged mode it is
not possible to see low level header information of the packets
on the wire but only status information about the amount of bytes
that are being transmitted and received.UDP mode can be used to
interact with any UDP based server such as DNS servers,
streamming servers, online gaming servers, Port Knocking/Single
Packet Authorization daemons, etc.
-
--icmp (ICMP mode)
ICMP mode is the default mode when the user runs Nping with
raw packet privileges. It lets the user to create any kind of
ICMP message. By default ICMP Echo messages are sent to the
specified target hosts. ICMP mode can be used for many different
purposes. From a simple request for a timestamp or a netmask to
the transmission of fake Destination Unreachable messages, custom
Redirects, Router Advertisements, etc.
-
--arp (ARP/RARP mode)
ARP lets you create and send a few different ARP-related packets.
These include ARP, RARP, DRARP, and InARP requests and replies.
This mode can ban be used to perform low level host discovery,
conduct ARP-cache poisoning attacks, etc. -
--traceroute (Traceroute mode)
Traceroute is not a mode by itself but a complement to
TCP, UDP and ICMP modes. When this option is specified Nping
will set the IP TTL value of the first probe to 1. When the
next router receives the packet it will drop it due to
the expiration of the TTL and it will generate an ICMP
Destination Unreachable message. The next probe will have a TTL
of 2 so now the first router will forward the packet while the
second router will be the one that drops the packet and
generates the ICMP message. The third probe will have a TTL value
of 3 and so on... By examining the source addresses of all
those ICMP Destination Unreachable messages it is possible to
determine the path that the probes we send are taking until
they reach their final destination.
-
-p <port_spec>;
--dest-port <port_spec> (Target ports)
This option specifies which ports you want to try to connect to.
It can be a single port, a comma-separated list of
ports (e.g. 80,443,8080), a range (e.g. 1-1023), and any combination
of those (e.g. 21-25,80,443,1024-2048). The beginning and/or end values
of a range may be omitted, causing Nping to use 1 and 65535,
respectively. So you can specify -p- to target ports from 1 through
65535. Using port zero is allowed if you specify it explicitly.
-
-g <portnumber>;
--source-port <portnumber> (Spoof source port)
This option specifies which TCP port should be used as source port
in all TCP probes. Specified value must be an integer in the range
[0-65535].
-
-p <port_spec>;
--dest-port <port_spec> (Target ports)
This option specifies which destination ports you want to send
probes to. It can be a single port, a comma-separated list of
ports (e.g. 80,443,8080), a range (e.g. 1-1023), and any combination
of those (e.g. 21-25,80,443,1024-2048). The beginning and/or end values
of a range may be omitted, causing Nping to use 1 and 65535,
respectively. So you can specify -p- to target ports from 1 through
65535. Using port zero is allowed if you specify it explicitly.
-
--seq <seqnumber> (Sequence Number)
Specifies the TCP sequence number. In SYN packets this is the initial
sequence number (ISN). In a normal transmission this corresponds to
the sequence number of the first byte of data in the segment.
<seqnumber> must be a number in the range
[0-4294967295].
-
--flags <flags> (TCP Flags)
This option specifies which flags should be set in the TCP packet.
<flags> may be specified in three different
ways:
1. As a comma-separated list of flags (e.g: --flags syn,ack,rst)
2. As list of flag initials in the format "XYZ..." where each
letter represent the initial that corresponds to the desired flag.
(e.g. "--flags SAR" tells Nping to set flags SYN, ACK and RST.
3. As an 8-bit hexadecimal number, where the supplied number
is the exact value that will be placed in the flags field of the
tcp header. The number should start with the prefix "0x" and should
be in the range [0x00-0xFF]. (e.g. "--flags 0x20" sets the URG flag as
0x20 corresponds to binary 00100000 and the URG flag is represented
by the third most significant bit)
There are 8 possible flags to set: CWR, ECN, URG, ACK, PSH,
RST, SYN, FIN. If "ALL" is specified, then Nping will set all flags.
Alternatively if word "NONE" is supplied, all flags will be set to zero.
It is important that if you don't want any flag to be set you
request it explicitely because in some cases the SYN flag may be
set by default. Here is a brief description of the meaning of each
flag:
CWR: Congestion Window Reduced flag. Set by an ECN-Capable
sender when it reduces its congestion window (due to a
retransmit timeout, a Fast Retransmit or in response to an ECN
Notification).
ECN: During the three-way handshake it indicates that sender
is capable of performing explicit congestion notification.
Normally it means that a packet with the IP Congestion
Experienced flag set was received during normal transmission.
See RFC 3168 for more information. URG: (Urgent) Segment is urgent and the Urgent Pointer field
carries valid information. ACK: (Acknowledgement) The segment carries an aknowledgement and
the value of the Acknowledgement Number field is valid and
contains the next sequence number that is expected from the
receiver. PSH: (Push) The data in this segment should be inmediately
pushed to the application layer on arrival. RST: (Reset) There was some problem and the sender wants to
abort the connection. SYN: (Synchronize) The segment is a request to synchronize
sequence numbers and establish a connection. The Sequence Number
field contains the sender's Initial Sequence Number. FIN: (Finish) The sender wants to close the connection. -
--win <size> (Window Size)
Specifies the TCP window size, this is, the number of octects the
sender of the segment is willing to accept from the receiver at one
time. This is usually the size of the reception buffer that the OS
allocates for a given connection. <size>
must be a number in the range [0-65535]
-
--badsum (Invalid Checksum)
Asks Nping to use an invalid TCP, checksum for packets sent to
target hosts. Since virtually all host IP stacks properly drop these
packets, any responses received are likely coming from a firewall or
an IDS that didn't bother to verify the checksum. For more
details on this technique, see http://nmap.org/p60-12.html
-
--mss <size> (Maximum Segment Size)
Adds a Maximum Segment Size option to the TCP packets, this is, the
size of the largest segment the sender wishes to receive. This is
normally used only in TCP SYN messages.
<size> must be a number in the
range [0-65535].
-
--ws <scale> (Window Scale)
Adds a Window Scale option to the TCP packets, this is, the power of
2 that the Window field should be multiplied by to obtain the actual
sender's window size (e.g. a value of 8 means that the value found in
the Window field should be multiplied by 256).
<scale> must be a number in the range
[0-255].
-
-g <portnumber>;
--source-port <portnumber> (Spoof source port)
This option specifies which UDP port should be used as source port
in all TCP probes. Specified value must be an integer in the range
[0-65535].
-
-p <port_spec>;
--dest-port <port_spec> (Target ports)
This option specifies which destination ports you want to send
probes to. It can be a single port, a comma-separated list of
ports (e.g. 53,69,139), a range (e.g. 1-1023), and any combination
of those (e.g. 137-139,53,194,5222-5269). The beginning and/or end values
of a range may be omitted, causing Nping to use 1 and 65535,
respectively. So you can specify -p- to target ports from 1 through
65535. Using port zero is allowed if you specify it explicitly.
-
--badsum (Invalid Checksum)
Asks Nping to use an invalid UDP, checksum for packets sent to
target hosts. Since virtually all host IP stacks properly drop these
packets, any responses received are likely coming from a firewall or
an IDS that didn't bother to verify the checksum. For more
details on this technique, see http://nmap.org/p60-12.html
-
--icmp-type <type> (ICMP Type)
This option specifies which type of ICMP messages should be
generated. <type> can be supplied in
two different ways. You can use the official number assigned by IANA
(http://www.iana.org/assignments/icmp-parameters)
(e.g. --icmp-type 8 for ICMP Echo Request), or you can use something
easier to remember like one of the following identifiers.
In general you can use the full option name (e.g
destination-unreachable), the 4-3 letters format (e.g. dest-unr)
or the initials (e.g. du). In ICMP types that request something,
the word "request" is ommited. These are the the available
ICMP types:
destination-unreachable; dest-unr; du;
Send Destination Unreachable messages. This message indicates that
a datagram could not be delivered to its destination.
source-quench; sour-que; sq;
Send Source Quench messages. This message is used by a congested
IP device to tell other device that is sending packets too fast
and that it should slow down.
redirect; redi; r;
Send Redirect messages. This message is normally used by routers
to inform a host that there is a better route to use for sending
datagrams.
echo-request; echo; e;
Send Echo Request messages. This message is used to test the
connectivity of another device on a network.
echo-reply; echo-rep; er; Send ICMP echo replies.
Send Echo Reply messages. This message is sent in response to an
Echo Request message.
router-advertisement; rout-adv; ra;
Send Router Advertisement messages. This message is used by
routers to let hosts know of their existence and capabilities.
router-solicitation; rout-sol; rs;
Send Router Solicitation messages. This message is used by hosts
to request Router Advertisement messages from any listening
routers.
time-exceeded; time-exc; te;
Send Time Exceeded messages. This message is generated by some
intermediate device (normally a router) to indicate that a datagram
has been discarded before reaching its destination because the
IP Time To Live expired.
parameter-problem; para-pro; pp;
Send Parameter Problem messages. This message is used when a device
finds a problem with a parameter in an IP header and it cannot
continue processing it.
timestamp; time; tm;
Send Timestamp Request messages. This message is used to request
a device to send a timestamp value for propagation time
calculation and clock synchronization.
timestamp-reply; time-rep; tr;
Send Timestamp Reply messages. This message is sent in response
to a Timestamp Request message.
information; info; i;
Send Information Request messages. This message is now obsolete
but it was originally used to request configuration information
from another device.
information-reply; info-rep; ir;
Send Information Reply messages. This message is now obsolete but
it was originally sent in response to an Information Request
message to provide configuration information.
mask-request; mask; m;
Send Address Mask Request messages. This message is used to
ask a device to send its subnet mask.
mask-reply; mask-rep; mr;
Send Address Mask Reply messages. This message contains a subnet
mask and is sent in response to a Address Mask Request message.
traceroute; trace; tc;
Send Traceroute messages. This message is normally sent
by an intermediate device when it receives an IP datagram
with a traceroute option. ICMP Traceroute messages are still
experimental, see RFC 1393 for more information.
-
--icmp-code <code> (ICMP Code)
This option specifies which ICMP code should should be included in
the generated ICMP messages. <code> can be
supplied in two different ways. You can use the official code numbers
assigned by IANA (http://www.iana.org/assignments/icmp-parameters)
(e.g. --icmp-code 1 to indicate "Fragment Reassembly Time Exceeded"
in ICMP Time Exceeded messages), or you can use something easier to
remember like one of the following identifiers.
CODES FOR DESTINATION UNREACHABLE MESSAGES:
network-unreachable; netw-unr; net;
Datagram could not be delivered to its destination network
(probably due to some routing problem).
host-unreachable; host-unr; host;
Datagram was delivered to the destination network but it was
impossible to reach the specified host (probably due to some
routing problem).
protocol-unreachable; prot-unr; proto;
The protocol specified in the Protocol field of the IP datagram
is not supported by the host to which the datagram was delivered.
port-unreachable; port-unr; port;
The TCP/UDP destination port was invalid.
needs-fragmentation; need-fra; frag;
Datagram had the DF bit set but it was too large for the MTU of
the next physical network so it had to be dropped.
source-route-failed; sour-rou; routefail;
IP datagram had a Source Route option but a router couldn't
pass it to the next hop.
network-unknown; netw-unk; net?;
Destination network is unknown. This code is never used. Instead,
Network Unreachable is used.
host-unknown; host-unk; host?;
Specified host is unknown. Usually generated by a router local to
the destination host to inform of a bad address.
host-isolated; host-iso; isolated;
Source Host Isolated. Not used.
network-prohibited; netw-pro; !net;
Communication with destination network is administratively
prohibited (source device is not allowed to send packets to the
destination network)
host-prohibited; host-pro; !host;
Communication with destination host is administratively
prohibited (source device is allowed to send packets to the
destination network but not to the destination device)
network-tos; unreachable-network-tos; netw-tos; tosnet;
Destination network unreachable because it cannot provide the
type of service specified in the IP TOS field.
host-tos; unreachable-host-tos; toshost;
Destination host unreachable because it cannot provide the
type of service specified in the IP TOS field.
communication-prohibited; comm-pro; !comm;
Datagram could not be forwarded due to filtering that blocks the
message based on its contents
host-precedence-violation; precedence-violation; prec-vio; violation;
Precedence value in the IP TOS field is not permited.
precedence-cutoff; prec-cut; cutoff;
Precedence value in the IP TOS field is lower than the minimum
allowed for the network.
CODES FOR REDIRECT MESSAGES:
redirect-network; redi-net; net;
Redirect all future datagrams with the same destination network
as the original datagram, to the router specified in the Address
field. The use of this code is prohibited by RFC 1812.
redirect-host; redi-host; host;
Redirect all future datagrams with the same destination host
as the original datagram, to the router specified in the Address
field.
redirect-network-tos; redi-ntos; redir-ntos;
Redirect all future datagrams with the same destination network
and IP TOS value as the original datagram, to the router
specified in the Address field. The use of this code is
prohibited by RFC 1812.
redirect-host-tos; redi-htos; redir-htos;
Redirect all future datagrams with the same destination host
and IP TOS value as the original datagram, to the router
specified in the Address field.
CODES FOR ROUTER ADVERTISEMENT MESSAGES:
normal-advertisement; norm-adv; normal; zero; default; def;
Normal router advertisement. In Mobile IP: Mobility agent can
act as a router for IP datagrams not related to mobile nodes.
not-route-common-traffic; not-rou; mobile-ip; !route; !commontraffic;
Used for Mobile IP. The mobility agent does not route common
traffic. All foreign agents must forward to a default router any
datagrams received from a registered mobile node
CODES FOR TIME EXCEEDED MESSAGES:
ttl-exceeded-in-transit; ttl-exc; ttl-transit;
IP Time To Live expired during transit.
fragment-reassembly-time-exceeded; frag-exc; frag-time;
Fragment reassemly time has been exceeded.
CODES FOR PARAMETER PROBLEM MESSAGES:
pointer-indicates-error; poin-ind; pointer;
The pointer field indicates the location of the problem.
missing-required-option; miss-option; option-missing;
IP datagram was expected to have an option that is not present.
bad-length; bad-len; badlen;
The length of the IP datagram is incorrect.
-
--icmp-id <id> (ICMP Identifier)
This option specifies the value of the identifier used in some of
the ICMP messages. In general it is used to match request and
reply messages. <id> must be a number in
the range [0-65535] or [0x0000-0xFFFF].
-
--icmp-seq <seq> (ICMP Sequence)
This option specifies the value of the Sequence Number filed used
in some ICMP messages. In general it is used to match request and
reply messages. <id> must be a number in
the range [0-65535] or [0x0000-0xFFFF].
-
--icmp-redirect-addr <addr> (ICMP Redirect Address)
This option sets the Address field in ICMP Redirect messages. In
other words, it sets the IP address of the router that should be
used when sending IP datagrams to the original destination.
<addr> can be either an IP address in
dot-decimal notation or a hostname.
-
--icmp-param-pointer <pointer> (ICMP Parameter Problem Pointer)
This option specifies the pointer that indicates the location of
the problem in ICMP Parameter Problem messages. <pointer>
should be a number in the range [0-255]. Normally this option is
only used when ICMP code is set to 0 ("Pointer indicates the error").
-
--icmp-advert-lifetime <ttl> (ICMP Router Advertisement Lifetime)
This option specifies the Router Advertisement Lifetime, this is,
the number of seconds the information carried in an ICMP Router
Advertisement can be considered valid for. <ttl>
must be a positive integer in the range [0-65535] or [0x0000-0xFFFF].
-
--icmp-advert-entry <addr>,<pref> (ICMP Router Advertisement Entry)
This option adds a Router Advertisement entry to an ICMP Router
Advertisement message. Parameter should be specified as two
values separated by a comma. <addr> is
the router's IP and can be specified either as an IP address in
dot-decimal notation or as a hostname. <pref>
is the preference level for the specified IP. It must be a number
in the range [0-4294967295] or [0x00000000-0xFFFFFFFF].
(e.g. --icmp-advert-entry 192.168.128.1,3)
-
--icmp-orig-time <timestamp> (ICMP Originate Timestamp)
This option sets the Originate Timestamp in ICMP Timestamp messages.
The Originate Timestamp is expressed as the number of milliseconds
since midnight UTC and it corresponds to the time the sender
last touched the Timestamp message before its transmission.
<timestamp> can be specified as a regular
time (e.g. 10s, 3h, 1000), or using the qualifier
<now>. You can even add or substract
values from the current time (e.g. --icmp-orig-time now-2s,
--icmp-orig-time now+1h, --icmp-orig-time now+200).
-
--icmp-recv-time <timestamp> (ICMP Receive Timestamp)
This option sets the Receive Timestamp in ICMP Timestamp messages.
The Receive Timestamp is expressed as the number of milliseconds
since midnight UTC and it corresponds to the time the echoer
first touched the Timestamp message on receipt.
<timestamp> can be specified as a regular
time (e.g. 10s, 3h, 1000), or using the qualifier
<now>. You can even add or substract
values from the current time (e.g. --icmp-recv-time now-2s,
--icmp-recv-time now+1h, --icmp-recv-time now+200).
-
--icmp-trans-time <timestamp> (ICMP Transmit Timestamp)
This option sets the Transmit Timestamp in ICMP Timestamp messages.
The Transmit Timestamp is expressed as the number of milliseconds
since midnight UTC and it corresponds to the time the echoer
last touched the Timestamp message before its transmission.
<timestamp> can be specified as a regular
time (e.g. 10s, 3h, 1000), or using the qualifier
<now>. You can even add or substract
values from the current time (e.g. --icmp-trans-time now-2s,
--icmp-trans-time now+1h, --icmp-trans-time now+200).
-
--arp-type <type> (ICMP Type)
This option specifies which type of ARP messages should be
generated. <type> can be supplied in
two different ways. You can use the official numbers assigned by IANA
(http://www.iana.org/assignments/arp-parameters/)
(e.g. --arp-type 1 for ARP Request), or you can use something
easier to remember like one of the following identifiers.
arp-request; arp; a;
Send ARP requests. ARP requests are used to translate network layer
addresses (normally IP addresses) to link layer addresses
(usually MAC addresses). Basically, and ARP request is a
broadcasted message that asks the host in the same network
segment that has a given IP address to provide its MAC address.
arp-reply; arp-rep; ar;
Send ARP replies. An ARP reply is a message that a host sends in
response to an ARP request to provide its link layer address.
rarp-request; rarp; r;
Send RARP requests. RARP requests are used to translate a link
layer address (normally a MAC address) to a network layer
address (usually an IP address). Basically a RARP request is
a broadcasted message sent by a host that wants to know his
own IP address because it doesn't have any. It was the first
protocol designed to solve the bootstrapping problem. However,
RARP is now obsolete and DHCP is used instead. For more
information about RARP see RFC 903.
rarp-reply; rarp-rep; rr;
Send RARP replies. A RARP reply is a message sent in response to
a RARP request to provide an IP address to the host that
sent the RARP request in the first place.
drarp-request; drarp; d;
Send Dynamic RARP requests. Dynamic RARP is an extension to RARP
used to obtain or assign a network layer address from a fixed
link layer address. DRARP was used mainly in Sun Microsystems
platforms in the late 90's but now it's no longer used. See
RFC 1931 for more information.
drarp-reply; drarp-rep; dr;
Send Dynamic RARP replies. A DRARP reply is a message sent in
response to a RARP request to provide network layer address.
drarp-error; drarp-err; de;
Send RARP error replies. DRARP Error messages are usually sent
in response to DRARP requests to inform of some error. In
DRARP Error messages, the Target Protocol Address field is used
to carry an error code (usually in the first byte). The error
code is intended to tell why no target protocol address is
being returned. For more information see RFC 1931.
inarp-request; inarp; i;
Send Inverse ARP requests. InARP requests are used to translate
a link layer address to a network layer address. It is similar
to RARP request but in this case, the sender of the InARP
request wants to know the network layer address of another node,
not its own address. InARP is mainly used in Frame Relay and
ATM networks. For more information see RFC 2390
inarp-reply; inarp-rep; ir;
Send Inverse ARP replies. InARP replies are messages sent in
response to InARP requests to provide the network layer address
associated with the host that has a given link layer address.
arp-nak; an;
Send ARP NAK messages. ARP NAK messages are an extension to the
ARMARP protocol and they are used to improve the robustness of
the ATMARP server mechanism. With ARP NAK, a client can
determine the difference between a catastrophic server failure
and an ATMARP table lookup failure. See RFC 1577 for more
information.
-
--arp-sender-mac <mac> (Sender MAC address)
This option sets the Sender Hardware Address field of the ARP header.
Although in theory ARP can support any type of link layer address,
only MAC addresses are supported at the moment.
<mac> must be specified using the
traditional MAC notation (e.g. 00:0a:8a:32:f4:ae). You can also use
hyphens as separators (e.g. 00-0a-8a-32-f4-ae).
-
--arp-sender-ip <addr> (Sender IP address)
This option sets the Sender IP field of the ARP header.
<addr> can be specified either as an IP
address in dot-decimal notation or as a hostname.
-
--arp-target-mac <mac> (target MAC address)
This option sets the Target Hardware Address field of the ARP header.
<mac> must be specified using the
traditional MAC notation (e.g. 00:0a:8a:32:f4:ae). You can also use
hyphens as separators (e.g. 00-0a-8a-32-f4-ae).
-
--arp-target-ip <addr> (target ip address)
This option sets the Target IP field of the ARP header.
<addr> can be specified either as an IP
address in dot-decimal notation or as a hostname.
-
-S <addr>;
--source-ip <addr> (Source IP Address)
Set source IP address. This option lets you specify a custom IP
address to be used as source IP address in sent packets. This
allows spoofing the sender of the packets.
<addr> can be specified either as an IP
address in dot-decimal notation or as a hostname.
-
--dest-ip <addr> (Destination IP Address)
This option is provided for consistency but its use is deprecated
in favor of the usual {target specification}. Please check section
Target Specification for more details.
-
--tos <tos> (Type of Service)
Sets the IP TOS field. The TOS field is used to carry information
to provide quality of service features. It is normally used to
support a technique called Differentiated Services. See RFC 2474 for
more information. <tos> must be a number
in the range [0-255] or [0x00-0xFF].
-
--id <id> (Identification)
Sets the IPv4 Identification field. The Identification field is a
16bit value that is common to all fragments belonging to a particular
message. The value is used by the receiver to reassemble the
original message from the fragments received. <id>
must be a number in the range [0-65535] or [0x0000-0xFFFF].
-
--df (Don't Fragment)
This option sets the Don't Fragment bit in sent packets. When an
IP datagram has its DF flag set, intermediate devices are not
allowed to fragment it so if it needs to travel across a network
with a MTU smaller that datagram length the datagram will have
to be dropped. Normally an ICMP Destination Unreachable message
is generated and sent back to the sender.
-
--md (More Fragments)
This option sets the More Fragments bit in sent packets. The MF
flag is set to indicate the receiver that the current datagram is
a fragment of some larger datagram. When set to zero it indicates
that the current datagram is either the last fragment in the set
or that it is the only fragment.
-
--ttl <hops> (Time To Live)
Sets the IPv4 time-to-live field in sent packets to the given
value. The TTL field specifies how long the datagram is allowed
to exist on the network. It was originally intended to represent
a number of seconds but it actually represents the number of
hops a packet can traverse before being dropped. The TTL tries to
avoid a situation in which undeliverable datagrams keep being
forwarded from one router to another endlessly.
<hops> must be a number in the range [0-255].
-
--badsum-ip (Invalid IP checksum)
Asks Nping to use an invalid IP checksum for packets sent to
target hosts.
-
--ip-options <S|R [route]|L [route]|T|U ...>;
--ip-options <hex string> (IP Options)
The IP protocol offers several options which may be placed in
packet headers. Unlike the ubiquitous TCP options, IP options are
rarely seen due to practicality and security concerns. In fact,
many Internet routers block the most dangerous options such as
source routing. Yet options can still be useful in some cases for
determining and manipulating the network route to target machines.
For example, you may be able to use the record route option to
determine a path to a target even when more traditional
traceroute-style approaches fail. Or if your packets are being
dropped by a certain firewall, you may be able to specify a
different route with the strict or loose source routing options.
The most powerful way to specify IP options is to simply pass in
values as the argument to --ip-options. Precede each hex number
with \x then the two digits. You may repeat certain characters by
following them with an asterisk and then the number of times you
wish them to repeat. For example, \x01\x07\x04\x00*36\x01 is a hex
string containing 36 NUL bytes.
Nmap also offers a shortcut mechanism for specifying options.
Simply pass the letter R, T, or U to request record-route,.
record-timestamp,. or both options together, respectively. Loose
or strict source routing. may be specified with an L or S followed
by a space and then a space-separated list of IP addresses.
For more information and examples of using IP options with Nping,
see http://seclists.org/nmap-dev/2006/q3/0052.html.
-
--mtu <size> (Maximum Transmission Unit)
This option sets a fictional MTU in Nping so IP datagrams larger than
<size> are fragmented before transmission.
<size> must be specified in bytes and
corresponds to the number of octects that can be carried on a
single link layer frame.
-
-6 ;
--IPv6 (Use IPv6)
Tells Nping to use IP version 6 instead of the default IPv4.
It is generally a good idea to specify this option as early as
possible in the command line so Nping can parse it soon and know in
advance that the rest of the parameters refer to IPv6. The command
syntax is the same as usual except that you also add the -6 option.
Of course, you must use IPv6 syntax if you specify an address
rather than a hostname. An address might look like
3ffe:7501:4819:2000:210:f3ff:fe03:14d0, so hostnames are
recommended.
While IPv6 hasn't exactly taken the world by storm, it gets
significant use in some (usually Asian) countries and most modern
operating systems support it. To use Nping with IPv6, both the
source and target of your packets must be configured for IPv6. If your
ISP (like most of them) does not allocate IPv6 addresses to you,
free tunnel brokers are widely available and work fine with Nping.
You can use the free IPv6 tunnel broker service at
http://www.tunnelbroker.net.
Please note that IPv6 support is still highly experimental and
many modes and options may not with with it.
-
-S <addr>;
--source-ip <addr> (Source IP Address)
Set source IP address. This option lets you specify a custom IP
address to be used as source IP address in sent packets. This
allows spoofing the sender of the packets.
<addr> can be specified either as an IP
address in the standard IPv6 notation or as a hostname.
-
--dest-ip <addr> (Destination IP Address)
This option is provided for consistency but its use is deprecated
in favor of the usual {target specification}. Please check section
Target Specification for more details.
-
--flow <label> (Flow Label)
-
--traffic-class <class> (Traffic Class)
-
--hop-limit <hops> (Hop Limit)
Sets the IPv6 Hop Limit field in sent packets to the given
value. The Hop Limit field specifies how long the datagram is allowed
to exist on the network. It represents the number of hops a packet
can traverse before being dropped. As with IPv5 TTL, IPv6 Hop Limit
tries to avoid a situation in which undeliverable datagrams keep being
forwarded from one router to another endlessly.
<hops> must be a number in the range [0-255].
In most cases Nping sends packets at raw IP level. This means that Nping
creates its own IP packets and trasmits them through a raw socket. However,
in some cases it may be necessary to send packets at the raw Ethernet level.
This happens, for example, when Nping is run under Windows (as Microsoft
has disabled raw socket support since Windows XP SP2), or when Nping is
asked to send ARP packets.
Since in some cases it is necessary to construct ethernet frames, Nping
offers some options to manipulate the different fields.
-
--dest-mac <mac> (Ethernet Destination MAC Address)
This option sets the destination MAC address that should be set in
outgoing Ethernet frames. This is useful in case Nping can't
determine the next hop MAC address or when you want to route
probes through a router different than the configured default
gateway. The MAC address should have the usual
colon-separated 6 hex byte format (e.g: 00:50:56:d4:01:98 ).
Alternatively, hyphens may be used intead of colons
(e.g: 00-50-56-c0-00-08). Additionally word "random" sets up a
random MAC address and words "broadcast" and "bcast" set up
address ff:ff:ff:ff:ff:ff. Also, note that if you set up a bogus
destination MAC address your probes may not reach the intended
targets.
-
--source-mac <mac> (Ethernet Source MAC Address)
This option sets the source MAC address that should be set in
outgoing Ethernet frames. This is useful in case Nping can't
determine your network interface MAC address or when you want to
inject traffic into the network hidding your network card's real
address. The syntax is the same as in option --dest-mac. Check above
for details. Note that if you set up a bogus source MAC address
you may not receive probe replies.
-
--ether-type <type> (EtherType)
This option sets the Ethertype field of the Ethernet frame.
The Ethertype is used to indicate which protocol is encapsulated
in the payload. <type> can be supplied in
two different ways. You can use the official numbers listed by the
IEEE (http://standards.ieee.org/regauth/ethertype/eth.txt)
(e.g. --ether-type 0x0800 for IP version 4), or you can use something
easier to remember like one of the following identifiers.
ipv4; ip; 4;
Internet Protocol version 4.
ipv6; 6;
Internet Protocol version 6.
arp;
Address Resolution Protocol.
rarp;
Reverse Address Resolution Protocol.
frame-relay; frelay; fr;
Frame Relay
pptp;
Point-to-Point Protocol.
gsmp;
General Switch Management Protocol.
mpls;
Multiprotocol Label Switching.
mps-ual; mps;
Multiprotocol Label Switching with Upstream-assigned Label.
mcap;
Multicast Channel Allocation Protocol.
pppoe-discovery; pppoe-d;
PPP over Ethernet Discovery Stage.
pppoe-session; pppoe-s;
PP over Ethernet Session Stage.
ctag;
Customer VLAN Tag Type.
epon;
Ethernet Passive Optical Network.
pbnac;
Port-based network access control.
stag;
Service VLAN tag identifier.
ethexp1;
Local Experimental Ethertype 1.
ethexp2;
Local Experimental Ethertype 2.
ethoui;
OUI Extended Ethertype.
preauth;
Pre-Authentication.
lldp;
Link Layer Discovery Protocol.
mac-security; mac-sec; macsec;
Media Access Control Security.
mvrp;
Multiple VLAN Registration Protocol.
mmrp;
Multiple Multicast Registration Protocol.
frrr;
Fast Roaming Remote Request.
Description.
-
--data <hex string> (Append custom binary data to sent packets)
This option lets you include binary data as payload in sent packets.
<hex string> may be specified in any of
the following formats: "0xAABBCCDDEEFF...", "AABBCCDDEEFF..." or
"\xAA\xBB\xCC\xDD\xEE\xFF...". Note that if you specify a number
like 0x00ff no byte order conversion is performed. Make sure you
specify information in the byte order expected by the receiver.
(e.g. --data 0xdeadbeef; --data \xCA\xFE\x09)
-
--data-string <string> (Append custom ASCII string to sent packets)
This option lets you include a regular ASCII string as payload in
sent packets. <string> can
contain any printable string. However, note that some characters
may depend on your system's locale and the receiver may not
see the same information. Also, make sure you enclose the string
in double quotes and scape any special character.
(e.g --data-string "Jimmy Jazz...")
-
--data-file <filename> (Append contents of a file to sent packets)
This option lets you include the contents of a file as payload in
sent packets. <filename> must be a valid
filename (or path to a file) and it should be readable.
-
--data-length <len> (Append random data to sent packets)
This option lets you include <len>
random bytes of data as payload in sent packets.
<len> must be an integer in the range
[0-65400]. However, values higher than 1400 are not recommended
because it may not be possible to transmit packets due to
network MTU limitations.
Timing and Performance Options-
--delay <time> (Delay between probes)
This option lets you control for how long will Nping wait before
sending the next probe. Like many other ping tools, the default
delay is one second, this means that Nping sends one probe
per second. <time> must be a positive
integer. By default it is specified in milliseconds. However, you
can specify it in seconds appending 's', minutes 'm' or hours 'h'
(e.g. 20s, 45m, 2h).
-
--rate <rate> (Send probes at a given rate)
This option specifies the number of probes that Nping should send
per second. It is almost equivalent to --delay because Nping
actually computes a delay from the specified rate doing
delay=1000ms/rate. Note that there is no point on using --delay
and --rate together. If you do so, only the last one in the
parameter list will be used.
-
-h ;
--help (Display help)
This option displays help information to stdout. The output is
supposed to fit on a 80-character-wide terminal.
-
-V ;
--version (Display current version)
This option tells Nping to display its current version number and
quit.
-
-c <rounds>;
--count <rounds> (Stop after a given number of rounds)
This option lets you specify the number of times that Nping should
loop over target hosts (and in some cases target ports). Nping calls
this "rounds". In a basic execution with only one target (and only
one target port in TCP/UDP modes), the number of rounds matches the
number of probes sent to the target host. However, in more complex
executions where Nping is run against multiple targets and multiple
ports, the number of rounds is the number of times that Nping sends
a complete set of probes that covers all target IPs and all
target ports. For example, if Nping is asked to send TCP SYN packets
to hosts 192.168.1.0-255 and ports 80,433, 255*2=510 packets
are sent in one round. So if you specify -c 100, Nping will
loop over the different target hosts and ports 100 times, sending
a total of 255*2*100= 51000 packets. By default Nping runs for
5 rounds.
-
-e <name>;
--interface <name> ( )
This option tells Nping what interface should be used to send and
receive packets. Nping should be able to detect this automatically,
but it will tell you if it cannot. <name>
must be the name of an existing network interface with an assigned
IP address.
-
--privileged (Assume that the user is fully privileged)
Tells Nping to simply assume that it is privileged enough to perform
raw socket sends, packet sniffing, and similar operations that
usually require root privileges. on Unix systems. By default Nping
quits if such operations are requested but geteuid is not zero.
--privileged is useful with Linux kernel capabilities and similar
systems that may be configured to allow unprivileged users to
perform raw-packet transmissions. The NPING_PRIVILEGED
environmental variable may be set as an equivalent alternative to
--privileged.
-
--unprivileged (Assume that the user lacks raw socket privileges)
This option is the opposite of --privileged. It tells Nping to treat
the user as lacking network raw socket and sniffing privileges.
This is useful for testing, debugging, or when the raw network
functionality of your operating system is somehow broken. The
NPING_UNPRIVILEGED environmental variable may be set as an
equivalent alternative to --unprivileged.
-
--send-eth (Use raw ethernet sending)
Asks Nping to send packets at the raw ethernet (data link) layer
rather than the higher IP (network) layer. By default, Nping chooses
the one which is generally best for the platform it is running on.
Raw sockets (IP layer) are generally most efficient for Unix
machines, while ethernet frames are required for Windows operation
since Microsoft disabled raw socket support. N still uses raw IP
packets on Unix despite this option when there is no other choice
(such as non-ethernet connections).
-
--send-ip (Send at raw IP level)
Asks Nping to send packets via raw IP sockets rather than sending
lower level ethernet frames. It is the complement to the --send-eth
option discussed previously.
-
--bpf-filter <filter spec>
--filter <filter spec> (Set custom BPF filter)
This option lets you specify a custom BPF filter. By default Nping
chooses a filter that is intended to capture most common responses
to the particular probes that are sent. For example, when sending
TCP messages, the filter is set to capture packets whose destination
port matches the probe's source port. If for some reason you expect
strange packets in response to sent probes or you just want
to sniff a particular kind of traffic, you can specify a custom
filter using the tradicional tcpdump syntax. Check documentation
in http://www.tcpdump.org/ for more information.
-
-H ;
--hide-sent (Do not display sent packets)
This option tells Nping not to print information about sent packets.
This can be useful when using very short inter-probe delays (e.g.
when doing flooding), because printing information to the standard
output has a computational cost and disabling it can probably
speed things up a bit.
-
-N ;
--no-capture (Do not attempt to capture replies)
This option tells Nping to skip packet capture. This means that
packets in response to sent probes will not be processed or
displayed. This can be useful when doing flooding and network stack
stress tests. Note that when this option is specified, most of
the statistics shown at the end of the execution will be useless.
This option does not work with TCP Connect mode.
Description.
-
-v [<level>] (Increase or set verbosity level) .
Increases the verbosity level, causing Nping to print more
information during its execution. There are 9 levels of verbosity
(-4 to 4). Every instance of -v increments verbosity level by one
(from its default value, level 0). Every instance of option -q
decrements verbosity level by one. Alternatively one can specify
the level along with the -v option (e.g. -v3 or -v-1). These are the
available levels:
Level -4:
No output at all. In some circumstances you may not want
Nping to produce any output (like when one of your work mates is
watching over your shoulder). In that case level 0 can be useful
because although you won't see any response packets, probes will
still be sent.
Level -3:
Like level -4 but displaying fatal error messages so you can
actually see if Nping is running or it failed due to some error.
Level -2:
Like level -3 but also displaying warnings and recoverable errors.
Level -1:
Displays traditional run-time information (version, start time,
statisctics, etc) but does not display sent/received packets.
Level 0:
This is the default verbosity level. It behaves like level -1 but
displaying sent/receive packets and some other important information.
Level 1:
Like level 0 but it displays detailed information about
timing, flags, protocol details, etc. Level 2:
Like level 1 but displaying very detailed information
about sent/recv packets and other interesting information.
Level 3:
Like level 2 but also displaying the raw hexadecimal dump of sent
and received packets.
Level 4:
Currently unused.
-
-q [<level>] (Decrese verbosity level) .
Decreases the verbosity level, causing Nping to print less
information during its execution. As explained above, there are 9
levels of verbosity (-4 to 4). Every instance of -q decrements
verbosity level by one (from its default value, level 0).
Alternatively one can specify how many times should verbosity be
decreased (e.g: -d2 sets verbosity level -2). For a detailed
description of the available levels, check documentation for
option "-v".
-
-d [<level>] (Increase or set debugging level)
When even verbose mode doesn't provide sufficient data for you,
debugging is available to flood you with much more! As with the
verbosity option (-v), debugging is enabled with a command-line
flag (-d) and the debug level can be increased by specifying it
multiple times.. There are 7 debugging levels (0 to 6).
Every instance of -d increments debugging level by one
(from its default value, level 0). Alternatively one can specify
the level along with the -d option (e.g. -d4).
Debugging output is useful when a bug is suspected in Nping, or if
you are simply confused as to what Nping is doing and why. As this
feature is mostly intended for developers, debug lines aren't
always self-explanatory. You may get something like:
"NSOCK (1.0000s) Callback: TIMER SUCCESS for EID 12;
tcpconnect_event_handler(): Received callback of type TIMER with
status SUCCESS". If you don't understand a line, your only
recourses are to ignore it, look it up in the source code, or
request help from the development list (nmap-dev).. Some lines are
self explanatory, but the messages become more obscure as the debug
level is increased.
These are the available levels:
Level 0:
Level 0. No debug information at all. This is the default level.
Level 1:
In this level, only very important or high level debug information
will be printed.
Level 2:
Like level 1 but also displaying important or medium level debug
information
Level 3:
Like level 2 but it displays regular and low level debug information.
Level 4:
Like level 3 but displaying messages only a real Nping freak would
want to see.
Level 5:
Like level 4 but it enables basic debug information related to
external libraries like nsock.
Level 6:
Like level 5 but it enables full, very detailed, debug information
related to external libraries like nsock.
Like its author, Nping isn't perfect. But you can help make
it better by sending bug reports or even writing patches. If Nping
doesn't behave the way you expect, first upgrade to the latest
version available from http://nmap.org. If the problem
persists, do some research to determine whether it has already been
discovered and addressed. Try searching for the error message on our
search page at http://insecure.org/search.html or at Google.
Also try browsing the nmap-dev archives at
http://seclists.org/.
Read this full manual page as
well. If nothing comes of this, mail a bug report to
<nmap-dev@insecure.org>. Please include everything
you have learned about the problem, as well as what version of
Nping you are running and what operating system version it is
running on. Problem reports and Nping usage questions sent to
<nmap-dev@insecure.org> are far more likely to be answered than
those sent to Fyodor directly. If you subscribe to the nmap-dev
list before posting, your message will bypass moderation and get
through more quickly. Subscribe at
http://cgi.insecure.org/mailman/listinfo/nmap-dev. Code patches to fix bugs are even better than bug reports.
Basic instructions for creating patch files with your changes are
available at http://nmap.org/data/HACKING. Patches may
be sent to nmap-dev (recommended) or to any of the
authors listed in the next section directly. |
|
