nping
1
Nping
Nping Reference Guide

# nping

Network packet generation tool / ping utility

          nping

            Probe Mode

            Options

            target specification

## Description

This document describes the very latest version of Nping available from 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 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.

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 . 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.

### A representative Nping execution

    # nping -c 1 --tcp -p 80,433 scanme.nmap.org google.com

    Starting Nping ( http://nmap.org/nping )
    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

## Options Summary

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-usage;

## Target Specification

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 (binary: `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 `0-.-.13.37` 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:

## General Operation

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

## Probe Modes

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.

## TCP Connect Mode

`-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.

## TCP Mode

`-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 acknowledgement 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 immediately 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

## UDP Mode

`-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 Mode

`--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 () (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 omitted. 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 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 () (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, 1000ms), 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+200ms).

`--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, 1000ms), 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+200ms).

`--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, 1000ms), 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+200ms).

## ARP Mode

`--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 () (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 ATMARP 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.

## IPv4 Options

`-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. Note that some systems (like most Linux kernels), may fix the checksum before placing the packet on the wire, so even if Nping shows the incorrect checksum in its ouput, the packets may be transparently corrected by the kernel.

`--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 NULL bytes.

  Note that if you specify a number of bytes that is not a multiple of four, an incorrect IP header length will be set in the IP packet. The reason for this is that the IP header length field is expressed in units of 32-bit words and therefore, there is no way to set the correct length if the options are not padded to 32 bits. In those cases, the length is computed as follows: `ip_hl=(20 + ipopts_len)/4`. This is, the integer division of the total number of header bytes and the 4 bytes that form a 32-bit word, whose fractional part will be truncated. This will affect the way the header that follows the IP header is interpreted, showing bogus information in Nping or in the output of any sniffer. Although this kind of situation might be useful for some stack stress tests, users would normally want to specify explicit padding, so the correct header length is set.

  Nping 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.

## IPv6 Options

`-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 IPv4 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].

## Ethernet Options

In most cases Nping sends packets at raw IP level. This means that Nping creates its own IP packets and transmits 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 () (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.

## Payload Options

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-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 or floating point number. By default it is specified in seconds. However, you can give an explicit unit by appending ms for milliseconds, s for seconds, m for minutes, or h for hours (e.g.`2.5s`, `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.

## Miscellaneous Options

`-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. If a value of 0 is specified, Nping will run for 2^32 rounds.

`-e name`; `--interface name` (Set the network interface to be used)

  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.

## Output Options

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]` (Decrease 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: -q2 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.

## Bugs

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 . 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 or at Google. Also try browsing the nmap-dev archives at
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 .

Code patches to fix bugs are even better than bug reports. Basic instructions for creating patch files with your changes are available at . Patches may be sent to nmap-dev (recommended) or to any of the authors listed in the next section directly.

## Authors

Luis MartinGarcia luis.mgarc@gmail.com ()

Fyodor fyodor@insecure.org ()