diff options
| author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-17 07:42:04 +0000 |
|---|---|---|
| committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-17 07:42:04 +0000 |
| commit | 0d47952611198ef6b1163f366dc03922d20b1475 (patch) | |
| tree | 3d840a3b8c0daef0754707bfb9f5e873b6b1ac13 /nping/docs | |
| parent | Initial commit. (diff) | |
| download | nmap-0d47952611198ef6b1163f366dc03922d20b1475.tar.xz nmap-0d47952611198ef6b1163f366dc03922d20b1475.zip | |
Adding upstream version 7.94+git20230807.3be01efb1+dfsg.upstream/7.94+git20230807.3be01efb1+dfsgupstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'nping/docs')
| -rw-r--r-- | nping/docs/AUTHORS | 16 | ||||
| -rw-r--r-- | nping/docs/EchoProtoRFC.txt | 1158 | ||||
| -rw-r--r-- | nping/docs/leet-nping-ascii-art.txt | 18 | ||||
| -rw-r--r-- | nping/docs/nping-man.xml | 3575 | ||||
| -rw-r--r-- | nping/docs/nping-usage.txt | 120 | ||||
| -rw-r--r-- | nping/docs/nping-usage.xml | 2 | ||||
| -rw-r--r-- | nping/docs/nping.1 | 1797 | ||||
| -rw-r--r-- | nping/docs/npingmanhtml.xml | 13 |
8 files changed, 6699 insertions, 0 deletions
diff --git a/nping/docs/AUTHORS b/nping/docs/AUTHORS new file mode 100644 index 0000000..cef394b --- /dev/null +++ b/nping/docs/AUTHORS @@ -0,0 +1,16 @@ +Nping AUTHORS +=============== + +Nping was originally written from the ground up by Luis MartinGarcia +(luis.mgarc@gmail.com), during the Google Summer of Code program in 2009. Luis +was mentored by Fyodor. + +Further development was done in the Google Summer of Code 2010 by Luis +once again mentored by Fyodor. + +Many helpful comments, suggestions and other useful information were taken from +the dev@nmap.org list as well as other contributors via email. + +Nping shares the Nmap infrastructure libraries (Nsock and Nbase) which were +originally written by Fyodor. + diff --git a/nping/docs/EchoProtoRFC.txt b/nping/docs/EchoProtoRFC.txt new file mode 100644 index 0000000..e819411 --- /dev/null +++ b/nping/docs/EchoProtoRFC.txt @@ -0,0 +1,1158 @@ ++-----------------------------------------------------------------------------+ + + + + + + + NPING ECHO PROTOCOL + + + + + PROTOCOL SPECIFICATION + + Request for Comments + + August 2010 + + + + + + Luis MartinGarcia + (luis.mgarc@gmail.com) + + + + + + ++-----------------------------------------------------------------------------+ + +Status of this document: DRAFT +First version: May 29, 2009. +Last revision date: April 27, 2011. + ++-----------------------------------------------------------------------------+ + + + + PREFACE + +This documents presents the technical specification of the Nping Echo Protocol. + + + + + TABLE OF CONTENTS + +1. INTRODUCTION ..................................................... x + +2. NPING ECHO PROTOCOL SPECIFICATION................................. x + + 2.1 General Message Format......................................... x + 2.2 Field Description.............................................. x + 2.3 Message type codes............................................. x + 2.4 Message NEP_HANDSHAKE_SERVER................................... x + 2.5 Message NEP_HANDSHAKE_CLIENT................................... x + 2.6 Message NEP_HANDSHAKE_FINAL.................................... x + 2.7 Operation NEP_PACKET_SPEC...................................... x + 2.8 Operation NEP_READY............................................ x + 2.9 Operation NEP_ECHO............................................. x + 2.10 Operation NEP_ERROR............................................ x + 2.11 Flow diagrams.................................................. x + 2.12 Security....................................................... x + 2.13 Cryptographic key derivation................................... x + 2.14 Encryption process............................................. x + 2.15 Additional considerations...................................... x + +3. GLOSSARY .......................................................... x + +4. REFERENCES ........................................................ x + + + + + + + + + + + + + +1. INTRODUCTION + + Troubleshooting routing and firewall issues is a common task nowadays. + The scenario is generally that some network traffic should be flowing + but isn't. The causes of problem can range from routing issues to + network firewall to host-based firewalls to all sorts of other strange + things. It is usually the "middle box" problem that is the hardest to + find. + + Suppose there is some host with a TCP service listening that you can't + connect to for an unknown reason. If a Nmap -sS scan doesn't show the + port as open there are a multitude of possible problems. Maybe the SYN + packet never made it because of some firewall in the middle. Maybe the + SYN did make it but the SYN+ACK got dropped on its way back to you. + Maybe the TTL expired in transit but the ICMP message got blocked by + another firewall before making it back to you. Maybe the SYN made it + but some intermediate host forged a reset packet to snipe the connection + before the SYN+ACK made it back to you. + + When things like the above are going on it is often the case that even + nping can't track down the problem alone. One generally has to turn to + Wireshark/tcpdump on one station and nping on the other but sometimes + it may be quite difficult to coordinate, specially when the person at + the remote host does not even know what an IP address is. + + To solve this problem, Nping implements a new mode of operation, called + "Echo mode", which provides a combination of a packet generator and a + remote sniffer. + + The Echo mode is based on a client/server architecture. Both ends run Nping, + one of them in server mode and the other in client mode. The way it works + is: the Nping client performs an initial handshake with the server over some + standard port (creating a side-channel). Then it notifies the server + what packets are about to be sent. The server sets up a liberal BPF + filter that captures those packets, and starts listening. When the server + receives a packet it encapsulates it (including the link layer frame) + into our own protocol packet and sends it back to the nping client. + This would be essentially like running tcpdump on the remote machine + and having it report back the packets you sent to it with Nping. + + By having the side-channel to talk to the server, things like NAT would + become immediately apparent because you'd see your source IP (and + sometimes port) change. Things like "packet shapers" that change TCP + window sizes transparently between hosts would turn up. It would be + easy to tell if the traffic is being dropped in transit and never gets + to the box. It would also be easy to tell if the traffic does make it + to the box but the reply never makes it back to you. + + In general, it would be like sending a postal package to someone and + having them email you a photo of the package when they get it. If you + think your packages are being abused by the parcel service then having + someone on the other end to send information back is a great way to + uncover what is going on. + + + +2. NPING ECHO PROTOCOL SPECIFICATION + + + 2.1 General Message Format + + The following diagram describes the general format of the NEP messages. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Message Type | Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . DATA . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Message Authentication Code . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + There are 7 different kinds of packets: + + NEP_HANDSHAKE_SERVER (S->C) + Informs the client of the highest version it supports and sends + the server's authentication parameters. + + NEP_HANDSHAKE_CLIENT (C->S) + Informs the server of the highest version it supports and sends + the initial authentication parameters. + + NEP_HANDSHAKE_FINAL (S->C) + Echoes server nonce back to the server. + + NEP_PACKET_SPEC: (C->S): + Tells the server what kind of packets we are planning to send. + + NEP_READY: (S->C): + Tells the client that the server is ready to start receiving + packets. + + NEP_ECHO: (S->C): + Contains the packet that the server receives from the client. + + NEP_ERROR: (C->S or S->C): + Indicates an error and terminates the session. + + + + 2.2 Field Description + + Version: 8 bits + Current version of the protocol. This document covers version 0x01. + + + Message type: 8 bits + Integer that indicates the type of packet. It must be one of the + type codes defined in section 2.3. + + + Total Length: 16 bits + Length of the entire packet, measured in 32bit words. Value must + be in NETWORK byte order. + + + Sequence Number: 32 bits + Packet sequence number, relative to the sender. Initially this + field is set to a random value, and then it is incremented by one + for each packet that is sent in a given session. The counter must + wrap back to zero after it reaches (2^32)-1. This field is intended + to provide flow tracking and basic protection against replay + attacks. + + Timestamp: 32 bits + Current time of the sender. This time is expressed as the number + of seconds elapsed since 00:00, 01/01/1970 UTC (epoch time). + + Reserved: 32 bits + Reserved for future use. Reserved fields have been added for two + reasons: to allow future extension of the protocol and to make + the header a multiple of 128 bits needed to satisfy AES encryption + requirements in block size. + + + Data: variable length + Message specific data. + + + Message Authentication Code : 256 bits + Code that provides integrity and authentication to the rest of the + packet. For this, the HMAC-SHA256 suite must be used. The + computation of the code includes the whole plain-text message until + the first byte of the Message Authentication Code field. + + + 2.3 Message type codes + + Message NEP_HANDSHAKE_SERVER: 0x01 + Message NEP_HANDSHAKE_CLIENT: 0x02 + Message NEP_HANDSHAKE_FINAL: 0x03 + Message NEP_PACKET_SPEC: 0x04 + Message NEP_READY: 0x05 + Message NEP_ECHO: 0x06 + Message NEP_ERROR: 0x07 + + + 2.4 Message NEP_HANDSHAKE_SERVER + + The NEP_HANDSHAKE_SERVER message is sent by the server and it requests + client's authentication. The packet informs the client of the latest + version of the protocol that the server supports and provides the + appropriate information for the client authentication process. + + The NEP_HANDSHAKE_SERVER message establishes the following: + + - The identity of the server and that the message was generated + by that server. + - That the message was intended for the client. + - The integrity and originality of the message. + + + The format of the NEP_HANDSHAKE_SERVER message is the following: + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Message Type | Total Length | + 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + 5 +-- --+ + | | + 6 +-- --+ + | | + 7 +-- --+ + | Server Nonce | + 8 +-- --+ + | | + 9 +-- --+ + | | + 10 +-- --+ + | | + 11 +-- --+ + | | + 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + 13 + --+ + | | + 14 +-- Reserved --+ + | | + 15 +-- --+ + | | + 16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . . + . . Message Authentication Code . + + . . . + | | + 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + Server Nonce: 256 bits + Random number. This number must be generated using a + cryptographically secure PRNG and must not be reused. This is + the data that should be used by the client to construct its + cipher block initialization vector. + + Reserved: 120 bits + Reserved for future use. + + HMAC-SHA256: 256 bits + Message authentication code that covers the entire packet, from + byte 0 to the last byte of the last reserved field. The code is + computed over the plaintext, before the encryption is applied to + part of the packet. + + + + 2.5 Message NEP_HANDSHAKE_CLIENT + + + The NEP_HANDSHAKE_CLIENT message is sent by the client and it provides + the appropriate information for client-side authentication. This type + of message is generated only if the previous NEP_HANDSHAKE_CLIENT + message contains a valid message authentication code. + + The NEP_HANDSHAKE_CLIENT message establishes the following: + + - The identity of the client and that reply message has been + generated by the client. + - That the message was intended for the server. + - The integrity and originaltity of the reply. + + + The format of the NEP_HANDSHAKE_CLIENT message is the following: + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Message Type | Total Length | + 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + 5 +-- --+ + | | + 6 +-- --+ + | | + 7 +-- --+ + | Server Nonce | + 8 +-- --+ + | | + 9 +-- --+ + | | + 10 +-- --+ + | | + 11 +-- --+ + | | + 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + 13 +-- --+ + | | + 14 +-- --+ + | | + 15 +-- --+ + | Client Nonce | + 16 +-- --+ + | | + 17 +-- --+ + | | + 18 +-- --+ + | | + 19 +-- --+ + | | + 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ###################### ENCRYPTION STARTS HERE ####################### + 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + 21 +-- --+ + | | + 22 +-- Partner IP address --+ + | | + 23 +-- --+ + | | + 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Version | | + 25 +---------------+ --+ + | | + 26 +-- Reserved --+ + | | + 27 +-- --+ + | | + 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ####################### ENCRYPTION ENDS HERE ####################### + 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . . + . . Message Authentication Code . + . . . + | | + 36 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + Server Nonce: 256 bits + Nonce value received from the server in the previous + NEP_HANDSHAKE_SERVER message. This allows the server to ensure that + the received reply is fresh and was generated as a result of its + NEP_HANDSHAKE_SERVER message. + + Client Nonce: 256 bits + Random number. This number must be generated using a + cryptographically secure PRNG and must not be reused. This is + the data that should be used by the server to construct its + cipher block initialization vector. + + Partner IP address: 128 bits + This is the server's IP address as seen by the client. This field + has 128 bits to allow use of both IPv4 and IPv6 addresses. When + IPv4 is used, only the first four bytes are used. The rest may be + set to zero or filled with random data. + + IP version: 8-bits + Version of the address in the "Partner IP address" field. It should + take one of the following values: + + 0x04 : for IP version 4. + 0x06 : for IP version 6. + + 2.6 Message NEP_HANDSHAKE_FINAL + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Message Type | Total Length | + 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + 5 +-- --+ + | | + 6 +-- --+ + | | + 7 +-- --+ + | Client Nonce | + 8 +-- --+ + | | + 9 +-- --+ + | | + 10 +-- --+ + | | + 11 +-- --+ + | | + 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ###################### ENCRYPTION STARTS HERE ####################### + 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + 13 +-- --+ + | | + 14 +-- Partner IP address --+ + | | + 15 +-- --+ + | | + 16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Version | | + 17 +---------------+ --+ + | | + 18 +-- Reserved --+ + | | + 19 +-- --+ + | | + 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ####################### ENCRYPTION ENDS HERE ######################## + 20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . . + . . Message Authentication Code . + . . . + | | + 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + Client Nonce: 256 bits + Nonce value received from the client in the preceding + NEP_HANDSHAKE_CLIENT message. + + Partner IP address: 128 bits + This is the clients's IP address as seen by the server. This field + has 128 bits to allow use of both IPv4 and IPv6 addresses. When + IPv4 is used, only the first four bytes are used. The rest may be + set to zero or filled with random data. The inclusion of this + information lets the client immediately detect the presence of + some intermediate devices that change his source IP (e.g a NAT box). + This is a modification of the original X.509 three way + authentication protocol, provided, among other things, in order to + make the man-in-the-middle attack described in [1] more difficult. + + IP version: 8 bits + Version of the address in the "Partner IP address" field. It should + take one of the following values: + + 0x04 : for IP version 4. + 0x06 : for IP version 6. + + + 2.7 Operation NEP_PACKET_SPEC + + The NEP_PACKET_SPEC message is sent by the client to tell the server + what kind of packets it should expect. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + ###################### ENCRYPTION STARTS HERE ####################### + 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Message Type | Total Length | + 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP version | Protocol | Packet Count | + 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . | | + . . . + . . PacketSpec . + n . . + | | + 32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ####################### ENCRYPTION ENDS HERE ######################## + 32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . . + . . Message Authentication Code . + . . . + | | + 40 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + IP version: 8 bits + Specifies which is the expected IP version. It must contain one + of the following values: + + 0x04 (IP version 4) + + 0x06 (IP version 6) + + 0xFF (Any version) + + Protocol: 8 bits. + Specifies which kind of packets will be sent to the server. It + must contain one of the following values: + + 0x06 (Protocol TCP) + Tells the server to listen to TCP packets coming from + the client's IP address. + + 0x11 (Protocol UDP) + Tells the server to listen to UDP packets coming from + the client's IP address. + + 0x01 (Protocol ICMP) + Tells the server to listen to ICMP packets coming from + the client's IP address. + + Packet count: 16 bits. + Specifies how many packets will be sent. It must be in NETWORK + byte order. + + PacketSpec: 864 bits. + Tells the server which header fields should be checked to match + a captured packet with the client that sent it. This is necessary + as the server supports multiple user sessions at a time, and needs + a way to distinguish the packets. + + The PacketSpec field consists of a list of protocol fields and + their expected value. Every item on that list has the following + format: + + {Field Code, Field Value} + + Where "Field Code" is an 8-bit numeric identifier of the field (see + definitions below) and "Field Value" is the expected value, that + the server should try to match. The length of "Field Value" depends + on the "Field Code" (see table below for details) and, in general, + it matches the usual length for that field int its original + protocol header. + + Items on the PacketSpec list are specified sequentially. However, + the final length of the list must be 108 bytes, so null bytes must + be added after the last item. + + The following table lists the available field specifiers, their + code and the length of their values. + + ====NAME======== ==CODE== ==LENGTH== + +----------------+--------+----------+ + | IPv4_TOS | 0xA0 | 8 bits | + +----------------+--------+----------+ + | IPv4_ID | 0xA1 | 16 bits | + +----------------+--------+----------+ + | IPv4_FRAGOFF | 0xA2 | 16 bits | + +----------------+--------+----------+ + | IPv4_PROTO | 0xA3 | 8 bits | + +----------------+--------+----------+ + + +----------------+--------+----------+ + | IPv6_TCLASS | 0xB0 | 8 bits | + +----------------+--------+----------+ + | IPv6_FLOW | 0xB1 | 24 bits | + +----------------+--------+----------+ + | IPv6_NHDR | 0xB2 | 8 bits | + +----------------+--------+----------+ + + +----------------+--------+----------+ + | TCP_SPORT | 0xC0 | 16 bits | + +----------------+--------+----------+ + | TCP_DPORT | 0xC1 | 16 bits | + +----------------+--------+----------+ + | TCP_SEQ | 0xC2 | 32 bits | + +----------------+--------+----------+ + | TCP_ACK | 0xC3 | 32 bits | + +----------------+--------+----------+ + | TCP_FLAGS | 0xC4 | 8 bits | + +----------------+--------+----------+ + | TCP_WIN | 0xC5 | 16 bits | + +----------------+--------+----------+ + | TCP_URP | 0xC6 | 16 bits | + +----------------+--------+----------+ + + +----------------+--------+----------+ + | ICMP_TYPE | 0xD0 | 8 bits | + +----------------+--------+----------+ + | ICMP_CODE | 0xD1 | 8 bits | + +----------------+--------+----------+ + + +----------------+--------+----------+ + | UDP_SPORT | 0xE0 | 16 bits | + +----------------+--------+----------+ + | UDP_DPORT | 0xE1 | 16 bits | + +----------------+--------+----------+ + | UDP_LEN | 0xE2 | 16 bits | + +----------------+--------+----------+ + + +----------------+--------+----------+ + | PAYLOAD_MAGIC | 0xFF | Variable | + +----------------+--------+----------+ + + + The PAYLOAD_MAGIC type lets the client specify some magic number + included in the packet's payload. This can be used when all other + specifiers fail (e.g: in IPv4-to-IPv6 tunnels). The length of + its field data is variable and must be specified right after the + field code. Note that the length can never be higher than the + remaining space in the PacketSpec field. If no other field + specifiers are set, "length" can never be higher than 106 bytes. + Servers should carefully check the structure of the PacketSpec + field and close the session established with the sender if it + does not meet the requirements specified in this document. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PAYLOAD_MAGIC | Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + PAYLOAD_MAGIC: 8 bits. + Field code. MUST be set to 0xFF. + + Length: 8 bits. + Length of the data in the "Value" field. MUST be greater + than zero; MUST NOT be greater than the remaining space in + the PacketSpec field and MUST NEVER exceed 106 bytes. + + Value: variable length. + Payload data. Its length must be the one specified in the + "Length" field. It may contain any binary value. Comparisons + at the server side should be made at the bit level so the + encoding should match the one used at the application layer + in the packets that are produced and sent by the client. + + + Here is an example of how a typical specifier list looks like: + + 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4_TOS | 0x00 | IPv4_ID | 0xCA | + 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0xFE | IPv4_PROTO | 0x06 | TCP_SPORT | + 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x4432 | TCP_DPORT | 0x00 | + 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x50 | TCP_FLAGS | 0x08 | TCP_SEQ | + 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x5D33FA6D | + 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x00 | 0x00 | 0x00 | 0x00 | + 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x00 | 0x00 | 0x00 | 0x00 | + 27 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + All packet specifications MUST include the IPv4_ID specifier + (or IPv6_Flow for IPv6) and at least three other fields specifiers. + Additionally, clients MUST NEVER specify the same field specifier + more than once in a NEP_PACKET_SPEC message. Clients that send + messages that do not meet these requirements MUST be rejected by the + server. + + + 2.8 Operation NEP_READY + + The READY packet is sent by the server to indicate the client that + his SPECS packet was accepted and that everything is ready to start + receiving and echoing packets. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + ###################### ENCRYPTION STARTS HERE ####################### + 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Message Type | Total Length | + 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ####################### ENCRYPTION ENDS HERE ######################## + 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . . + . . Message Authentication Code . + . . . + | | + 12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + 2.9 Operation NEP_ECHO + + The NEP_ECHO message is sent by the server and it contains an echoed + network packet. + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + ###################### ENCRYPTION STARTS HERE ####################### + 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Message Type | Total Length | + 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DLT Type | Packet Length | + 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . . Packet . + . . . + . . +-+-+-+-+-+-+-+-+ + | | Padding | + n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ####################### ENCRYPTION ENDS HERE ######################## + n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . . + . . Message Authentication Code . + . . . + | | + n+8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + DLT Type: 16 bits. + Specifies the type of link layer device used in the server side. + Since the server includes link layer frames in echoed packets, + the client needs to know the DLT in order to process link layer + header information. Values used in this field must match DLT types + defined in libpcap and must be transmitted in NETWORK byte order. + Servers may use the special value 0x0000 to indicate that no link + layer header is included. + + Packet Length: 16 bits. + Specifies the length of the echoed packet measured in bytes. + The value stored in this field must be in NETWORK byte order and + must never be greater than 9212, as that is the maximum number of + bytes that can be echoed per packet. + + Packet: variable length. + This corresponds to the packet being echoed. Servers should + store the packet exactly as it was received. No byte order + conversions or any other alteration should be performed. + The whole NEP_ECHO packet must have a length that is a multiple of + 16 bytes, so if (packet_len+4)mod16 is not zero, the packet field + must be padded with NULL bytes. As noted before, the maximum length + for an echoed packet is 9212 bytes. Any packet that exceeds that + length must be truncated. + + + + 2.10 Operation NEP_ERROR + + The NEP_ERROR packet is sent by client or server when an error occurs, + and informs the other end that the sender is terminating the NEP + session and closing the TCP connection. This message includes an error + description string that should explain the reason why the session is + being terminated (e.g. authentication failed, invalid message format). + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + ###################### ENCRYPTION STARTS HERE ####################### + 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Message Type | Total Length | + 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . . Error Message . + . . . + . . . + | | + 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ####################### ENCRYPTION ENDS HERE ######################## + 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . . + . . Message Authentication Code . + . . . + | | + 32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Error Message: 640 bits. + Contains a NULL-terminated ASCII string that describes the reason + why the session is being terminated by the sender. The string MUST + contain a NULL character (0x00) at the end of it. The remaining + bytes, if any, must also be set to zero. + + + 2.11 Flow diagrams + + + The following diagram shows a typical client/server session: + + +------+ +------+ + |CLIENT| |SERVER| + +------+ +------+ + | | + | NEP_HANDSHAKE_SERVER | + |<<---------------------| + | | + | | + | NEP_HANDSHAKE_CLIENT | + |--------------------->>| + | | + | | + | NEP_HANDSHAKE_FINAL | + |<<---------------------| + | | + | | + | | + | NEP_PACKET_SPEC | + |--------------------->>| + | | + | | + | | + | NEP_READY | + |<<---------------------| + | | + | | + | | + | | + | NEP_ECHO | + |<<---------------------| + | | + | NEP_ECHO | + |<<---------------------| + | | + | NEP_ECHO | + |<<---------------------| + | . | + | . | + | . | + | NEP_ECHO | + |<<---------------------| + | | + | | + | | + | TCP Connection Close | + |<<------------------->>| + + + + + + The following diagram represents a session where the client sends an + invalid PacketSpec message. + + + +------+ +------+ + |CLIENT| |SERVER| + +------+ +------+ + | | + | NEP_HANDSHAKE_SERVER | + |<<---------------------| + | | + | | + | NEP_HANDSHAKE_CLIENT | + |--------------------->>| + | | + | | + | NEP_HANDSHAKE_FINAL | + |<<---------------------| + | | + | | + | | + | NEP_PACKET_SPEC | + |--------------------->>| + | | + | | + | NEP_ERROR | + |<<---------------------| + | | + | TCP Connection Close | + |<<------------------->>| + + + The following diagram represents a session where the server fails to + provide a valid NEP_HANDSHAKE_SERVER message. + + +------+ +------+ + |CLIENT| |SERVER| + +------+ +------+ + | | + | NEP_HANDSHAKE_SERVER | + |<<---------------------| + | | + | | + | TCP Connection Close | + |<<------------------->>| + + + + The following diagram represents a session where the client fails to + provide a valid NEP_HANDSHAKE_CLIENT message. + + + +------+ +------+ + |CLIENT| |SERVER| + +------+ +------+ + | | + | NEP_HANDSHAKE_SERVER | + |<<---------------------| + | | + | | + | NEP_HANDSHAKE_CLIENT | + |--------------------->>| + | | + | | + | TCP Connection Close | + |<<------------------->>| + + + + 2.12 Security + + The NEP client/server authentication process is based on the three-way + authentication protocol, described in CITT recommendation X.509 [2]. + However, it has been slightly modified: + + - Messages are not signed using public-key cryptography but a + symmetric encryption key known by both client and server. This + provides the same authentication as the original specification + but it does not provide non-repudiation. + + - Ciphertext is encrypted using the secret key shared by client and + server, instead of using the receiver's public key. + + The cipher suite to be used for data encryption is AES-128. + + When one of the two participating entities receives a fully encrypted + message (any message other than NEP_HANDSHAKE_SERVER, NEP_HANDSHAKE_CLIENT + or NEP_HANDSHAKE_FINAL), it performs the following steps: + + 1. Reads 128 bits and decrypts them. + 2. Checks that version equals 0x01 + 3. Checks that the value in the message type field corresponds to a + valid message type code. + 4. If message type is not one of NEP_HANDSHAKE_CLIENT or + NEP_HANDSHAKE_SERVER, it checks that the received sequence number + matches the last received sequence number from the same sender plus + one. + 5. It checks that the received timestamp is inside a "reasonable" time + window (where "reasonable" is left undefined on purpose, as it may + vary depending on the nature of the implementation or the host + system). + 6. Checks the received total length. For messages whose length is + fixed, it should check whether the received length matches the + expected length of the message. For variable length messages, it + should check that the length is at least, higher than or equal to the + minimum length for that kind of message. + 7. If all tests succeed, then the remaining bits are read + (remaining = TotalLength - 128bits) + 8. Any remaining ciphertext is decrypted. + 9. An alternative message authentication code is computed over the + unencrypted data and matched against the received one. If both codes + match, then the message is considered valid (its integrity has been + verified and its contents are to be trusted), authentic (the creator + of the message is someone who knows the secret) and fresh (the + message is new and has not been replayed). + + + 2.13 Cryptographic key derivation. + + Five cryptographic keys are generated for each client session. All of + them are derived from a single shared secret (a passphrase), known by + client and server. The key derivation process is the following: + + h=SHA256( "passphrase" + NONCES + KEY_TYPE_ID ) + do(1000 times){ + h=SHA256(h); + } + + Where 'h' is a 256bit buffer that holds the final key, 'SHA256' is the + hash computation function for the SHA-256 algorithm, 'NONCES' is the + combination of server's and client's nonce values, exchanged during + handshake, and KEY_TYPE_ID is a string that varies depending on the + type of key being derived. (See below for its definitions). + + As mentioned above, a total of 5 symmetric keys are used. Those keys + are: + + NEP_KEY_MAC_S2C : Key used by the server to sign its messages. + For this type of key, KEY_TYPE_ID="NEPkeyforMACServer2Client" + (unquoted) and NONCES equals the server nonce in the + NEP_HANDSHAKE_SERVER message, concatenated with the client nonce + in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE). + + NEP_KEY_MAC_S2C_INITIAL : Key used by the server to sign its + NEP_HANDSHAKE_SERVER messages. This is a special case key because + it needs to be generated before a client nonce is received (this is + the only key that is not influenced by the client's nonce). For + this type of key, KEY_TYPE_ID="NEPkeyforMACServer2ClientInitial" + (unquoted) and NONCES equals the nonce in the NEP_HANDSHAKE_SERVER + message, concatenated with an empty client nonce, in other words, + a nonce with all its bits set to zero (SERVER_NONCE + ZEROED_NONCE). + + NEP_KEY_MAC_C2S : Key used by the client to sign its messages. + For this type of key, KEY_TYPE_ID="NEPkeyforMACClient2Server" + (unquoted) and NONCES equals the server nonce in the + NEP_HANDSHAKE_SERVER message, concatenated with the client nonce + in the NEP_HANDSHAKE_CLIENT message (SERVER_NONCE + CLIENT_NONCE). + + NEP_KEY_CIPHERTEXT_C2S : Key used by the client to encrypt its + messages. For this type of key, KEY_TYPE_ID= + "NEPkeyforCiphertextClient2Server" (unquoted) and NONCES equals the + server nonce in the NEP_HANDSHAKE_SERVER message, concatenated with + the client nonce in the NEP_HANDSHAKE_CLIENT message + (SERVER_NONCE + CLIENT_NONCE). + + NEP_KEY_CIPHERTEXT_S2C : Key used by the server to encrypt its + messages. For this type of key, KEY_TYPE_ID= + "NEPkeyforCiphertextServer2Client" (unquoted) and NONCES equals the + server nonce in the NEP_HANDSHAKE_SERVER message, concatenated with + the client nonce in the NEP_HANDSHAKE_CLIENT message + (SERVER_NONCE + CLIENT_NONCE). + + When not all 256 bits are required, the last 256-N bits of key material + may be discarded, where N is the desired key length. This is, if less + than 256 of key material is needed, discarded bits must be the least + significant ones. + + 2.14 Encryption process. + + Encryption must be performed using AES-128-CBC. This is, using the AES + encryption algorithm in CBC mode, with 128-bit keys. + + For each party producing encrypted data, the first initialization + vector should be the nonce that this same party generated during the + authentication handshake phase. If the nonce has more bits than needed, + only the necessary number of bits should be used. These bits should be + the most significant ones. + + The initialization vector for subsequent encryption operations should + be the last ciphertext block produced by the same entitiy. This is, to + encrypt the Nth message, the last ciphertext block of the (N-1)th + message should be used as the initialization vector for message N. Same + rule applies for decryption operations, where the initialization vector + should be the last ciphertext block received from the other end. + + + 2.15 Additional considerations. + + - By default, the server side will listen for incoming connections on + TCP port 9929. + + +3. GLOSSARY + + C->S : Indicates that a given message is sent from the client to the server + S->C : Indicates that a given message is sent from the server to the client + NEP : Acronym for Nping Echo Protocol + + +4. REFERENCES + + [1] I'Anson, C. and Mitchell, C. (1990). "Security defects in CCITT + recommendation X.509: the directory authentication framework". ACM + SIGCOMM Computer Communication Review, Volume 20, Issue 2. United + States. + + [2] C.C.I.T.T. (1988). "Recommendation X .509, The Directory - + Authentication Framework" diff --git a/nping/docs/leet-nping-ascii-art.txt b/nping/docs/leet-nping-ascii-art.txt new file mode 100644 index 0000000..1721094 --- /dev/null +++ b/nping/docs/leet-nping-ascii-art.txt @@ -0,0 +1,18 @@ + o + o + o + o o + o o + o o + o o o + o o o + 888b 888 o o o + 8888b 888 o o o + 88888b 888 o o o + 888Y88b 888 o + 888 Y88b888 o + 888 Y88888 + 888 Y8888 + 888 Y888 + + --[NPING]-- diff --git a/nping/docs/nping-man.xml b/nping/docs/nping-man.xml new file mode 100644 index 0000000..d416f72 --- /dev/null +++ b/nping/docs/nping-man.xml @@ -0,0 +1,3575 @@ +<refentry id="npingman"> + <refmeta> + <refentrytitle>nping</refentrytitle> + <manvolnum>1</manvolnum> + <refmiscinfo class="source">Nping</refmiscinfo> + <refmiscinfo class="manual">Nping Reference Guide</refmiscinfo> + </refmeta> + <refnamediv id="nping-man-name"> + <refname>nping</refname> + <refpurpose>Network packet generation tool / ping utility</refpurpose> + </refnamediv> + <!-- body begins here --> + <refsynopsisdiv id="nping-man-synopsis"> + <cmdsynopsis sepchar=" "> + <command>nping</command> + <arg choice="opt" rep="norepeat"> + <replaceable>Options</replaceable> + </arg> + <arg choice="req" rep="norepeat"> + <replaceable>targets</replaceable> + </arg> + </cmdsynopsis> + </refsynopsisdiv> + <refsect1 id="nping-man-description"> + <title>Description</title> + <indexterm><primary>Nping</primary><secondary>description of</secondary></indexterm> + <web> + <note><para>This document describes the very latest version of + Nping available from <ulink url="https://nmap.org/nping"/> Please + ensure you are using the latest version before reporting that a + feature doesn't work as described.</para></note> + </web> + <para>Nping is an open-source tool for network packet generation, + response analysis and response time measurement. Nping allows + users to generate network packets of a wide range of protocols, + letting them 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, and other purposes.</para> + + <para>Additionally, Nping offers a special mode of operation called + the "Echo Mode", that lets users see how the generated probes change + in transit, revealing the differences between the transmitted packets and + the packets received at the other end. See section "Echo Mode" for details. + </para> + + <para>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.</para> +<!-- + <para>Additionally, Nping can provide further information on targets, + including reverse DNS names and MAC addresses.</para> +--> + + <para>A typical Nping execution is shown in <xref linkend="nping-man-ex-repping" xrefstyle="select: label nopage"/>. The only Nping arguments used in + this example are <option>-c</option>, to specify the number of times to + target each host, <option>--tcp</option> to specify TCP Probe Mode, + <option>-p 80,433</option> to specify the target ports; and then the two + target hostnames.</para> + +<example id="nping-man-ex-repping"><title>A representative Nping execution</title> +<indexterm><primary><option>-c</option> (Nping option)</primary><secondary>example of</secondary></indexterm> +<indexterm><primary><option>--tcp</option> (Nping option)</primary><secondary>example of</secondary></indexterm> +<indexterm><primary><option>-p</option> (Nping option)</primary><secondary>example of</secondary></indexterm> +<screen format="linespecific"> +# <userinput>nping -c 1 --tcp -p 80,433 scanme.nmap.org google.com</userinput> + +Starting Nping ( https://nmap.org/nping ) +SENT (0.0120s) TCP 96.16.226.135:50091 > 64.13.134.52:80 S ttl=64 id=52072 iple<continuation/>n=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=4<continuation/>4 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 ipl<continuation/>en=40 seq=1077657388 win=1480 +RCVD (1.1370s) TCP 74.125.45.100:80 > 96.16.226.135:50091 SA ttl=52 id=52913 ip<continuation/>len=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 iple<continuation/>n=40 seq=1077657388 win=1480 +SENT (3.0140s) TCP 96.16.226.135:50091 > 74.125.45.100:433 S ttl=64 id=23624 ip<continuation/>len=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 +</screen> +</example> + +<!-- This para is a bit jumbled together for man page rendering reasons --> +<para>The newest version of Nping can be obtained with Nmap at <ulink url="https://nmap.org"/>. The newest version of this man page +is available at <ulink url="https://nmap.org/book/nping-man.html"/>.</para> +--> + </refsect1> + + <refsect1 id="nping-man-briefoptions"> + <title>Options Summary</title> + + +<para>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.</para> + +<!-- sortas="#" puts it before the entries that start with '-' in the options + section. --> +<indexterm class="startofrange" id="nping-usage-indexterm"><primary sortas="#">summary of options (Nping)</primary></indexterm> +<indexterm class="startofrange" id="nping-usage-nping-indexterm"><primary>command-line options</primary><secondary>of Nping</secondary></indexterm> + +&nping-usage; + +<indexterm class="endofrange" startref="nping-usage-nping-indexterm"/> +<indexterm class="endofrange" startref="nping-usage-indexterm"/> + + </refsect1> + + + <refsect1 id="nping-man-target-specification"> + <title>Target Specification</title> + <indexterm><primary>target specification</primary><secondary>in Nping</secondary></indexterm> + + <para>Everything on the Nping command line that isn't an option or an + option argument is treated as a target host specification. Nping + uses the same syntax for target specifications that Nmap does. The + simplest case is a single target given by IP address or hostname. + </para> + + + <para>Nping supports + CIDR-style<indexterm><primary>CIDR (Classless Inter-Domain Routing)</primary></indexterm> + addressing. You can append <literal>/<replaceable>numbits</replaceable></literal> to an + IPv4 address or hostname and Nping will send probes to every IP + address for which the first <replaceable>numbits</replaceable> are the same as for the + reference IP or hostname given. For example, <literal>192.168.10.0/24</literal> would + send probes to the 256 hosts between 192.168.10.0 + (binary: <literal>11000000 10101000 00001010 00000000</literal>) + and 192.168.10.255 + (binary: <literal>11000000 10101000 00001010 11111111</literal>), + inclusive. <literal>192.168.10.40/24</literal> would ping exactly the same targets. + Given that the host scanme.nmap.org<indexterm><primary>scanme.nmap.org</primary></indexterm> + is at the IP address 64.13.134.52, the specification + <literal>scanme.nmap.org/16</literal> would send probes to the 65,536 IP addresses + between 64.13.0.0 and 64.13.255.255. The smallest allowed value is + <literal>/0</literal>, which targets the whole Internet. The largest value is <literal>/32</literal>, + which targets just the named host or IP address because all address + bits are fixed. + </para> + + <indexterm><primary>address ranges</primary></indexterm> + <para>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, <literal>192.168.0-255.1-254</literal> will skip all addresses in the range + that end in .0 or .255, and <literal>192.168.3-5,7.1</literal> 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 + <literal>-</literal> by itself is the same as <literal>0-255</literal>, + but remember to use <literal>0-</literal> 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 <literal>0-.-.13.37</literal> 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. + </para> + + <para>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.</para> + + <para>Nping accepts multiple host specifications on the command line, + and they don't need to be the same type. The command + <command>nping scanme.nmap.org + 192.168.0.0/8 10.0.0,1,3-7.-</command> does what you would expect. + </para> + + </refsect1> + + + <refsect1 id="nping-man-option-specification"> + <title>Option Specification</title> + + <para> + Nping is designed to be very flexible and fit a wide variety of needs. + As with most command-line tools, its behavior can be adjusted using + command-line options. These general principles apply to option + arguments, unless stated otherwise. + </para> + + <para> + Options that take integer numbers can accept values specified in + decimal, octal or hexadecimal base. When a number starts with <literal>0x</literal>, + it will be treated as hexadecimal; when it simply starts with <literal>0</literal>, it + will be treated as octal. Otherwise, Nping will assume the number has + been specified in base 10. Virtually all numbers that can be supplied + from the command line are unsigned so, as a general rule, the minimum + value is zero. Users may also specify the word <literal>random</literal> or <literal>rand</literal> to + make Nping generate a random value within the expected range. + </para> + + <para> + IP addresses may be given as IPv4 addresses (e.g. + <literal>192.168.1.1</literal>), IPv6 addresses (e.g. + <literal>2001:db8:85a3::8e4c:760:7146</literal>), or hostnames, which + will be resolved using the default DNS server configured in the host + system. + </para> + + <para> + Options that take MAC addresses accept the usual colon-separated 6 hex + byte format (e.g. <literal>00:50:56:d4:01:98</literal>). Hyphens may also be used instead + of colons (e.g. <literal>00-50-56-c0-00-08</literal>). The special + word <literal>random</literal> or <literal>rand</literal> sets a random + address and the word <literal>broadcast</literal> + or <literal>bcast</literal> sets ff:ff:ff:ff:ff:ff. + </para> + + </refsect1> + + + <refsect1 id="nping-man-general-operation"> + <title>General Operation</title> + <indexterm><primary>general operation</primary></indexterm> + + <para>Unlike other ping and packet generation tools, Nping supports + multiple target host and port specifications. 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. + </para> + + <para> + When multiple target hosts are specified, Nping rotates among them + in round-robin fashion. This gives slow hosts more time to send + their responses before another probe is sent to them. 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. + </para> + + <para> + The loop around targets is the <quote>inner loop</quote> and the + loop around ports is the <quote>outer loop</quote>. All targets + will be sent a probe for a given port before moving on to the next + port. Between probes, Nping waits a configurable amount of time + called the <quote>inter-probe delay</quote>, which is controlled by + the <option>--delay</option> option. These examples show how it + works. + </para> + + <variablelist> + <varlistentry> + <term> + <para>One target, three ports, and two rounds.</para> + </term> + <listitem> +<screen> +# <userinput>nping --tcp -c 2 1.1.1.1 -p 100-102</userinput> + +Starting Nping ( https://nmap.org/nping ) +SENT (0.0210s) TCP 192.168.1.77 > 1.1.1.1:100 +SENT (1.0230s) TCP 192.168.1.77 > 1.1.1.1:101 +SENT (2.0250s) TCP 192.168.1.77 > 1.1.1.1:102 +SENT (3.0280s) TCP 192.168.1.77 > 1.1.1.1:100 +SENT (4.0300s) TCP 192.168.1.77 > 1.1.1.1:101 +SENT (5.0320s) TCP 192.168.1.77 > 1.1.1.1:102 +</screen> + </listitem> + </varlistentry> + <varlistentry> + <term> + <para>Three targets, one port, and two rounds.</para> + </term> + <listitem> +<screen> +# <userinput>nping --tcp -c 2 1.1.1.1 2.2.2.2 3.3.3.3 -p 8080</userinput> + +Starting Nping ( https://nmap.org/nping ) +SENT (0.0230s) TCP 192.168.0.21 > 1.1.1.1:8080 +SENT (1.0240s) TCP 192.168.0.21 > 2.2.2.2:8080 +SENT (2.0260s) TCP 192.168.0.21 > 3.3.3.3:8080 +SENT (3.0270s) TCP 192.168.0.21 > 1.1.1.1:8080 +SENT (4.0290s) TCP 192.168.0.21 > 2.2.2.2:8080 +SENT (5.0310s) TCP 192.168.0.21 > 3.3.3.3:8080 +</screen> + </listitem> + </varlistentry> + <varlistentry> + <term> + <para>Three hosts, three ports, one round, inter-probe delay of 500 ms.</para> + </term> + <listitem> +<screen> +# <userinput>nping --tcp -c 1 --delay 500ms 1.1.1.1 2.2.2.2 3.3.3.3 -p 137-139</userinput> + +Starting Nping ( https://nmap.org/nping ) +SENT (0.0230s) TCP 192.168.0.21 > 1.1.1.1:137 +SENT (0.5250s) TCP 192.168.0.21 > 2.2.2.2:137 +SENT (1.0250s) TCP 192.168.0.21 > 3.3.3.3:137 +SENT (1.5280s) TCP 192.168.0.21 > 1.1.1.1:138 +SENT (2.0280s) TCP 192.168.0.21 > 2.2.2.2:138 +SENT (2.5310s) TCP 192.168.0.21 > 3.3.3.3:138 +SENT (3.0300s) TCP 192.168.0.21 > 1.1.1.1:139 +SENT (3.5330s) TCP 192.168.0.21 > 2.2.2.2:139 +SENT (4.0330s) TCP 192.168.0.21 > 3.3.3.3:139 +</screen> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + + <refsect1 id="nping-man-probe-modes"> + <title>Probe Modes</title> + <indexterm class="startofrange" id="nping-man-probe-modes-indexterm"><primary>probe modes</primary></indexterm> + + <para>Nping supports a wide variety of protocols. Although in some cases + Nping can automatically determine the mode from the options used, it + is generally a good idea to specify it explicitly. + </para> + + <variablelist> + + <varlistentry> + <term> + <option>--tcp-connect</option> (TCP Connect mode) + <indexterm><primary><option>--tcp-connect</option> (Nping option)</primary></indexterm> + <indexterm><primary>TCP connect</primary><secondary>in Nping</secondary></indexterm> + <indexterm><primary>TCP connect</primary><seealso>connect scan</seealso></indexterm> + </term> + <listitem> + <para>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 <literal>connect</literal> 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. + </para> + + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--tcp</option> (TCP mode) + <indexterm><primary><option>--tcp</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para>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 a + non-RFC-compliant packet, like one 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. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--udp</option> (UDP mode) + <indexterm><primary><option>--udp</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para>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 unprivileged UDP mode which basically sends + UDP packets to the specified target hosts and ports using the + <literal>sendto</literal> 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. Examples are DNS servers, + streaming servers, online gaming servers, and + port knocking/single-packet<indexterm><primary>port knocking</primary></indexterm> + authorization daemons. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--icmp</option> (ICMP mode) + <indexterm><primary><option>--icmp</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para>ICMP mode is the default mode when the user runs Nping with + raw packet privileges. Any kind of ICMP message can be created. + The default ICMP type is Echo, i.e., ping. 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, and router + advertisements. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--arp</option> (ARP/RARP mode) + <indexterm><primary><option>--arp</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para>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, + and conduct ARP-cache poisoning attacks.</para> + </listitem> + </varlistentry> + + + + <varlistentry> + <term> + <option>--traceroute</option> (Traceroute mode) + <indexterm><primary><option>--tcp-connect</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para>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 take until they reach their + final destination. + </para> + + </listitem> + </varlistentry> + + </variablelist> + <indexterm class="endofrange" startref="nping-man-probe-modes-indexterm"/> + </refsect1> + + + +<!-- TCP CONNECT MODE ****************************************************** --> + <refsect1 id="nping-man-tcp-connect-mode"> + <title>TCP Connect Mode</title> + + <variablelist> + + <varlistentry> + <term> + <option>-p <replaceable>port_spec</replaceable></option>, + <option>--dest-port <replaceable>port_spec</replaceable></option> (Target ports) + <indexterm significance="preferred"><primary><option>--dest-port</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-p</option> (Nping option)</primary><see><option>--dest-port</option></see></indexterm> + </term> + <listitem> + <para> + 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. <literal>80,443,8080</literal>), a range + (e.g. <literal>1-1023</literal>), and any combination + of those (e.g. <literal>21-25,80,443,1024-2048</literal>). + The beginning and/or end values + of a range may be omitted, causing Nping to use 1 and 65535, + respectively. So you can specify <literal>-p-</literal> to target ports from 1 through + 65535. Using port zero is allowed if you specify it explicitly. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>-g <replaceable>portnumber</replaceable></option>, + <option>--source-port <replaceable>portnumber</replaceable></option> (Spoof source port) + <indexterm significance="preferred"><primary><option>--source-port</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-g</option> (Nping option)</primary><see><option>--source-port</option></see></indexterm> + </term> + <listitem> + <para> + This option asks Nping to use the specified port as source port for + the TCP connections. Note that this might not work on all systems or + may require root privileges. Specified value must be an integer in + the range [0–65535]. + </para> + </listitem> + </varlistentry> + + + </variablelist> + </refsect1> + + + + +<!-- TCP MODE ************************************************************** --> + <refsect1 id="nping-man-tcp-mode"> + <title>TCP Mode</title> + + <variablelist> + + + <varlistentry> + <term> + <option>-p <replaceable>port_spec</replaceable></option>, + <option>--dest-port <replaceable>port_spec</replaceable></option> (Target ports) + </term> + <listitem> + <para> + 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. <literal>80,443,8080</literal>), a range + (e.g. <literal>1-1023</literal>), and any combination + of those (e.g. <literal>21-25,80,443,1024-2048</literal>). + The beginning and/or end values + of a range may be omitted, causing Nping to use 1 and 65535, + respectively. So you can specify <literal>-p-</literal> to target ports from 1 through + 65535. Using port zero is allowed if you specify it explicitly. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>-g <replaceable>portnumber</replaceable></option>, + <option>--source-port <replaceable>portnumber</replaceable></option> (Spoof source port) + </term> + <listitem> + <para> + This option asks Nping to use the specified port as source port for + the TCP connections. Note that this might not work on all systems or + may require root privileges. Specified value must be an integer in + the range [0–65535]. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--seq <replaceable>seqnumber</replaceable></option> (Sequence Number) + <indexterm significance="preferred"><primary><option>--seq</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. + <replaceable>seqnumber</replaceable> must be a number in the range + [0–4294967295]. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--flags <replaceable>flags</replaceable></option> (TCP Flags) + <indexterm significance="preferred"><primary><option>--flags</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option specifies which flags should be set in the TCP packet. + <replaceable>flags</replaceable> may be specified in three different + ways: + </para> + + <orderedlist spacing="compact"> + <listitem> + <para>As a comma-separated list of flags, e.g. <option>--flags syn,ack,rst</option></para> + </listitem> + <listitem> + <para>As a list of one-character flag initials, e.g. <option>--flags SAR</option> tells Nping to set flags SYN, ACK, and RST.</para> + </listitem> + <listitem> + <para>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 + <literal>0x</literal> and should be in the range + [0x00–0xFF], e.g. <literal>--flags 0x20</literal> sets the + URG flag as 0x20 corresponds to binary 00100000 and the URG flag + is represented by the third bit.</para> + </listitem> + </orderedlist> + + <para> + There are 8 possible flags to set: + <literal>CWR</literal>, + <literal>ECN</literal>, + <literal>URG</literal>, + <literal>ACK</literal>, + <literal>PSH</literal>, + <literal>RST</literal>, + <literal>SYN</literal>, and + <literal>FIN</literal>. + The special value <literal>ALL</literal> means to set all flags. + <literal>NONE</literal> means to set no flags. It is important that + if you don't want any flag to be set, you request it explicitly + because in some cases the SYN flag may be set by default. Here is a + brief description of the meaning of each flag: + </para> + + <variablelist> + <varlistentry> + <term> + CWR (Congestion Window Reduced) + <indexterm><primary>CWR (TCP flag)</primary></indexterm> + </term> + <listitem> + <para> + 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. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + ECN (Explicit Congestion Notification) + <indexterm><primary>ECN (TCP flag)</primary></indexterm> + </term> + <listitem> + <para> + 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<indexterm><primary>RFC 3168</primary></indexterm> + for more information. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + URG (Urgent) + <indexterm><primary>URG (TCP flag)</primary></indexterm> + </term> + <listitem> + <para> + Segment is urgent and the urgent pointer field + carries valid information. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + ACK (Acknowledgement) + <indexterm><primary>ACK (TCP flag)</primary></indexterm> + </term> + <listitem> + <para> + 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. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + PSH (Push) + <indexterm><primary>PSH (TCP flag)</primary></indexterm> + </term> + <listitem> + <para> + The data in this segment should be immediately + pushed to the application layer on arrival. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + RST (Reset) + <indexterm><primary>RST (TCP flag)</primary></indexterm> + </term> + <listitem> + <para> + There was some problem and the sender wants to + abort the connection. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + SYN (Synchronize) + <indexterm><primary>SYN (TCP flag)</primary></indexterm> + </term> + <listitem> + <para> + The segment is a request to synchronize + sequence numbers and establish a connection. The sequence + number field contains the sender's initial sequence + number. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term> + FIN (Finish) + <indexterm><primary>FIN (TCP flag)</primary></indexterm> + </term> + <listitem> + <para> + The sender wants to close the connection. + </para> + </listitem> + </varlistentry> + </variablelist> + + </listitem> + </varlistentry> + + + + + <varlistentry> + <term> + <option>--win <replaceable>size</replaceable></option> (Window Size) + <indexterm significance="preferred"><primary><option>--win</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Specifies the TCP window size, this is, the number of octets 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. <replaceable>size</replaceable> + must be a number in the range [0–65535]. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--badsum</option> (Invalid Checksum) + <indexterm significance="preferred"><primary><option>--badsum</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Asks Nping to use an invalid TCP checksum for the 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 + <ulink url="https://nmap.org/p60-12.html"/>. + </para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + + + +<!-- UDP MODE ************************************************************** --> + <refsect1 id="nping-man-udp-mode"> + <title>UDP Mode</title> + + + <variablelist> + + <varlistentry> + <term> + <option>-p <replaceable>port_spec</replaceable></option>, + <option>--dest-port <replaceable>port_spec</replaceable></option> (Target ports) + <indexterm significance="preferred"><primary><option>--dest-port</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option specifies which ports you want UDP datagrams to be sent to. + It can be a single port, a comma-separated list of + ports (e.g. <literal>80,443,8080</literal>), a range + (e.g. <literal>1-1023</literal>), and any combination + of those (e.g. <literal>21-25,80,443,1024-2048</literal>). + The beginning and/or end values + of a range may be omitted, causing Nping to use 1 and 65535, + respectively. So you can specify <literal>-p-</literal> to target ports from 1 through + 65535. Using port zero is allowed if you specify it explicitly. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>-g <replaceable>portnumber</replaceable></option>, + <option>--source-port <replaceable>portnumber</replaceable></option> (Spoof source port) + <indexterm significance="preferred"><primary><option>--source-port</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option asks Nping to use the specified port as source port for + the transmitted datagrams. Note that this might not work on all systems or + may require root privileges. Specified value must be an integer in + the range [0–65535]. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--badsum</option> (Invalid Checksum) + </term> + <listitem> + <para> + Asks Nping to use an invalid UDP checksum for the 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 + <ulink url="https://nmap.org/p60-12.html"/>. + </para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + + + +<!-- ICMP MODE ************************************************************* --> + <refsect1 id="nping-man-icmp-mode"> + <title>ICMP Mode</title> + + + <variablelist> + + <varlistentry> + <term> + <option>--icmp-type <replaceable>type</replaceable></option> (ICMP type) + <indexterm significance="preferred"><primary><option>--icmp-type</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option specifies which type of ICMP messages should be + generated. <replaceable>type</replaceable> can be supplied in + two different ways. You can use the + <ulink url="http://www.iana.org/assignments/icmp-parameters">official type numbers assigned by IANA</ulink> + (e.g. <option>--icmp-type 8</option> for ICMP Echo Request), or you + can use any of the mnemonics listed in + <xref linkend="nping-man-icmp-types"/>. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--icmp-code <replaceable>code</replaceable></option> (ICMP code) + <indexterm significance="preferred"><primary><option>--icmp-code</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option specifies which ICMP code should be included in + the generated ICMP messages. <replaceable>code</replaceable> can be + supplied in two different ways. You can use the + <ulink url="http://www.iana.org/assignments/icmp-parameters">official code numbers assigned by IANA</ulink> + (e.g. <option>--icmp-code 1</option> for Fragment Reassembly Time + Exceeded), or you can use any of the mnemonics listed in + <xref linkend="nping-man-icmp-codes"/>. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--icmp-id <replaceable>id</replaceable></option> (ICMP identifier) + <indexterm significance="preferred"><primary><option>--icmp-id</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. <replaceable>id</replaceable> must be a number in + the range [0–65535]. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--icmp-seq <replaceable>seq</replaceable></option> (ICMP sequence) + <indexterm significance="preferred"><primary><option>--icmp-seq</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option specifies the value of the sequence number field used + in some ICMP messages. In general it is used to match request and + reply messages. <replaceable>id</replaceable> must be a number in + the range [0–65535]. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--icmp-redirect-addr <replaceable>addr</replaceable></option> (ICMP Redirect address) + <indexterm significance="preferred"><primary><option>--icmp-redirect-addr</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. + <replaceable>addr</replaceable> can be either an IPv4 address + or a hostname. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--icmp-param-pointer <replaceable>pointer</replaceable></option> (ICMP Parameter Problem pointer) + <indexterm significance="preferred"><primary><option>--icmp-param-pointer</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option specifies the pointer that indicates the location of + the problem in ICMP Parameter Problem messages. <replaceable>pointer</replaceable> + 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"). + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--icmp-advert-lifetime <replaceable>ttl</replaceable></option> (ICMP Router Advertisement Lifetime) + <indexterm significance="preferred"><primary><option>--icmp-advert-lifetime</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. <replaceable>ttl</replaceable> + must be a positive integer in the range [0–65535]. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--icmp-advert-entry <replaceable>addr</replaceable>,<replaceable>pref</replaceable></option> (ICMP Router Advertisement Entry) + <indexterm significance="preferred"><primary><option>--icmp-advert-entry</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option adds a Router Advertisement entry to an ICMP Router + Advertisement message. The parameter must be two + values separated by a comma. <replaceable>addr</replaceable> is + the router's IP and can be specified either as an IP address in + dot-decimal notation or as a hostname. <replaceable>pref</replaceable> + is the preference level for the specified IP. It must be a number + in the range [0–4294967295]. An example is + <option>--icmp-advert-entry 192.168.128.1,3</option>. + </para> + </listitem> + </varlistentry> + + + + <varlistentry> + <term> + <option>--icmp-orig-time <replaceable>timestamp</replaceable></option> (ICMP Originate Timestamp) + <indexterm significance="preferred"><primary><option>--icmp-orig-time</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. + <replaceable>timestamp</replaceable> can be specified as a regular + time (e.g. <literal>10s</literal>, <literal>3h</literal>, <literal>1000ms</literal>), or the special string + <literal>now</literal>. You can add or subtract + values from <literal>now</literal>, for example + <option>--icmp-orig-time now-2s</option>, + <option>--icmp-orig-time now+1h</option>, + <option>--icmp-orig-time now+200ms</option>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--icmp-recv-time <replaceable>timestamp</replaceable></option> (ICMP Receive Timestamp) + <indexterm significance="preferred"><primary><option>--icmp-recv-time</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. + <replaceable>timestamp</replaceable> is as with + <option>--icmp-orig-time</option>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--icmp-trans-time <replaceable>timestamp</replaceable></option> (ICMP Transmit Timestamp) + <indexterm significance="preferred"><primary><option>--icmp-trans-time</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. + <replaceable>timestamp</replaceable> is as with + <option>--icmp-orig-time</option>. + </para> + </listitem> + </varlistentry> + + </variablelist> + + <refsect2 id="nping-man-icmp-types"> + <indexterm class="startofrange" id="nping-man-icmp-types-indexterm"><primary>ICMP types</primary><secondary>mnemonics of, in Nping</secondary></indexterm> + <title>ICMP Types</title> + + <para> + These identifiers may be used as mnemonics for the ICMP type numbers given + to the + <option>--icmp-type</option><indexterm><primary><option>--icmp-type</option> (Nping option)</primary></indexterm> + option. In general there are three forms of each identifier: the full name + (e.g. <literal>destination-unreachable</literal>), the short name (e.g. + <literal>dest-unr</literal>), or the initials (e.g. <literal>du</literal>). + In ICMP types that request something, the word "request" is omitted. + </para> + + <variablelist> + <varlistentry> + <term><literal>echo-reply</literal></term> + <term><literal>echo-rep</literal></term> + <term><literal>er</literal></term> + <listitem> + <para> + Echo Reply (type 0). This message is sent in response to an Echo + Request message. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>destination-unreachable</literal></term> + <term><literal>dest-unr</literal></term> + <term><literal>du</literal></term> + <listitem> + <para> + Destination Unreachable (type 3). This message indicates that + a datagram could not be delivered to its destination. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>source-quench</literal></term> + <term><literal>sour-que</literal></term> + <term><literal>sq</literal></term> + <listitem> + <para> + Source Quench (type 4). 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. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>redirect</literal></term> + <term><literal>redi</literal></term> + <term><literal>r</literal></term> + <listitem> + <para> + Redirect (type 5). This message is normally used by routers + to inform a host that there is a better route to use for sending + datagrams. See also the <option>--icmp-redirect-addr</option> + option. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>echo-request</literal></term> + <term><literal>echo</literal></term> + <term><literal>e</literal></term> + <listitem> + <para> + Echo Request (type 8). This message is used to test the + connectivity of another device on a network. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>router-advertisement</literal></term> + <term><literal>rout-adv</literal></term> + <term><literal>ra</literal></term> + <listitem> + <para> + Router Advertisement (type 9). This message is used by + routers to let hosts know of their existence and capabilities. See + also the <option>--icmp-advert-lifetime</option> option. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>router-solicitation</literal></term> + <term><literal>rout-sol</literal></term> + <term><literal>rs</literal></term> + <listitem> + <para> + Router Solicitation (type 10). This message is used by hosts + to request Router Advertisement messages from any listening + routers. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>time-exceeded</literal></term> + <term><literal>time-exc</literal></term> + <term><literal>te</literal></term> + <listitem> + <para> + Time Exceeded (type 11). 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 TTL expired. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>parameter-problem</literal></term> + <term><literal>member-pro</literal></term> + <term><literal>pp</literal></term> + <listitem> + <para> + Parameter Problem (type 12). This message is used when a device + finds a problem with a parameter in an IP header and it cannot + continue processing it. See also the + <option>--icmp-param-pointer</option> option. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>timestamp</literal></term> + <term><literal>time</literal></term> + <term><literal>tm</literal></term> + <listitem> + <para> + Timestamp Request (type 13). This message is used to request + a device to send a timestamp value for propagation time + calculation and clock synchronization. See also the + <option>--icmp-orig-time</option>, + <option>--icmp-recv-time</option>, and + <option>--icmp-trans-time</option>. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>timestamp-reply</literal></term> + <term><literal>time-rep</literal></term> + <term><literal>tr</literal></term> + <listitem> + <para> + Timestamp Reply (type 14). This message is sent in response + to a Timestamp Request message. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>information</literal></term> + <term><literal>info</literal></term> + <term><literal>i</literal></term> + <listitem> + <para> + Information Request (type 15). This message is now obsolete + but it was originally used to request configuration information + from another device. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>information-reply</literal></term> + <term><literal>info-rep</literal></term> + <term><literal>ir</literal></term> + <listitem> + <para> + Information Reply (type 16). This message is now obsolete but + it was originally sent in response to an Information Request + message to provide configuration information. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>mask-request</literal></term> + <term><literal>mask</literal></term> + <term><literal>m</literal></term> + <listitem> + <para> + Address Mask Request (type 17). This message is used to + ask a device to send its subnet mask. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>mask-reply</literal></term> + <term><literal>mask-rep</literal></term> + <term><literal>mr</literal></term> + <listitem> + <para> + Address Mask Reply (type 18). This message contains a subnet + mask and is sent in response to a Address Mask Request message. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>traceroute</literal></term> + <term><literal>trace</literal></term> + <term><literal>tc</literal></term> + <listitem> + <para> + Traceroute (type 30). 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<indexterm><primary>RFC 1393</primary></indexterm> + for more information. + </para> + </listitem> + </varlistentry> + </variablelist> + + <indexterm class="endofrange" startref="nping-man-icmp-types-indexterm"/> + </refsect2> + + <refsect2 id="nping-man-icmp-codes"> + <indexterm class="startofrange" id="nping-man-icmp-codes-indexterm"><primary>ICMP codes</primary><secondary>mnemonics of, in Nping</secondary></indexterm> + <title>ICMP Codes</title> + + <para> + These identifiers may be used as mnemonics for the ICMP code numbers given + to the + <option>--icmp-code</option><indexterm><primary><option>--icmp-code</option> (Nping option)</primary></indexterm> + option. They are listed by the ICMP type they correspond to. + </para> + + <refsect3> + <title>Destination Unreachable</title> + + <variablelist> + <varlistentry> + <term><literal>network-unreachable</literal></term> + <term><literal>netw-unr</literal></term> + <term><literal>net</literal></term> + <listitem> + <para> + Code 0. Datagram could not be delivered to its destination + network (probably due to some routing problem). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>host-unreachable</literal></term> + <term><literal>host-unr</literal></term> + <term><literal>host</literal></term> + <listitem> + <para> + Code 1. Datagram was delivered to the destination network but it + was impossible to reach the specified host (probably due to some + routing problem). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>protocol-unreachable</literal></term> + <term><literal>prot-unr</literal></term> + <term><literal>proto</literal></term> + <listitem> + <para> + Code 2. The protocol specified in the Protocol field of the IP + datagram is not supported by the host to which the datagram was + delivered. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>port-unreachable</literal></term> + <term><literal>port-unr</literal></term> + <term><literal>port</literal></term> + <listitem> + <para> + Code 3. The TCP/UDP destination port was invalid. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>needs-fragmentation</literal></term> + <term><literal>need-fra</literal></term> + <term><literal>frag</literal></term> + <listitem> + <para> + Code 4. 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. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>source-route-failed</literal></term> + <term><literal>sour-rou</literal></term> + <term><literal>routefail</literal></term> + <listitem> + <para> + Code 5. IP datagram had a Source Route option but a router + couldn't pass it to the next hop. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>network-unknown</literal></term> + <term><literal>netw-unk</literal></term> + <term><literal>net?</literal></term> + <listitem> + <para> + Code 6. Destination network is unknown. This code is never used. + Instead, Network Unreachable is used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>host-unknown</literal></term> + <term><literal>host-unk</literal></term> + <term><literal>host?</literal></term> + <listitem> + <para> + Code 7. Specified host is unknown. Usually generated by a router + local to the destination host to inform of a bad address. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>host-isolated</literal></term> + <term><literal>host-iso</literal></term> + <term><literal>isolated</literal></term> + <listitem> + <para> + Code 8. Source Host Isolated. Not used. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>network-prohibited</literal></term> + <term><literal>netw-pro</literal></term> + <term><literal>!net</literal></term> + <listitem> + <para> + Code 9. Communication with destination network is + administratively prohibited (source device is not allowed to send + packets to the destination network). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>host-prohibited</literal></term> + <term><literal>host-pro</literal></term> + <term><literal>!host</literal></term> + <listitem> + <para> + Code 10. Communication with destination host is administratively + prohibited. (The source device is allowed to send packets to the + destination network but not to the destination device.) + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>network-tos</literal></term> + <term><literal>unreachable-network-tos</literal></term> + <term><literal>netw-tos</literal></term> + <term><literal>tosnet</literal></term> + <listitem> + <para> + Code 11. Destination network unreachable because it cannot + provide the type of service specified in the IP TOS field. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>host-tos</literal></term> + <term><literal>unreachable-host-tos</literal></term> + <term><literal>toshost</literal></term> + <listitem> + <para> + Code 12. Destination host unreachable because it cannot provide + the type of service specified in the IP TOS field. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>communication-prohibited</literal></term> + <term><literal>comm-pro</literal></term> + <term><literal>!comm</literal></term> + <listitem> + <para> + Code 13. Datagram could not be forwarded due to filtering that + blocks the message based on its contents. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>host-precedence-violation</literal></term> + <term><literal>precedence-violation</literal></term> + <term><literal>prec-vio</literal></term> + <term><literal>violation</literal></term> + <listitem> + <para> + Code 14. Precedence value in the IP TOS field is not permitted. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>precedence-cutoff</literal></term> + <term><literal>prec-cut</literal></term> + <term><literal>cutoff</literal></term> + <listitem> + <para> + Code 15. Precedence value in the IP TOS field is lower than the + minimum allowed for the network. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect3> + + <refsect3> + <title>Redirect</title> + + <variablelist> + <varlistentry> + <term><literal>redirect-network</literal></term> + <term><literal>redi-net</literal></term> + <term><literal>net</literal></term> + <listitem> + <para> + Code 0. 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.<indexterm><primary>RFC 1812</primary></indexterm> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>redirect-host</literal></term> + <term><literal>redi-host</literal></term> + <term><literal>host</literal></term> + <listitem> + <para> + Code 1. Redirect all future datagrams with the same destination + host as the original datagram, to the router specified in the + Address field. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>redirect-network-tos</literal></term> + <term><literal>redi-ntos</literal></term> + <term><literal>redir-ntos</literal></term> + <listitem> + <para> + Code 2. 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. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>redirect-host-tos</literal></term> + <term><literal>redi-htos</literal></term> + <term><literal>redir-htos</literal></term> + <listitem> + <para> + Code 3. 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. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect3> + + <refsect3> + <title>Router Advertisement</title> + + <variablelist> + <varlistentry> + <term><literal>normal-advertisement</literal></term> + <term><literal>norm-adv</literal></term> + <term><literal>normal</literal></term> + <term><literal>zero</literal></term> + <term><literal>default</literal></term> + <term><literal>def</literal></term> + <listitem> + <para> + Code 0. Normal router advertisement. In Mobile IP: Mobility agent + can act as a router for IP datagrams not related to mobile nodes. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>not-route-common-traffic</literal></term> + <term><literal>not-rou</literal></term> + <term><literal>mobile-ip</literal></term> + <term><literal>!route</literal></term> + <term><literal>!commontraffic</literal></term> + <listitem> + <para> + Code 16. 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 + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect3> + + <refsect3> + <title>Time Exceeded</title> + + <variablelist> + <varlistentry> + <term><literal>ttl-exceeded-in-transit</literal></term> + <term><literal>ttl-exc</literal></term> + <term><literal>ttl-transit</literal></term> + <listitem> + <para> + Code 0. IP Time To Live expired during transit. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>fragment-reassembly-time-exceeded</literal></term> + <term><literal>frag-exc</literal></term> + <term><literal>frag-time</literal></term> + <listitem> + <para> + Code 1. Fragment reassembly time has been exceeded. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect3> + + <refsect3> + <title>Parameter Problem</title> + + <variablelist> + <varlistentry> + <term><literal>pointer-indicates-error</literal></term> + <term><literal>poin-ind</literal></term> + <term><literal>pointer</literal></term> + <listitem> + <para> + Code 0. The pointer field indicates the location of the problem. + See the <option>--icmp-param-pointer</option> option. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>missing-required-option</literal></term> + <term><literal>miss-option</literal></term> + <term><literal>option-missing</literal></term> + <listitem> + <para> + Code 1. IP datagram was expected to have an option that is not + present. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>bad-length</literal></term> + <term><literal>bad-len</literal></term> + <term><literal>badlen</literal></term> + <listitem> + <para> + Code 2. The length of the IP datagram is incorrect. + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect3> + +<!-- + <refsect3> + <title>ICMP Security Failures Messages (Experimental)</title> + + <variablelist> + <varlistentry> + <term><literal>bad-spi</literal></term> + <term><literal>badspi</literal></term> + <term><literal>!spi</literal></term> + <listitem> + <para> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>authentication-failed</literal></term> + <term><literal>auth-fai</literal></term> + <term><literal>auth-failed</literal></term> + <term><literal>authfail</literal></term> + <term><literal>!auth</literal></term> + <listitem> + <para> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>decompression-failed</literal></term> + <term><literal>deco-fai</literal></term> + <term><literal>decom-failed</literal></term> + <term><literal>!decompress</literal></term> + <term><literal>!decompression</literal></term> + <listitem> + <para> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>decryption-failed</literal></term> + <term><literal>decr-fai</literal></term> + <term><literal>decrypt-failed</literal></term> + <term><literal>!decrypt</literal></term> + <term><literal>!decryption</literal></term> + <listitem> + <para> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>need-authentication</literal></term> + <term><literal>need-aut</literal></term> + <term><literal>need-auth</literal></term> + <term><literal>auth-needed</literal></term> + <term><literal>!auth</literal></term> + <listitem> + <para> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>need-authorization</literal></term> + <term><literal>need-author</literal></term> + <term><literal>authorization-needed</literal></term> + <term><literal>author-needed</literal></term> + <term><literal>!author</literal></term> + <term><literal>!authorization</literal></term> + <listitem> + <para> + </para> + </listitem> + </varlistentry> + </variablelist> + </refsect3> +--> + + <indexterm class="endofrange" startref="nping-man-icmp-types-indexterm"/> + </refsect2> + </refsect1> + +<!-- ARP MODE ************************************************************* --> + <refsect1 id="nping-man-arp-mode"> + <title>ARP Mode</title> + + + <variablelist> + + <varlistentry> + <term> + <option>--arp-type <replaceable>type</replaceable></option> (ICMP Type) + <indexterm significance="preferred"><primary><option>--arp-type</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option specifies which type of ARP messages should be + generated. <replaceable>type</replaceable> can be supplied in + two different ways. You can use the + <ulink url="http://www.iana.org/assignments/arp-parameters/">official + numbers assigned by IANA</ulink> + (e.g. <option>--arp-type 1</option> for ARP Request), or you can use + one of the mnemonics from <xref linkend="nping-man-arp-types"/>. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--arp-sender-mac <replaceable>mac</replaceable></option> (Sender MAC address) + <indexterm significance="preferred"><primary><option>--arp-sender-mac</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option sets the Sender Hardware Address field of the ARP header. + Although ARP supports many types of link layer addresses, currently + Nping only supports MAC addresses. + <replaceable>mac</replaceable> must be specified using the + traditional MAC notation (e.g. <literal>00:0a:8a:32:f4:ae</literal>). You can also use + hyphens as separators (e.g. <literal>00-0a-8a-32-f4-ae</literal>). + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--arp-sender-ip <replaceable>addr</replaceable></option> (Sender IP address) + <indexterm significance="preferred"><primary><option>--arp-sender-ip</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option sets the Sender IP field of the ARP header. + <replaceable>addr</replaceable> can be given as an IPv4 address or a + hostname. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--arp-target-mac <replaceable>mac</replaceable></option> (target MAC address) + <indexterm significance="preferred"><primary><option>--arp-target-mac</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option sets the Target Hardware Address field of the ARP header. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--arp-target-ip <replaceable>addr</replaceable></option> (target ip address) + <indexterm significance="preferred"><primary><option>--arp-target-ip</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option sets the Target IP field of the ARP header. + </para> + </listitem> + </varlistentry> + + </variablelist> + + <refsect2 id="nping-man-arp-types"> + <indexterm class="startofrange" id="nping-man-arp-types-indexterm"><primary>ARP types</primary><secondary>mnemonics of, in Nping</secondary></indexterm> + <title>ARP Types</title> + + <para> + These identifiers may be used as mnemonics for the ARP type numbers given + to the + <option>--arp-type</option><indexterm><primary><option>--arp-type</option> (Nping option)</primary></indexterm> + option. + </para> + + <variablelist> + <varlistentry> + <term><literal>arp-request</literal></term> + <term><literal>arp</literal></term> + <term><literal>a</literal></term> + <listitem> + <para> + ARP Request (type 1). 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. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>arp-reply</literal></term> + <term><literal>arp-rep</literal></term> + <term><literal>ar</literal></term> + <listitem> + <para> + ARP Reply (type 2). An ARP reply is a message that a host sends in + response to an ARP request to provide its link layer address. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>rarp-request</literal></term> + <term><literal>rarp</literal></term> + <term><literal>r</literal></term> + <listitem> + <para> + RARP Requests (type 3). 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.<indexterm><primary>RFC 903</primary></indexterm> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>rarp-reply</literal></term> + <term><literal>rarp-rep</literal></term> + <term><literal>rr</literal></term> + <listitem> + <para> + RARP Reply (type 4). 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. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>drarp-request</literal></term> + <term><literal>drarp</literal></term> + <term><literal>d</literal></term> + <listitem> + <para> + Dynamic RARP Request (type 5). 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<indexterm><primary>RFC 1931</primary></indexterm> + for more information. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>drarp-reply</literal></term> + <term><literal>drarp-rep</literal></term> + <term><literal>dr</literal></term> + <listitem> + <para> + Dynamic RARP Reply (type 6). A DRARP reply is a message sent in + response to a RARP request to provide network layer address. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>drarp-error</literal></term> + <term><literal>drarp-err</literal></term> + <term><literal>de</literal></term> + <listitem> + <para> + DRARP Error (type 7). 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. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>inarp-request</literal></term> + <term><literal>inarp</literal></term> + <term><literal>i</literal></term> + <listitem> + <para> + Inverse ARP Request (type 8). 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.<indexterm><primary>RFC 2390</primary></indexterm> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>inarp-reply</literal></term> + <term><literal>inarp-rep</literal></term> + <term><literal>ir</literal></term> + <listitem> + <para> + Inverse ARP Reply (type 9). InARP reply messages are sent in + response to InARP requests to provide the network layer address + associated with the host that has a given link layer address. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>arp-nak</literal></term> + <term><literal>an</literal></term> + <listitem> + <para> + ARP NAK (type 10). 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<indexterm><primary>RFC 1577</primary></indexterm> + for more information. + </para> + </listitem> + </varlistentry> + </variablelist> + + <indexterm class="endofrange" startref="nping-man-arp-types-indexterm"/> + </refsect2> + + </refsect1> + + + +<!-- IPv4 OPTIONS ********************************************************** --> + <refsect1 id="nping-man-ip-options"> + <title>IPv4 Options</title> + + <variablelist> + + <varlistentry> + <term> + <option>-S <replaceable>addr</replaceable></option>, + <option>--source-ip <replaceable>addr</replaceable></option> (Source IP Address) + <indexterm significance="preferred"><primary><option>--source-ip</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-S</option> (Nping option)</primary><see><option>--source-ip</option></see></indexterm> + </term> + <listitem> + <para> + Sets the 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. + <replaceable>addr</replaceable> can be an IPv4 address or a hostname. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--dest-ip <replaceable>addr</replaceable></option> (Destination IP Address) + <indexterm significance="preferred"><primary><option>--dest-ip</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Adds a target to Nping's target list. + This option is provided for consistency but its use is deprecated + in favor of plain target specifications. See + <xref linkend="nping-man-target-specification"/>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--tos <replaceable>tos</replaceable></option> (Type of Service) + <indexterm significance="preferred"><primary><option>--tos</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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<indexterm><primary>RFC 2474</primary></indexterm> + for + more information. <replaceable>tos</replaceable> must be a number + in the range [0–255]. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--id <replaceable>id</replaceable></option> (Identification) + <indexterm significance="preferred"><primary><option>--id</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Sets the IPv4 Identification field. The Identification field is a + 16-bit 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. <replaceable>id</replaceable> + must be a number in the range [0–65535]. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--df</option> (Don't Fragment) + <indexterm significance="preferred"><primary><option>--df</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--mf</option> (More Fragments) + <indexterm significance="preferred"><primary><option>--mf</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--evil</option> (Reserved / Evil) + <indexterm significance="preferred"><primary><option>--evil</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Sets the Reserved / Evil bit in sent packets. The Evil flag + helps firewalls and other network security systems to distinguish + between datagrams that have malicious intent and those that are + merely unusual. When set, it indicates that the datagram has evil + intent, instructing insecure systems to succumb. Setting it to zero + indicates no evil intent. The option is implied if environmental + variable SCRIPT_KIDDIE is set to a non-zero value. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--ttl <replaceable>hops</replaceable></option> (Time To Live) + <indexterm significance="preferred"><primary><option>--ttl</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Sets the IPv4 Time-To-Live (TTL) 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. + <replaceable>hops</replaceable> must be a number in the range [0–255]. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--badsum-ip</option> (Invalid IP checksum) + <indexterm significance="preferred"><primary><option>--badsum-ip</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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 output, the + packets may be transparently corrected by the kernel. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--ip-options <replaceable>R|S [route]|L [route]|T|U ...</replaceable></option>, + <option>--ip-options <replaceable>hex string</replaceable></option> (IP Options) + <indexterm significance="preferred"><primary><option>--ip-options</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. + </para> + + <para> + The most powerful way to specify IP options is to simply pass in hexadecimal data + as the argument to <option>--ip-options</option>. Precede each hex byte value + with <literal>\x</literal>. You may repeat certain characters by + following them with an asterisk and then the number of times you + wish them to repeat. For example, + <literal>\x01\x07\x04\x00*4</literal> is the same as + <literal>\x01\x07\x04\x00\x00\x00\x00</literal>. + </para> + + <para> + 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 + can only express multiples of four. In those cases, the length is + computed by dividing the header length by 4 and rounding down. + 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. + </para> + + <para> + Nping also offers a shortcut mechanism for specifying options. + Simply pass the letter <literal>R</literal>, <literal>T</literal>, or <literal>U</literal> 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. + </para> + + <para> + For more information and examples of using IP options with Nping, + see the mailing list post at + <ulink url="https://seclists.org/nmap-dev/2006/q3/0052.html"/>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--mtu <replaceable>size</replaceable></option> (Maximum Transmission Unit) + <indexterm significance="preferred"><primary><option>--mtu</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option sets a fictional MTU in Nping so IP datagrams larger than + <replaceable>size</replaceable> are fragmented before transmission. + <replaceable>size</replaceable> must be specified in bytes and + corresponds to the number of octets that can be carried on a + single link-layer frame. + </para> + </listitem> + </varlistentry> + + + </variablelist> + </refsect1> + + + + + +<!-- IPv6 OPTIONS ********************************************************** --> + <refsect1 id="nping-man-ip6-options"> + <title>IPv6 Options</title> + + <variablelist> + + <varlistentry> + <term> + <option>-6</option>, + <option>--ipv6</option> (Use IPv6) + <indexterm significance="preferred"><primary><option>--ipv6</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-6</option> (Nping option)</primary><see><option>--ipv6</option></see></indexterm> + </term> + <listitem> + <para> + 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 <option>-6</option> option. + Of course, you must use IPv6 syntax if you specify an address + rather than a hostname. An address might look like + <option>3ffe:7501:4819:2000:210:f3ff:fe03:14d0</option>, so hostnames are + recommended. + </para> + <para> + 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 + <ulink url="http://www.tunnelbroker.net"/>. + </para> + <para> + Please note that IPv6 support is still highly experimental and + many modes and options may not work with it. + </para> + + </listitem> + </varlistentry> + + + + <varlistentry> + <term> + <option>-S <replaceable>addr</replaceable></option>, + <option>--source-ip <replaceable>addr</replaceable></option> (Source IP Address) + <indexterm significance="preferred"><primary><option>--source-ip</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Sets the 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. + <replaceable>addr</replaceable> can be an IPv6 address or a hostname. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--dest-ip <replaceable>addr</replaceable></option> (Destination IP Address) + <indexterm significance="preferred"><primary><option>--dest-ip</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Adds a target to Nping's target list. + This option is provided for consistency but its use is deprecated + in favor of plain target specifications. See + <xref linkend="nping-man-target-specification"/>. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--flow <replaceable>label</replaceable></option> (Flow Label) + <indexterm significance="preferred"><primary><option>--flow</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Sets the IPv6 Flow Label. The Flow Label field is 20 bits long and is + intended to provide certain quality-of-service properties for + real-time datagram delivery. However, it has not been widely + adopted, and not all routers or endpoints support it. Check + RFC 2460<indexterm><primary>RFC 2560</primary></indexterm> + for more information. <replaceable>label</replaceable> must be an + integer in the range [0–1048575]. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--traffic-class <replaceable>class</replaceable></option> (Traffic Class) + <indexterm significance="preferred"><primary><option>--traffic-class</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Sets the IPv6 Traffic Class. This field is similar to the TOS field in + IPv4, and is intended to provide the Differentiated Services + method, enabling scalable service discrimination in the Internet + without the need for per-flow state and signaling at every hop. Check + RFC 2474<indexterm><primary>RFC 2474</primary></indexterm> + for more information. <replaceable>class</replaceable> must + be an integer in the range [0–255]. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--hop-limit <replaceable>hops</replaceable></option> (Hop Limit) + <indexterm significance="preferred"><primary><option>--hop-limit</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + <indexterm><primary>hop limit (IPv6)</primary><seealso>TTL</seealso></indexterm> + 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 the TTL in IPv4, IPv6 Hop Limit + tries to avoid a situation in which undeliverable datagrams keep being + forwarded from one router to another endlessly. + <replaceable>hops</replaceable> must be a number in the range [0–255]. + </para> + </listitem> + </varlistentry> + + + </variablelist> + </refsect1> + + + + + + +<!-- ETHERNET OPTIONS ***************************************************** --> + <refsect1 id="nping-man-ethernet-options"> + <title>Ethernet Options</title> + + <para> + In most cases Nping sends packets at the 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. + </para> + + <variablelist> + + <varlistentry> + <term> + <option>--dest-mac <replaceable>mac</replaceable></option> (Ethernet Destination MAC Address) + <indexterm significance="preferred"><primary><option>--dest-mac</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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's MAC address or when you want to route + probes through a router other than the configured default + gateway. The MAC address should have the usual format of + six colon-separated bytes, e.g. <literal>00:50:56:d4:01:98</literal>. + Alternatively, hyphens may be used instead of colons. + Use the word <literal>random</literal> or <literal>rand</literal> to + generate a random address, and <literal>broadcast</literal> or + <literal>bcast</literal> to use ff:ff:ff:ff:ff:ff. + If you set up a bogus destination MAC address your probes may not + reach the intended targets. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--source-mac <replaceable>mac</replaceable></option> (Ethernet Source MAC Address) + <indexterm significance="preferred"><primary><option>--source-mac</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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 while hiding your network card's real + address. The syntax is the same as for <literal>--dest-mac</literal>. + If you set up a bogus source MAC address + you may not receive probe replies. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--ether-type <replaceable>type</replaceable></option> (Ethertype) + <indexterm significance="preferred"><primary><option>--ether-type</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option sets the Ethertype field of the ethernet frame. + The Ethertype is used to indicate which protocol is encapsulated + in the payload. <replaceable>type</replaceable> can be supplied in + two different ways. You can use the + <ulink url="http://standards.ieee.org/regauth/ethertype/eth.txt">official + numbers listed by the IEEE</ulink> + (e.g. <option>--ether-type 0x0800</option> for IP version 4), + or one of the mnemonics from + <xref linkend="nping-man-ether-types" xrefstyle="template:the section called “%t”"/>. + <!-- Hide the page number, but also include the section title. xrefstyle="select: label nopage" doesn't work here. --> + </para> + + </listitem> + </varlistentry> + + </variablelist> + + <refsect2 id="nping-man-ether-types"> + <indexterm class="startofrange" id="nping-man-arp-ether-indexterm"><primary>Ethernet types</primary><secondary>mnemonics of, in Nping</secondary></indexterm> + <title>Ethernet Types</title> + + <para> + These identifiers may be used as mnemonics for the Ethertype numbers given + to the + <option>--arp-type</option><indexterm><primary><option>--arp-type</option> (Nping option)</primary></indexterm> + option. + </para> + + <variablelist> + <varlistentry> + <term><literal>ipv4</literal></term> + <term><literal>ip</literal></term> + <term><literal>4</literal></term> + <listitem> + <para> + Internet Protocol version 4 (type 0x0800). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>ipv6</literal></term> + <term><literal>6</literal></term> + <listitem> + <para> + Internet Protocol version 6 (type 0x86DD). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>arp</literal></term> + <listitem> + <para> + Address Resolution Protocol (type 0x0806). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>rarp</literal></term> + <listitem> + <para> + Reverse Address Resolution Protocol (type 0x8035). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>frame-relay</literal></term> + <term><literal>frelay</literal></term> + <term><literal>fr</literal></term> + <listitem> + <para> + Frame Relay (type 0x0808). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>ppp</literal></term> + <listitem> + <para> + Point-to-Point Protocol (type 0x880B). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>gsmp</literal></term> + <listitem> + <para> + General Switch Management Protocol (type 0x880C). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>mpls</literal></term> + <listitem> + <para> + Multiprotocol Label Switching (type 0x8847). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>mps-ual</literal></term> + <term><literal>mps</literal></term> + <listitem> + <para> + Multiprotocol Label Switching with Upstream-assigned Label (type 0x8848). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>mcap</literal></term> + <listitem> + <para> + Multicast Channel Allocation Protocol (type 0x8861). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>pppoe-discovery</literal></term> + <term><literal>pppoe-d</literal></term> + <listitem> + <para> + PPP over Ethernet Discovery Stage (type 0x8863). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>pppoe-session</literal></term> + <term><literal>pppoe-s</literal></term> + <listitem> + <para> + PPP over Ethernet Session Stage (type 0x8864). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>ctag</literal></term> + <listitem> + <para> + Customer VLAN Tag Type (type 0x8100). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>epon</literal></term> + <listitem> + <para> + Ethernet Passive Optical Network (type 0x8808). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>pbnac</literal></term> + <listitem> + <para> + Port-based network access control (type 0x888E). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>stag</literal></term> + <listitem> + <para> + Service VLAN tag identifier (type 0x88A8). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>ethexp1</literal></term> + <listitem> + <para> + Local Experimental Ethertype 1 (type 0x88B5). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>ethexp2</literal></term> + <listitem> + <para> + Local Experimental Ethertype 2 (type 0x88B6). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>ethoui</literal></term> + <listitem> + <para> + OUI Extended Ethertype (type 0x88B7). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>preauth</literal></term> + <listitem> + <para> + Pre-Authentication (type 0x88C7). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>lldp</literal></term> + <listitem> + <para> + Link Layer Discovery Protocol (type 0x88CC). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>mac-security</literal></term> + <term><literal>mac-sec</literal></term> + <term><literal>macsec</literal></term> + <listitem> + <para> + Media Access Control Security (type 0x88E5). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>mvrp</literal></term> + <listitem> + <para> + Multiple VLAN Registration Protocol (type 0x88F5). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>mmrp</literal></term> + <listitem> + <para> + Multiple Multicast Registration Protocol (type 0x88F6). + </para> + </listitem> + </varlistentry> + <varlistentry> + <term><literal>frrr</literal></term> + <listitem> + <para> + Fast Roaming Remote Request (type 0x890D). + </para> + </listitem> + </varlistentry> + </variablelist> + + <indexterm class="endofrange" startref="nping-man-ether-types-indexterm"/> + </refsect2> + </refsect1> + + + + +<!-- PAYLOAD OPTIONS ******************************************************* --> + <refsect1 id="nping-man-payload-options"> + <title>Payload Options</title> + + <variablelist> + + <varlistentry> + <term> + <option>--data <replaceable>hex string</replaceable></option> (Append custom binary data to sent packets) + <indexterm significance="preferred"><primary><option>--data</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option lets you include binary data as payload in sent packets. + <replaceable>hex string</replaceable> may be specified in any of + the following formats: <literal>0xAABBCCDDEEFF<replaceable>...</replaceable></literal>, + <literal>AABBCCDDEEFF<replaceable>...</replaceable></literal> or + <literal>\xAA\xBB\xCC\xDD\xEE\xFF<replaceable>...</replaceable></literal>. + Examples of use are <option>--data 0xdeadbeef</option> and + <option>--data \xCA\xFE\x09</option>. Note that if you specify a + number like <literal>0x00ff</literal> + no byte-order conversion is performed. Make sure you specify + the information in the byte order expected by the receiver. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--data-string <replaceable>string</replaceable></option> (Append custom string to sent packets) + <indexterm significance="preferred"><primary><option>--data-string</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option lets you include a regular string as payload in + sent packets. <replaceable>string</replaceable> can + contain any 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 escape any special characters from the shell. + Example: <option>--data-string "Jimmy Jazz..."</option>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--data-length <replaceable>len</replaceable></option> (Append random data to sent packets) + <indexterm significance="preferred"><primary><option>--data-length</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option lets you include <replaceable>len</replaceable> + random bytes of data as payload in sent packets. + <replaceable>len</replaceable> 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. + </para> + </listitem> + </varlistentry> + + + </variablelist> + </refsect1> + + + + + + +<!-- ECHO MODE ****************************************************** --> + <refsect1 id="nping-man-echo-mode"> + <title>Echo Mode</title> + + <para> + The "Echo Mode" is a novel technique implemented by Nping which lets users + see how network packets change in transit, from the host where they + originated to the target machine. Basically, the Echo mode turns Nping into + two different pieces: the Echo server and the Echo client. The Echo server + is a network service that has the ability to capture packets from the + network and send a copy ("echo them") to the originating client through a + side TCP channel. The Echo client is the part that generates such network + packets, transmits them to the server, and receives their echoed version + through a side TCP channel that it has previously established with the Echo + server. + </para> + + <para> + This scheme lets the client see the differences between the packets that it + sends and what is actually received by the server. By having the server + send back copies of the received packets through the side channel, things + like NAT devices become immediately apparent to the client because it + notices the changes in the source IP address (and maybe even source + port). Other devices like those that perform traffic shaping, changing + TCP window sizes or adding TCP options transparently between hosts, turn up + too. + </para> + + <para> + The Echo mode is also useful for troubleshooting routing and firewall issues. + Among other things, it can be used to determine if the traffic generated + by the Nping client is being dropped in transit and never gets to its + destination or if the responses are the ones that don't get back to it. + </para> + + <para> + Internally, client and server communicate over an encrypted and + authenticated channel, using the Nping Echo Protocol (NEP), whose technical + specification can be found in + <ulink url="https://nmap.org/svn/nping/docs/EchoProtoRFC.txt"/> + </para> + + <para> + The following paragraphs describe the different options available in Nping's + Echo mode. + </para> + + <variablelist> + + <varlistentry> + <term> + <option>--ec <replaceable>passphrase</replaceable></option>, + <option>--echo-client <replaceable>passphrase</replaceable></option> (Run Echo client) + <indexterm significance="preferred"><primary><option>--echo-client</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>--ec</option> (Nping option)</primary><see><option>--echo-client</option></see></indexterm> + </term> + <listitem> + <para> + This option tells Nping to run as an Echo client. + <replaceable>passphrase</replaceable> is a sequence of ASCII + characters that is used used to generate the cryptographic + keys needed for encryption and authentication in a given session. + The passphrase should be a secret that is also known by the server, + and it may contain any number of printable ASCII characters. + Passphrases that contain whitespace or special characters must be + enclosed in double quotes. + </para> + + <para> + When running Nping as an Echo client, most options from the regular + raw probe modes apply. The client may be configured to send specific + probes using flags like <option>--tcp</option>, + <option>--icmp</option> or <option>--udp</option>. Protocol header + fields may be manipulated normally using the appropriate options + (e.g. <option>--ttl</option>, <option>--seq</option>, + <option>--icmp-type</option>, etc.). The only exceptions are + ARP-related flags, which are not supported in Echo mode, as protocols + like ARP are closely related to the data link layer and its probes + can't pass through different network segments. + </para> + + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--es <replaceable>passphrase</replaceable></option>, + <option>--echo-server <replaceable>passphrase</replaceable></option> (Run Echo server) + <indexterm significance="preferred"><primary><option>--echo-server</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>--es</option> (Nping option)</primary><see><option>--echo-server</option></see></indexterm> + </term> + <listitem> + <para> + This option tells Nping to run as an Echo server. + <replaceable>passphrase</replaceable> is a sequence of ASCII + characters that is used used to generate the cryptographic + keys needed for encryption and authentication in a given session. + The passphrase should be a secret that is also known by the clients, + and it may contain any number of printable ASCII characters. + Passphrases that contain whitespace or special characters must be + enclosed in double quotes. Note that although it is not recommended, + it is possible to use empty passphrases, supplying + <option>--echo-server ""</option>. However, if what you + want is to set up an open Echo server, it is better to use option + <option>--no-crypto</option>. See below for details. + </para> + </listitem> + </varlistentry> + + + + <varlistentry> + <term> + <option>--ep <replaceable>port</replaceable></option>, + <option>--echo-port <replaceable>port</replaceable></option> (Set Echo TCP port number) + <indexterm significance="preferred"><primary><option>--echo-port</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>--ep</option> (Nping option)</primary><see><option>--echo-port</option></see></indexterm> + </term> + <listitem> + <para> + This option asks Nping to use the specified TCP port number for the + Echo side channel connection. If this option is used with + <option>--echo-server</option>, it specifies the port on which the + server listens for connections. If it is used with + <option>--echo-client</option>, it specifies the port to connect to + on the remote host. By default, port number 9929 is used. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--nc</option>, + <option>--no-crypto</option> (Disable encryption and authentication) + <indexterm significance="preferred"><primary><option>--no-crypto</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>--nc</option> (Nping option)</primary><see><option>--no-crypto</option></see></indexterm> + </term> + <listitem> + <para> + This option asks Nping not to use any cryptographic operations during + an Echo session. In practical terms, this means that the Echo side + channel session data will be transmitted in the clear, and no + authentication will be performed by the server or client + during the session establishment phase. When <option>--no-crypto</option> + is used, the passphrase supplied with <option>--echo-server</option> + or <option>--echo-client</option> is ignored. + </para> + + <para> + This option must be specified if Nping was compiled without + openSSL support. Note that, for technical reasons, a passphrase still + needs to be supplied after the --echo-client or --echo-server flags, + even though it will be ignored. + </para> + + <para> + The --no-crypto flag might be useful when setting up a public Echo + server, because it allows users to connect to the Echo server without + the need for any passphrase or shared secret. However, it is strongly + recommended to not use --no-crypto unless absolutely necessary. Public + Echo servers should be configured to use the passphrase "public" or + the empty passphrase (--echo-server "") as the use of cryptography + does not only provide confidentiality and authentication but also + message integrity. + </para> + + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--once</option> (Serve one client and quit) + <indexterm significance="preferred"><primary><option>--once</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option asks the Echo server to quit after serving one client. + This is useful when only a single Echo session wants to be established + as it eliminates the need to access the remote host to shutdown the + server. + </para> + + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--safe-payloads</option> (Zero application data before echoing a packet) + <indexterm significance="preferred"><primary><option>--safe-payloads</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option asks the Echo server to erase any application layer data + found in client packets before echoing them. When the option is enabled, + the Echo server parses the packets received from Echo clients and tries + to determine if they contain data beyond the transport layer. If such + data is found, it is overwritten with zeroes before transmitting the + packets to the appropriate Echo client. + </para> + + <para> + Echo servers can handle multiple simultaneous clients running + multiple echo sessions in parallel. In order to determine which packet + needs to be echoed to which client and through which session, the Echo + server uses an heuristic algorithm. Although we have taken every + security measure that we could think of to prevent that a client + receives an echoed packet that it did not generate, there is always + a risk that our algorithm makes a mistake and delivers a packet to + the wrong client. The --safe-payloads option is useful for public + echo servers or critical deployments where that kind of mistake + cannot be afforded. + </para> + + </listitem> + </varlistentry> + </variablelist> + + <para> + The following examples illustrate how Nping's Echo mode can be used + to discover intermediate devices. + </para> + + <example id="nping-man-ex-echo1"><title>Discovering NAT devices</title> + <indexterm><primary><option>--echo-client</option> (Nping option)</primary><secondary>example of</secondary></indexterm> + <screen format="linespecific"> + # <userinput>nping --echo-client "public" echo.nmap.org --udp </userinput> + + Starting Nping ( https://nmap.org/nping ) + SENT (1.0970s) UDP 10.1.20.128:53 > 178.79.165.17:40125 ttl=64 id=32523 iplen=28 + CAPT (1.1270s) UDP 80.38.10.21:45657 > 178.79.165.17:40125 ttl=54 id=32523 iplen=28 + RCVD (1.1570s) ICMP 178.79.165.17 > 10.1.20.128 Port unreachable (type=3/code=3) ttl=49 id=16619 iplen=56 + [...] + SENT (5.1020s) UDP 10.1.20.128:53 > 178.79.165.17:40125 ttl=64 id=32523 iplen=28 + CAPT (5.1335s) UDP 80.38.10.21:45657 > 178.79.165.17:40125 ttl=54 id=32523 iplen=28 + RCVD (5.1600s) ICMP 178.79.165.17 > 10.1.20.128 Port unreachable (type=3/code=3) ttl=49 id=16623 iplen=56 + + Max rtt: 60.628ms | Min rtt: 58.378ms | Avg rtt: 59.389ms + Raw packets sent: 5 (140B) | Rcvd: 5 (280B) | Lost: 0 (0.00%)| Echoed: 5 (140B) + Tx time: 4.00459s | Tx bytes/s: 34.96 | Tx pkts/s: 1.25 + Rx time: 5.00629s | Rx bytes/s: 55.93 | Rx pkts/s: 1.00 + Nping done: 1 IP address pinged in 6.18 seconds + </screen> + </example> + + <para> + The output clearly shows the presence of a NAT device in the client's local + network. Note how the captured packet (CAPT) differs from the SENT packet: the + source address for the original packets is in the reserved 10.0.0.0/8 range, + while the address seen by the server is 80.38.10.21, the Internet side address + of the NAT device. The source port was also modified by the device. The line + starting with RCVD corresponds to the responses generated by the TCP/IP stack + of the machine where the Echo server is run. + </para> + + <example id="nping-man-ex-echo2"><title>Discovering a transparent proxy</title> + <screen format="linespecific"> + # <userinput>nping --echo-client "public" echo.nmap.org --tcp -p80</userinput> + + Starting Nping ( https://nmap.org/nping ) + SENT (1.2160s) TCP 10.0.1.77:41659 > 178.79.165.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480 + RCVD (1.2180s) TCP 178.79.165.17:80 > 10.0.1.77:41659 SA ttl=128 id=13177 iplen=44 seq=3647106954 win=16384 <mss 1460> + SENT (2.2150s) TCP 10.0.1.77:41659 > 178.79.165.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480 + SENT (3.2180s) TCP 10.0.1.77:41659 > 178.79.165.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480 + SENT (4.2190s) TCP 10.0.1.77:41659 > 178.79.165.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480 + SENT (5.2200s) TCP 10.0.1.77:41659 > 178.79.165.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480 + + Max rtt: 2.062ms | Min rtt: 2.062ms | Avg rtt: 2.062ms + Raw packets sent: 5 (200B) | Rcvd: 1 (46B) | Lost: 4 (80.00%)| Echoed: 0 (0B) + Tx time: 4.00504s | Tx bytes/s: 49.94 | Tx pkts/s: 1.25 + Rx time: 5.00618s | Rx bytes/s: 9.19 | Rx pkts/s: 0.20 + Nping done: 1 IP address pinged in 6.39 seconds + </screen> + </example> + + <para> + In this example, the output is a bit more tricky. The absence of error + messages shows that the Echo client has successfully established an Echo + session with the server. However, no CAPT packets can be seen in the output. + This means that none of the transmitted packets reached the server. + Interestingly, a TCP SYN-ACK packet was received in response to the first + TCP-SYN packet (and also, it is known that the target host does not have + port 80 open). This behavior reveals the presence of a transparent web proxy + cache server (which in this case is an old MS ISA server). + </para> + +</refsect1> + + +<!-- TIMING AND PERFORMANCE OPTIONS **************************************** --> + <refsect1 id="nping-man-timing-performance-options"> + <title>Timing and Performance Options</title> + + <variablelist> + + <varlistentry> + <term> + <option>--delay <replaceable>time</replaceable></option> (Delay between probes) + <indexterm significance="preferred"><primary><option>--delay</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option lets you control for how long will Nping wait before + sending the next probe. Like in many other ping tools, the default + delay is one second. + <replaceable>time</replaceable> 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 + <literal>ms</literal> for milliseconds, <literal>s</literal> for seconds, + <literal>m</literal> for minutes, or <literal>h</literal> for hours + (e.g. <literal>2.5s</literal>, <literal>45m</literal>, <literal>2h</literal>). + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--rate <replaceable>rate</replaceable></option> (Send probes at a given rate) + <indexterm significance="preferred"><primary><option>--rate</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option specifies the number of probes that Nping should send + per second. This option and <option>--delay</option> are inverses; + <option>--rate 20</option> is the same as + <option>--delay 0.05</option>. If both options are used, only the + last one in the parameter list counts. + </para> + </listitem> + </varlistentry> + + + </variablelist> + </refsect1> + + + + + + + + + +<!-- MISCELLANEOUS OPTIONS ************************************************ --> + <refsect1 id="nping-man-miscellaneous-options"> + <title>Miscellaneous Options</title> + + <variablelist> + + <varlistentry> + <term><option>-h</option>, + <option>--help</option> (Display help) + <indexterm significance="preferred"><primary><option>--help</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>--h</option> (Nping option)</primary><see><option>--help</option></see></indexterm> + </term> + <listitem> + <para> + Displays help information and exits. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>-V</option>, + <option>--version</option> (Display version) + <indexterm significance="preferred"><primary><option>--version</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-V</option> (Nping option)</primary><see><option>--version</option></see></indexterm> + </term> + <listitem> + <para> + Displays the program's version number and quits. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>-c <replaceable>rounds</replaceable></option>, + <option>--count <replaceable>rounds</replaceable></option> (Stop after a given number of rounds) + <indexterm significance="preferred"><primary><option>--count</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-c</option> (Nping option)</primary><see><option>--count</option></see></indexterm> + </term> + <listitem> + <para> + This option lets you specify the number of times that Nping should + loop over target hosts (and in some cases target ports). Nping calls + these <quote>rounds</quote>. 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 and 433, then 256 × 2 = 512 packets + are sent in one round. So if you specify <option>-c 100</option>, Nping will + loop over the different target hosts and ports 100 times, sending + a total of 256 × 2 × 100 = 51200 packets. By default Nping runs for + 5 rounds. If a value of 0 is specified, Nping will run continuously. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>-e <replaceable>name</replaceable></option>, + <option>--interface <replaceable>name</replaceable></option> (Set the network interface to be used) + <indexterm significance="preferred"><primary><option>--interface</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-e</option> (Nping option)</primary><see><option>--interface</option></see></indexterm> + </term> + <listitem> + <para> + 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. <replaceable>name</replaceable> + must be the name of an existing network interface with an assigned + IP address. + + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--privileged</option> (Assume that the user is fully privileged) + <indexterm significance="preferred"><primary><option>--privileged</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Tells Nping to simply assume that it is privileged enough to perform + raw socket sends, packet sniffing, and similar operations that + usually require special privileges. By default Nping quits if such + operations are requested by a user that has no root or administrator + privileges. This option may be useful on Linux, BSD or similar + systems that can be configured to allow unprivileged users to perform + raw-packet transmissions. The + <envar>NPING_PRIVILEGED</envar><indexterm><primary><envar>NPING_PRIVILEGED</envar> environment variable</primary></indexterm> + environment variable + may be set as an alternative to using <option>--privileged</option>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--unprivileged</option> (Assume that the user lacks raw socket privileges) + <indexterm significance="preferred"><primary><option>--unprivileged</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + This option is the opposite of <option>--privileged</option>. 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 + <envar>NPING_UNPRIVILEGED</envar><indexterm><primary><envar>NPING_UNPRIVILEGED</envar> environment variable</primary></indexterm> + environment variable may be set as an + alternative to using <option>--unprivileged</option>. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--send-eth</option> (Use raw ethernet sending) + <indexterm significance="preferred"><primary><option>--send-eth</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + 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. Nping still uses raw IP + packets despite this option when there is no other choice (such as + non-ethernet connections). + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>--send-ip</option> (Send at raw IP level) + <indexterm significance="preferred"><primary><option>--send-ip</option> (Nping option)</primary></indexterm> + </term> + <listitem> + <para> + Asks Nping to send packets via raw IP sockets rather than sending + lower level ethernet frames. It is the complement to the + <option>--send-eth</option> option. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>--bpf-filter <replaceable>filter spec</replaceable></option> + <option>--filter <replaceable>filter spec</replaceable></option> (Set custom BPF filter) + <indexterm significance="preferred"><primary><option>--bpf-filter</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>--filter</option> (Nping option)</primary><see>--bpf-filter</see></indexterm> + </term> + <listitem> + <para> + This option lets you use 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 packets, the filter is set to capture packets whose destination + port matches the probe's source port or ICMP error messages that may + be generated by the target or any intermediate device as a result of + the probe. 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 BPF syntax used + by tools like + tcpdump.<indexterm><primary>tcpdump</primary></indexterm> + See the documentation at <ulink url="http://www.tcpdump.org/"/> for + more information. + </para> + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>-H</option>, + <option>--hide-sent</option> (Do not display sent packets) + <indexterm significance="preferred"><primary><option>--hide-sent</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-H</option> (Nping option)</primary><see>--hide-sent</see></indexterm> + </term> + <listitem> + <para> + This option tells Nping not to print information about sent packets. + This can be useful when using very short inter-probe delays (i.e., + when flooding), because printing information to the standard + output has a computational cost and disabling it can probably + speed things up a bit. Also, it may be useful when using Nping to + detect active hosts or open ports (e.g. sending probes to all TCP + ports in a /24 subnet). In that case, users may not want to see + thousands of sent probes but just the replies generated by active + hosts. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term> + <option>-N</option>, + <option>--no-capture</option> (Do not attempt to capture replies) + <indexterm significance="preferred"><primary><option>--no-capture</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-N</option> (Nping option)</primary><see><option>--no-capture</option></see></indexterm> + </term> + <listitem> + <para> + 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. + </para> + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + + + + + +<!-- OUTPUT OPTIONS **************************************** --> + <refsect1 id="nping-man-output-options"> + <title>Output Options</title> + + <variablelist> + + <varlistentry> + <term> + <option>-v<optional><replaceable>level</replaceable></optional></option>, + <option>--verbose <optional><replaceable>level</replaceable></optional></option> (Increase or set verbosity level) + <indexterm significance="preferred"><primary><option>--verbose</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-v</option> (Nping option)</primary><see><option>--verbose</option></see></indexterm> + </term> + <listitem> + <para> + 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 <option>-v</option> increments the verbosity level by one + (from its default value, level 0). Every instance of option <option>-q</option> + decrements the verbosity level by one. Alternatively you can specify + the level directly, as in <option>-v3</option> or + <option>-v-1</option>. These are the available levels: + </para> + + <indexterm><primary>verbosity levels of Nping</primary></indexterm> + <variablelist> + <varlistentry> + <term>Level -4</term> + <listitem> + <para> + 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 -4 can be useful + because although you won't see any response packets, probes will + still be sent. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level -3</term> + <listitem> + <para> + Like level -4 but displays fatal error messages so you can + actually see if Nping is running or it failed due to some error. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level -2</term> + <listitem> + <para> + Like level -3 but also displays warnings and recoverable errors. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level -1</term> + <listitem> + <para> + Displays traditional run-time information (version, start time, + statistics, etc.) but does not display sent or received packets. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 0</term> + <listitem> + <para> + This is the default verbosity level. It behaves like level -1 but + also displays sent and received packets and some other important information. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 1</term> + <listitem> + <para> + Like level 0 but it displays detailed information about + timing, flags, protocol details, etc. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 2</term> + <listitem> + <para> + Like level 1 but displays very detailed information + about sent and received packets and other interesting information. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 3</term> + <listitem> + <para> + Like level 2 but also displays the raw hexadecimal dump of sent + and received packets. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 4 and higher</term> + <listitem> + <para> + Same as level 3. + </para> + </listitem> + </varlistentry> + </variablelist> + + </listitem> + </varlistentry> + + + <varlistentry> + <term> + <option>-q<optional><replaceable>level</replaceable></optional></option>, + <option>--reduce-verbosity <optional><replaceable>level</replaceable></optional></option> (Decrease verbosity level) + <indexterm significance="preferred"><primary><option>--reduce-verbosity</option> (Nping option)</primary></indexterm> + <indexterm significance="preferred"><primary><option>-q</option> (Nping option)</primary><see>--reduce-verbosity</see></indexterm> + </term> + <listitem> + <para> + Decreases the verbosity level, causing Nping to print less + information during its execution. + </para> + + </listitem> + </varlistentry> + + + + <varlistentry> + <term> + <option>-d<optional><replaceable>level</replaceable></optional></option> (Increase or set debugging level) + <indexterm significance="preferred"><primary><option>-d</option> (Nping option)</primary></indexterm> + </term> + <listitem> + + <para> + When even verbose mode doesn't provide sufficient data for you, + debugging is available to flood you with much more! As with the + <option>-v</option>, debugging is enabled with a command-line + flag <option>-d</option> and the debug level can be increased by + specifying it multiple times. There are 7 debugging levels (0 to 6). + Every instance of <option>-d</option> increments debugging level by + one. Provide an argument to <option>-d</option> to set the level + directly; for example <option>-d4</option>. + </para> + + <para> + Debugging output is useful when you suspect a bug 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 +<indexterm><primary>Nsock</primary><secondary>debug output of</secondary></indexterm> +<screen> +NSOCK (1.0000s) Callback: TIMER SUCCESS for EID 12; tcpconnect_event_handler<continuation/>(): Received callback of type TIMER with status SUCCESS +</screen> + 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 (<citetitle>nmap-dev</citetitle>). Some lines are + self-explanatory, but the messages become more obscure as the debug + level is increased. These are the available levels: + </para> + + <indexterm><primary>debug levels of Nping</primary></indexterm> + <variablelist> + <varlistentry> + <term>Level 0</term> + <listitem> + <para> + Level 0. No debug information at all. This is the default level. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 1</term> + <listitem> + <para> + In this level, only very important or high-level debug information + will be printed. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 2</term> + <listitem> + <para> + Like level 1 but also displays important or medium-level debug + information + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 3</term> + <listitem> + <para> + Like level 2 but also displays regular and low-level debug information. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 4</term> + <listitem> + <para> + Like level 3 but also displays messages only a real Nping freak would + want to see. + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 5</term> + <listitem> + <para> + Like level 4 but it enables basic debug information related to + external libraries like Nsock.<indexterm><primary>Nsock</primary></indexterm> + </para> + </listitem> + </varlistentry> + <varlistentry> + <term>Level 6</term> + <listitem> + <para> + Like level 5 but it enables full, very detailed, debug information + related to external libraries like Nsock. + </para> + </listitem> + </varlistentry> + </variablelist> + + </listitem> + </varlistentry> + + </variablelist> + </refsect1> + + <refsect1 id="nping-man-bugs"> + <title>Bugs</title> + <indexterm><primary>bugs, reporting</primary></indexterm> + + <para>Like its authors, 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 <ulink + url="https://nmap.org"/>. If the problem persists, + do some research to determine whether it has already been + discovered and addressed. Try searching for the problem or error message on + Google since that aggregates so many forums. If nothing comes of this, create an Issue on our tracker + (<ulink url="http://issues.nmap.org"/>) and/or mail a bug report to + <email>dev@nmap.org</email>. If you subscribe to the nmap-dev + list before posting, your message will bypass moderation and get + through more quickly. Subscribe at <ulink + url="https://nmap.org/mailman/listinfo/dev"/>. Please include everything + you have learned about the problem, as well as what version of + Nping you are using and what operating system version it is + running on. Other suggestions for improving Nping may be sent to + the Nmap dev mailing list as well.</para> + + <para>If you are able to write a patch improving Nping or fixing a + bug, that is even better! Instructions for submitting patches or + git pull requests are available from <ulink + url="https://github.com/nmap/nmap/blob/master/CONTRIBUTING.md"/></para> + + <para>Particularly sensitive issues such as a security reports may + be sent directly to Fyodor directly at + <email>fyodor@nmap.org</email>. All other reports and comments + should use the dev list or issue tracker instead because more + people read, follow, and respond to those.</para> + + </refsect1> + + <refsect1 id="nping-man-author"> + <title>Authors</title> + + <para>Luis MartinGarcia <email>luis.mgarc@gmail.com</email> (<ulink url="http://www.luismg.com" />)</para> + + <para>Fyodor <email>fyodor@nmap.org</email> (<ulink url="https://insecure.org" />)</para> + + </refsect1> + + +</refentry> diff --git a/nping/docs/nping-usage.txt b/nping/docs/nping-usage.txt new file mode 100644 index 0000000..3e0cfca --- /dev/null +++ b/nping/docs/nping-usage.txt @@ -0,0 +1,120 @@ +Nping 0.7.92SVN ( https://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.*.1-24 +PROBE MODES: + --tcp-connect : Unprivileged TCP connect probe mode. + --tcp : TCP probe mode. + --udp : UDP 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). + -g, --source-port <portnumber> : Try to use a custom source port. +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. +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 Don't Fragment flag. + --mf : Set More Fragments flag. + --evil : Set Reserved / Evil flag. + --ttl <hops> : Set time to live [0-255]. + --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 : Set hop limit (same as IPv4 TTL). + --traffic-class <class> : : Set traffic class. + --flow <label> : Set 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-length <len> : Include len random bytes as payload. +ECHO CLIENT/SERVER: + --echo-client <passphrase> : Run Nping in client mode. + --echo-server <passphrase> : Run Nping in server mode. + --echo-port <port> : Use custom <port> to listen or connect. + --no-crypto : Disable encryption and authentication. + --once : Stop the server after one connection. + --safe-payloads : Erase application data in echoed packets. +TIMING AND PERFORMANCE: + Options which take <time> are in seconds, or append 'ms' (milliseconds), + 's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m, 0.25h). + --delay <time> : Adjust delay between probes. + --rate <rate> : Send num packets per second. +MISC: + -h, --help : Display help information. + -V, --version : Display 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 : Set verbosity and debug level to minimum. + --debug : Set 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 time --delay 500ms 192.168.254.254 + nping --echo-server "public" -e wlan0 -vvv + nping --echo-client "public" echo.nmap.org --tcp -p1-1024 --flags ack + +SEE THE MAN PAGE FOR MANY MORE OPTIONS, DESCRIPTIONS, AND EXAMPLES + diff --git a/nping/docs/nping-usage.xml b/nping/docs/nping-usage.xml new file mode 100644 index 0000000..6713aff --- /dev/null +++ b/nping/docs/nping-usage.xml @@ -0,0 +1,2 @@ +<?dbfo-need height="1in"?> +<screen><xi:include href="nping-usage.txt" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude" /></screen> diff --git a/nping/docs/nping.1 b/nping/docs/nping.1 new file mode 100644 index 0000000..2c92f41 --- /dev/null +++ b/nping/docs/nping.1 @@ -0,0 +1,1797 @@ +'\" t +.\" Title: nping +.\" Author: [see the "Authors" section] +.\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/> +.\" Date: 05/17/2023 +.\" Manual: Nping Reference Guide +.\" Source: Nping +.\" Language: English +.\" +.TH "NPING" "1" "05/17/2023" "Nping" "Nping Reference Guide" +.\" ----------------------------------------------------------------- +.\" * Define some portability stuff +.\" ----------------------------------------------------------------- +.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.\" http://bugs.debian.org/507673 +.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html +.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.ie \n(.g .ds Aq \(aq +.el .ds Aq ' +.\" ----------------------------------------------------------------- +.\" * set default formatting +.\" ----------------------------------------------------------------- +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.\" ----------------------------------------------------------------- +.\" * MAIN CONTENT STARTS HERE * +.\" ----------------------------------------------------------------- +.SH "NAME" +nping \- Network packet generation tool / ping utility +.SH "SYNOPSIS" +.HP \w'\fBnping\fR\ 'u +\fBnping\fR [\fIOptions\fR] {\fItargets\fR} +.SH "DESCRIPTION" +.PP +Nping is an open\-source tool for network packet generation, response analysis and response time measurement\&. Nping allows users to generate network packets of a wide range of protocols, letting them 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, and other purposes\&. +.PP +Additionally, Nping offers a special mode of operation called the "Echo Mode", that lets users see how the generated probes change in transit, revealing the differences between the transmitted packets and the packets received at the other end\&. See section "Echo Mode" for details\&. +.PP +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\&. +.PP +A typical Nping execution is shown in +Example\ \&1\&. The only Nping arguments used in this example are +\fB\-c\fR, to specify the number of times to target each host, +\fB\-\-tcp\fR +to specify TCP Probe Mode, +\fB\-p 80,433\fR +to specify the target ports; and then the two target hostnames\&. +.PP +\fBExample\ \&1.\ \&A representative Nping execution\fR +.sp +.if n \{\ +.RS 4 +.\} +.nf +# \fBnping \-c 1 \-\-tcp \-p 80,433 scanme\&.nmap\&.org google\&.com\fR + +Starting Nping ( https://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 +.fi +.if n \{\ +.RE +.\} +.PP +The newest version of Nping can be obtained with Nmap at +\m[blue]\fB\%https://nmap.org\fR\m[]\&. The newest version of this man page is available at +\m[blue]\fB\%https://nmap.org/book/nping-man.html\fR\m[]\&. + +\-\-> + .SH "OPTIONS SUMMARY" +.PP +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\*(Aqt even included here\&. +.sp +.if n \{\ +.RS 4 +.\} +.nf +Nping 0\&.7\&.92SVN ( https://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\&.*\&.1\-24 +PROBE MODES: + \-\-tcp\-connect : Unprivileged TCP connect probe mode\&. + \-\-tcp : TCP probe mode\&. + \-\-udp : UDP 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)\&. + \-g, \-\-source\-port <portnumber> : Try to use a custom source port\&. +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\&. +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 Don\*(Aqt Fragment flag\&. + \-\-mf : Set More Fragments flag\&. + \-\-evil : Set Reserved / Evil flag\&. + \-\-ttl <hops> : Set time to live [0\-255]\&. + \-\-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 : Set hop limit (same as IPv4 TTL)\&. + \-\-traffic\-class <class> : : Set traffic class\&. + \-\-flow <label> : Set 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\-length <len> : Include len random bytes as payload\&. +ECHO CLIENT/SERVER: + \-\-echo\-client <passphrase> : Run Nping in client mode\&. + \-\-echo\-server <passphrase> : Run Nping in server mode\&. + \-\-echo\-port <port> : Use custom <port> to listen or connect\&. + \-\-no\-crypto : Disable encryption and authentication\&. + \-\-once : Stop the server after one connection\&. + \-\-safe\-payloads : Erase application data in echoed packets\&. +TIMING AND PERFORMANCE: + Options which take <time> are in seconds, or append \*(Aqms\*(Aq (milliseconds), + \*(Aqs\*(Aq (seconds), \*(Aqm\*(Aq (minutes), or \*(Aqh\*(Aq (hours) to the value (e\&.g\&. 30m, 0\&.25h)\&. + \-\-delay <time> : Adjust delay between probes\&. + \-\-rate <rate> : Send num packets per second\&. +MISC: + \-h, \-\-help : Display help information\&. + \-V, \-\-version : Display 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 : Set verbosity and debug level to minimum\&. + \-\-debug : Set 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 time \-\-delay 500ms 192\&.168\&.254\&.254 + nping \-\-echo\-server "public" \-e wlan0 \-vvv + nping \-\-echo\-client "public" echo\&.nmap\&.org \-\-tcp \-p1\-1024 \-\-flags ack + +SEE THE MAN PAGE FOR MANY MORE OPTIONS, DESCRIPTIONS, AND EXAMPLES + +.fi +.if n \{\ +.RE +.\} +.SH "TARGET SPECIFICATION" +.PP +Everything on the Nping command line that isn\*(Aqt an option or an option argument is treated as a target host specification\&. Nping uses the same syntax for target specifications that Nmap does\&. The simplest case is a single target given by IP address or hostname\&. +.PP +Nping supports CIDR\-style +addressing\&. You can append +/\fInumbits\fR +to an IPv4 address or hostname and Nping will send probes to every IP address for which the first +\fInumbits\fR +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\&. +.PP +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\*(Aqt 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\&. +.PP +IPv6 addresses can only be specified by their fully qualified IPv6 address or hostname\&. CIDR and octet ranges aren\*(Aqt supported for IPv6 because they are rarely useful\&. +.PP +Nping accepts multiple host specifications on the command line, and they don\*(Aqt need to be the same type\&. The command +\fBnping scanme\&.nmap\&.org 192\&.168\&.0\&.0/8 10\&.0\&.0,1,3\-7\&.\-\fR +does what you would expect\&. +.SH "OPTION SPECIFICATION" +.PP +Nping is designed to be very flexible and fit a wide variety of needs\&. As with most command\-line tools, its behavior can be adjusted using command\-line options\&. These general principles apply to option arguments, unless stated otherwise\&. +.PP +Options that take integer numbers can accept values specified in decimal, octal or hexadecimal base\&. When a number starts with +0x, it will be treated as hexadecimal; when it simply starts with +0, it will be treated as octal\&. Otherwise, Nping will assume the number has been specified in base 10\&. Virtually all numbers that can be supplied from the command line are unsigned so, as a general rule, the minimum value is zero\&. Users may also specify the word +random +or +rand +to make Nping generate a random value within the expected range\&. +.PP +IP addresses may be given as IPv4 addresses (e\&.g\&. +192\&.168\&.1\&.1), IPv6 addresses (e\&.g\&. +2001:db8:85a3::8e4c:760:7146), or hostnames, which will be resolved using the default DNS server configured in the host system\&. +.PP +Options that take MAC addresses accept the usual colon\-separated 6 hex byte format (e\&.g\&. +00:50:56:d4:01:98)\&. Hyphens may also be used instead of colons (e\&.g\&. +00\-50\-56\-c0\-00\-08)\&. The special word +random +or +rand +sets a random address and the word +broadcast +or +bcast +sets ff:ff:ff:ff:ff:ff\&. +.SH "GENERAL OPERATION" +.PP +Unlike other ping and packet generation tools, Nping supports multiple target host and port specifications\&. 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\&. +.PP +When multiple target hosts are specified, Nping rotates among them in round\-robin fashion\&. This gives slow hosts more time to send their responses before another probe is sent to them\&. 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\&. +.PP +The loop around targets is the +\(lqinner loop\(rq +and the loop around ports is the +\(lqouter loop\(rq\&. All targets will be sent a probe for a given port before moving on to the next port\&. Between probes, Nping waits a configurable amount of time called the +\(lqinter\-probe delay\(rq, which is controlled by the +\fB\-\-delay\fR +option\&. These examples show how it works\&. +.PP +.PP One target, three ports, and two rounds\&. +.RS 4 +.sp +.if n \{\ +.RS 4 +.\} +.nf +# \fBnping \-\-tcp \-c 2 1\&.1\&.1\&.1 \-p 100\-102\fR + +Starting Nping ( https://nmap\&.org/nping ) +SENT (0\&.0210s) TCP 192\&.168\&.1\&.77 > 1\&.1\&.1\&.1:100 +SENT (1\&.0230s) TCP 192\&.168\&.1\&.77 > 1\&.1\&.1\&.1:101 +SENT (2\&.0250s) TCP 192\&.168\&.1\&.77 > 1\&.1\&.1\&.1:102 +SENT (3\&.0280s) TCP 192\&.168\&.1\&.77 > 1\&.1\&.1\&.1:100 +SENT (4\&.0300s) TCP 192\&.168\&.1\&.77 > 1\&.1\&.1\&.1:101 +SENT (5\&.0320s) TCP 192\&.168\&.1\&.77 > 1\&.1\&.1\&.1:102 +.fi +.if n \{\ +.RE +.\} +.RE +.PP +.PP Three targets, one port, and two rounds\&. +.RS 4 +.sp +.if n \{\ +.RS 4 +.\} +.nf +# \fBnping \-\-tcp \-c 2 1\&.1\&.1\&.1 2\&.2\&.2\&.2 3\&.3\&.3\&.3 \-p 8080\fR + +Starting Nping ( https://nmap\&.org/nping ) +SENT (0\&.0230s) TCP 192\&.168\&.0\&.21 > 1\&.1\&.1\&.1:8080 +SENT (1\&.0240s) TCP 192\&.168\&.0\&.21 > 2\&.2\&.2\&.2:8080 +SENT (2\&.0260s) TCP 192\&.168\&.0\&.21 > 3\&.3\&.3\&.3:8080 +SENT (3\&.0270s) TCP 192\&.168\&.0\&.21 > 1\&.1\&.1\&.1:8080 +SENT (4\&.0290s) TCP 192\&.168\&.0\&.21 > 2\&.2\&.2\&.2:8080 +SENT (5\&.0310s) TCP 192\&.168\&.0\&.21 > 3\&.3\&.3\&.3:8080 +.fi +.if n \{\ +.RE +.\} +.RE +.PP +.PP Three hosts, three ports, one round, inter\-probe delay of 500\ \&ms\&. +.RS 4 +.sp +.if n \{\ +.RS 4 +.\} +.nf +# \fBnping \-\-tcp \-c 1 \-\-delay 500ms 1\&.1\&.1\&.1 2\&.2\&.2\&.2 3\&.3\&.3\&.3 \-p 137\-139\fR + +Starting Nping ( https://nmap\&.org/nping ) +SENT (0\&.0230s) TCP 192\&.168\&.0\&.21 > 1\&.1\&.1\&.1:137 +SENT (0\&.5250s) TCP 192\&.168\&.0\&.21 > 2\&.2\&.2\&.2:137 +SENT (1\&.0250s) TCP 192\&.168\&.0\&.21 > 3\&.3\&.3\&.3:137 +SENT (1\&.5280s) TCP 192\&.168\&.0\&.21 > 1\&.1\&.1\&.1:138 +SENT (2\&.0280s) TCP 192\&.168\&.0\&.21 > 2\&.2\&.2\&.2:138 +SENT (2\&.5310s) TCP 192\&.168\&.0\&.21 > 3\&.3\&.3\&.3:138 +SENT (3\&.0300s) TCP 192\&.168\&.0\&.21 > 1\&.1\&.1\&.1:139 +SENT (3\&.5330s) TCP 192\&.168\&.0\&.21 > 2\&.2\&.2\&.2:139 +SENT (4\&.0330s) TCP 192\&.168\&.0\&.21 > 3\&.3\&.3\&.3:139 +.fi +.if n \{\ +.RE +.\} +.RE +.SH "PROBE MODES" +.PP +Nping supports a wide variety of protocols\&. Although in some cases Nping can automatically determine the mode from the options used, it is generally a good idea to specify it explicitly\&. +.PP +\fB\-\-tcp\-connect\fR (TCP Connect mode) +.RS 4 +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\&. +.RE +.PP +\fB\-\-tcp\fR (TCP mode) +.RS 4 +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\*(Aqt 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\*(Aqs 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 a non\-RFC\-compliant packet, like one 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\&. +.RE +.PP +\fB\-\-udp\fR (UDP mode) +.RS 4 +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 unprivileged UDP 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\&. Examples are DNS servers, streaming servers, online gaming servers, and port knocking/single\-packet +authorization daemons\&. +.RE +.PP +\fB\-\-icmp\fR (ICMP mode) +.RS 4 +ICMP mode is the default mode when the user runs Nping with raw packet privileges\&. Any kind of ICMP message can be created\&. The default ICMP type is Echo, i\&.e\&., ping\&. 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, and router advertisements\&. +.RE +.PP +\fB\-\-arp\fR (ARP/RARP mode) +.RS 4 +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, and conduct ARP\-cache poisoning attacks\&. +.RE +.PP +\fB\-\-traceroute\fR (Traceroute mode) +.RS 4 +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 take until they reach their final destination\&. +.RE +.SH "TCP CONNECT MODE" +.PP +\fB\-p \fR\fB\fIport_spec\fR\fR, \fB\-\-dest\-port \fR\fB\fIport_spec\fR\fR (Target ports) +.RS 4 +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\&. +.RE +.PP +\fB\-g \fR\fB\fIportnumber\fR\fR, \fB\-\-source\-port \fR\fB\fIportnumber\fR\fR (Spoof source port) +.RS 4 +This option asks Nping to use the specified port as source port for the TCP connections\&. Note that this might not work on all systems or may require root privileges\&. Specified value must be an integer in the range [0\(en65535]\&. +.RE +.SH "TCP MODE" +.PP +\fB\-p \fR\fB\fIport_spec\fR\fR, \fB\-\-dest\-port \fR\fB\fIport_spec\fR\fR (Target ports) +.RS 4 +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\&. +.RE +.PP +\fB\-g \fR\fB\fIportnumber\fR\fR, \fB\-\-source\-port \fR\fB\fIportnumber\fR\fR (Spoof source port) +.RS 4 +This option asks Nping to use the specified port as source port for the TCP connections\&. Note that this might not work on all systems or may require root privileges\&. Specified value must be an integer in the range [0\(en65535]\&. +.RE +.PP +\fB\-\-seq \fR\fB\fIseqnumber\fR\fR (Sequence Number) +.RS 4 +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\&. +\fIseqnumber\fR +must be a number in the range [0\(en4294967295]\&. +.RE +.PP +\fB\-\-flags \fR\fB\fIflags\fR\fR (TCP Flags) +.RS 4 +This option specifies which flags should be set in the TCP packet\&. +\fIflags\fR +may be specified in three different ways: +.sp +.RS 4 +.ie n \{\ +\h'-04' 1.\h'+01'\c +.\} +.el \{\ +.sp -1 +.IP " 1." 4.2 +.\} +As a comma\-separated list of flags, e\&.g\&. +\fB\-\-flags syn,ack,rst\fR +.RE +.sp +.RS 4 +.ie n \{\ +\h'-04' 2.\h'+01'\c +.\} +.el \{\ +.sp -1 +.IP " 2." 4.2 +.\} +As a list of one\-character flag initials, e\&.g\&. +\fB\-\-flags SAR\fR +tells Nping to set flags SYN, ACK, and RST\&. +.RE +.sp +.RS 4 +.ie n \{\ +\h'-04' 3.\h'+01'\c +.\} +.el \{\ +.sp -1 +.IP " 3." 4.2 +.\} +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\(en0xFF], e\&.g\&. +\-\-flags 0x20 +sets the URG flag as 0x20 corresponds to binary 00100000 and the URG flag is represented by the third bit\&. +.RE +.sp +There are 8 possible flags to set: +CWR, +ECN, +URG, +ACK, +PSH, +RST, +SYN, and +FIN\&. The special value +ALL +means to set all flags\&. +NONE +means to set no flags\&. It is important that if you don\*(Aqt want any flag to be set, you request it explicitly because in some cases the SYN flag may be set by default\&. Here is a brief description of the meaning of each flag: +.PP +CWR (Congestion Window Reduced) +.RS 4 +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\&. +.RE +.PP +ECN (Explicit Congestion Notification) +.RS 4 +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\&. +.RE +.PP +URG (Urgent) +.RS 4 +Segment is urgent and the urgent pointer field carries valid information\&. +.RE +.PP +ACK (Acknowledgement) +.RS 4 +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\&. +.RE +.PP +PSH (Push) +.RS 4 +The data in this segment should be immediately pushed to the application layer on arrival\&. +.RE +.PP +RST (Reset) +.RS 4 +There was some problem and the sender wants to abort the connection\&. +.RE +.PP +SYN (Synchronize) +.RS 4 +The segment is a request to synchronize sequence numbers and establish a connection\&. The sequence number field contains the sender\*(Aqs initial sequence number\&. +.RE +.PP +FIN (Finish) +.RS 4 +The sender wants to close the connection\&. +.RE +.RE +.PP +\fB\-\-win \fR\fB\fIsize\fR\fR (Window Size) +.RS 4 +Specifies the TCP window size, this is, the number of octets 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\&. +\fIsize\fR +must be a number in the range [0\(en65535]\&. +.RE +.PP +\fB\-\-badsum\fR (Invalid Checksum) +.RS 4 +Asks Nping to use an invalid TCP checksum for the 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\*(Aqt bother to verify the checksum\&. For more details on this technique, see +\m[blue]\fB\%https://nmap.org/p60-12.html\fR\m[]\&. +.RE +.SH "UDP MODE" +.PP +\fB\-p \fR\fB\fIport_spec\fR\fR, \fB\-\-dest\-port \fR\fB\fIport_spec\fR\fR (Target ports) +.RS 4 +This option specifies which ports you want UDP datagrams to be sent 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\&. +.RE +.PP +\fB\-g \fR\fB\fIportnumber\fR\fR, \fB\-\-source\-port \fR\fB\fIportnumber\fR\fR (Spoof source port) +.RS 4 +This option asks Nping to use the specified port as source port for the transmitted datagrams\&. Note that this might not work on all systems or may require root privileges\&. Specified value must be an integer in the range [0\(en65535]\&. +.RE +.PP +\fB\-\-badsum\fR (Invalid Checksum) +.RS 4 +Asks Nping to use an invalid UDP checksum for the 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\*(Aqt bother to verify the checksum\&. For more details on this technique, see +\m[blue]\fB\%https://nmap.org/p60-12.html\fR\m[]\&. +.RE +.SH "ICMP MODE" +.PP +\fB\-\-icmp\-type \fR\fB\fItype\fR\fR (ICMP type) +.RS 4 +This option specifies which type of ICMP messages should be generated\&. +\fItype\fR +can be supplied in two different ways\&. You can use the +\m[blue]\fBofficial type numbers assigned by IANA\fR\m[]\&\s-2\u[1]\d\s+2 +(e\&.g\&. +\fB\-\-icmp\-type 8\fR +for ICMP Echo Request), or you can use any of the mnemonics listed in +the section called \(lqICMP Types\(rq\&. +.RE +.PP +\fB\-\-icmp\-code \fR\fB\fIcode\fR\fR (ICMP code) +.RS 4 +This option specifies which ICMP code should be included in the generated ICMP messages\&. +\fIcode\fR +can be supplied in two different ways\&. You can use the +\m[blue]\fBofficial code numbers assigned by IANA\fR\m[]\&\s-2\u[1]\d\s+2 +(e\&.g\&. +\fB\-\-icmp\-code 1\fR +for Fragment Reassembly Time Exceeded), or you can use any of the mnemonics listed in +the section called \(lqICMP Codes\(rq\&. +.RE +.PP +\fB\-\-icmp\-id \fR\fB\fIid\fR\fR (ICMP identifier) +.RS 4 +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\&. +\fIid\fR +must be a number in the range [0\(en65535]\&. +.RE +.PP +\fB\-\-icmp\-seq \fR\fB\fIseq\fR\fR (ICMP sequence) +.RS 4 +This option specifies the value of the sequence number field used in some ICMP messages\&. In general it is used to match request and reply messages\&. +\fIid\fR +must be a number in the range [0\(en65535]\&. +.RE +.PP +\fB\-\-icmp\-redirect\-addr \fR\fB\fIaddr\fR\fR (ICMP Redirect address) +.RS 4 +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\&. +\fIaddr\fR +can be either an IPv4 address or a hostname\&. +.RE +.PP +\fB\-\-icmp\-param\-pointer \fR\fB\fIpointer\fR\fR (ICMP Parameter Problem pointer) +.RS 4 +This option specifies the pointer that indicates the location of the problem in ICMP Parameter Problem messages\&. +\fIpointer\fR +should be a number in the range [0\(en255]\&. Normally this option is only used when ICMP code is set to 0 ("Pointer indicates the error")\&. +.RE +.PP +\fB\-\-icmp\-advert\-lifetime \fR\fB\fIttl\fR\fR (ICMP Router Advertisement Lifetime) +.RS 4 +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\&. +\fIttl\fR +must be a positive integer in the range [0\(en65535]\&. +.RE +.PP +\fB\-\-icmp\-advert\-entry \fR\fB\fIaddr\fR\fR\fB,\fR\fB\fIpref\fR\fR (ICMP Router Advertisement Entry) +.RS 4 +This option adds a Router Advertisement entry to an ICMP Router Advertisement message\&. The parameter must be two values separated by a comma\&. +\fIaddr\fR +is the router\*(Aqs IP and can be specified either as an IP address in dot\-decimal notation or as a hostname\&. +\fIpref\fR +is the preference level for the specified IP\&. It must be a number in the range [0\(en4294967295]\&. An example is +\fB\-\-icmp\-advert\-entry 192\&.168\&.128\&.1,3\fR\&. +.RE +.PP +\fB\-\-icmp\-orig\-time \fR\fB\fItimestamp\fR\fR (ICMP Originate Timestamp) +.RS 4 +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\&. +\fItimestamp\fR +can be specified as a regular time (e\&.g\&. +10s, +3h, +1000ms), or the special string +now\&. You can add or subtract values from +now, for example +\fB\-\-icmp\-orig\-time now\-2s\fR, +\fB\-\-icmp\-orig\-time now+1h\fR, +\fB\-\-icmp\-orig\-time now+200ms\fR\&. +.RE +.PP +\fB\-\-icmp\-recv\-time \fR\fB\fItimestamp\fR\fR (ICMP Receive Timestamp) +.RS 4 +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\&. +\fItimestamp\fR +is as with +\fB\-\-icmp\-orig\-time\fR\&. +.RE +.PP +\fB\-\-icmp\-trans\-time \fR\fB\fItimestamp\fR\fR (ICMP Transmit Timestamp) +.RS 4 +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\&. +\fItimestamp\fR +is as with +\fB\-\-icmp\-orig\-time\fR\&. +.RE +.SS "ICMP Types" +.PP +These identifiers may be used as mnemonics for the ICMP type numbers given to the +\fB\-\-icmp\-type\fR +option\&. In general there are three forms of each identifier: the full name (e\&.g\&. +destination\-unreachable), the short name (e\&.g\&. +dest\-unr), or the initials (e\&.g\&. +du)\&. In ICMP types that request something, the word "request" is omitted\&. +.PP +echo\-reply, echo\-rep, er +.RS 4 +Echo Reply (type 0)\&. This message is sent in response to an Echo Request message\&. +.RE +.PP +destination\-unreachable, dest\-unr, du +.RS 4 +Destination Unreachable (type 3)\&. This message indicates that a datagram could not be delivered to its destination\&. +.RE +.PP +source\-quench, sour\-que, sq +.RS 4 +Source Quench (type 4)\&. 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\&. +.RE +.PP +redirect, redi, r +.RS 4 +Redirect (type 5)\&. This message is normally used by routers to inform a host that there is a better route to use for sending datagrams\&. See also the +\fB\-\-icmp\-redirect\-addr\fR +option\&. +.RE +.PP +echo\-request, echo, e +.RS 4 +Echo Request (type 8)\&. This message is used to test the connectivity of another device on a network\&. +.RE +.PP +router\-advertisement, rout\-adv, ra +.RS 4 +Router Advertisement (type 9)\&. This message is used by routers to let hosts know of their existence and capabilities\&. See also the +\fB\-\-icmp\-advert\-lifetime\fR +option\&. +.RE +.PP +router\-solicitation, rout\-sol, rs +.RS 4 +Router Solicitation (type 10)\&. This message is used by hosts to request Router Advertisement messages from any listening routers\&. +.RE +.PP +time\-exceeded, time\-exc, te +.RS 4 +Time Exceeded (type 11)\&. 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 TTL expired\&. +.RE +.PP +parameter\-problem, member\-pro, pp +.RS 4 +Parameter Problem (type 12)\&. This message is used when a device finds a problem with a parameter in an IP header and it cannot continue processing it\&. See also the +\fB\-\-icmp\-param\-pointer\fR +option\&. +.RE +.PP +timestamp, time, tm +.RS 4 +Timestamp Request (type 13)\&. This message is used to request a device to send a timestamp value for propagation time calculation and clock synchronization\&. See also the +\fB\-\-icmp\-orig\-time\fR, +\fB\-\-icmp\-recv\-time\fR, and +\fB\-\-icmp\-trans\-time\fR\&. +.RE +.PP +timestamp\-reply, time\-rep, tr +.RS 4 +Timestamp Reply (type 14)\&. This message is sent in response to a Timestamp Request message\&. +.RE +.PP +information, info, i +.RS 4 +Information Request (type 15)\&. This message is now obsolete but it was originally used to request configuration information from another device\&. +.RE +.PP +information\-reply, info\-rep, ir +.RS 4 +Information Reply (type 16)\&. This message is now obsolete but it was originally sent in response to an Information Request message to provide configuration information\&. +.RE +.PP +mask\-request, mask, m +.RS 4 +Address Mask Request (type 17)\&. This message is used to ask a device to send its subnet mask\&. +.RE +.PP +mask\-reply, mask\-rep, mr +.RS 4 +Address Mask Reply (type 18)\&. This message contains a subnet mask and is sent in response to a Address Mask Request message\&. +.RE +.PP +traceroute, trace, tc +.RS 4 +Traceroute (type 30)\&. 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\&. +.RE +.SS "ICMP Codes" +.PP +These identifiers may be used as mnemonics for the ICMP code numbers given to the +\fB\-\-icmp\-code\fR +option\&. They are listed by the ICMP type they correspond to\&. +.sp +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBDestination Unreachable\fR +.RS 4 +.PP +network\-unreachable, netw\-unr, net +.RS 4 +Code 0\&. Datagram could not be delivered to its destination network (probably due to some routing problem)\&. +.RE +.PP +host\-unreachable, host\-unr, host +.RS 4 +Code 1\&. Datagram was delivered to the destination network but it was impossible to reach the specified host (probably due to some routing problem)\&. +.RE +.PP +protocol\-unreachable, prot\-unr, proto +.RS 4 +Code 2\&. The protocol specified in the Protocol field of the IP datagram is not supported by the host to which the datagram was delivered\&. +.RE +.PP +port\-unreachable, port\-unr, port +.RS 4 +Code 3\&. The TCP/UDP destination port was invalid\&. +.RE +.PP +needs\-fragmentation, need\-fra, frag +.RS 4 +Code 4\&. 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\&. +.RE +.PP +source\-route\-failed, sour\-rou, routefail +.RS 4 +Code 5\&. IP datagram had a Source Route option but a router couldn\*(Aqt pass it to the next hop\&. +.RE +.PP +network\-unknown, netw\-unk, net? +.RS 4 +Code 6\&. Destination network is unknown\&. This code is never used\&. Instead, Network Unreachable is used\&. +.RE +.PP +host\-unknown, host\-unk, host? +.RS 4 +Code 7\&. Specified host is unknown\&. Usually generated by a router local to the destination host to inform of a bad address\&. +.RE +.PP +host\-isolated, host\-iso, isolated +.RS 4 +Code 8\&. Source Host Isolated\&. Not used\&. +.RE +.PP +network\-prohibited, netw\-pro, !net +.RS 4 +Code 9\&. Communication with destination network is administratively prohibited (source device is not allowed to send packets to the destination network)\&. +.RE +.PP +host\-prohibited, host\-pro, !host +.RS 4 +Code 10\&. Communication with destination host is administratively prohibited\&. (The source device is allowed to send packets to the destination network but not to the destination device\&.) +.RE +.PP +network\-tos, unreachable\-network\-tos, netw\-tos, tosnet +.RS 4 +Code 11\&. Destination network unreachable because it cannot provide the type of service specified in the IP TOS field\&. +.RE +.PP +host\-tos, unreachable\-host\-tos, toshost +.RS 4 +Code 12\&. Destination host unreachable because it cannot provide the type of service specified in the IP TOS field\&. +.RE +.PP +communication\-prohibited, comm\-pro, !comm +.RS 4 +Code 13\&. Datagram could not be forwarded due to filtering that blocks the message based on its contents\&. +.RE +.PP +host\-precedence\-violation, precedence\-violation, prec\-vio, violation +.RS 4 +Code 14\&. Precedence value in the IP TOS field is not permitted\&. +.RE +.PP +precedence\-cutoff, prec\-cut, cutoff +.RS 4 +Code 15\&. Precedence value in the IP TOS field is lower than the minimum allowed for the network\&. +.RE +.RE +.sp +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBRedirect\fR +.RS 4 +.PP +redirect\-network, redi\-net, net +.RS 4 +Code 0\&. 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\&. +.RE +.PP +redirect\-host, redi\-host, host +.RS 4 +Code 1\&. Redirect all future datagrams with the same destination host as the original datagram, to the router specified in the Address field\&. +.RE +.PP +redirect\-network\-tos, redi\-ntos, redir\-ntos +.RS 4 +Code 2\&. 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\&. +.RE +.PP +redirect\-host\-tos, redi\-htos, redir\-htos +.RS 4 +Code 3\&. 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\&. +.RE +.RE +.sp +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBRouter Advertisement\fR +.RS 4 +.PP +normal\-advertisement, norm\-adv, normal, zero, default, def +.RS 4 +Code 0\&. Normal router advertisement\&. In Mobile IP: Mobility agent can act as a router for IP datagrams not related to mobile nodes\&. +.RE +.PP +not\-route\-common\-traffic, not\-rou, mobile\-ip, !route, !commontraffic +.RS 4 +Code 16\&. 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 +.RE +.RE +.sp +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBTime Exceeded\fR +.RS 4 +.PP +ttl\-exceeded\-in\-transit, ttl\-exc, ttl\-transit +.RS 4 +Code 0\&. IP Time To Live expired during transit\&. +.RE +.PP +fragment\-reassembly\-time\-exceeded, frag\-exc, frag\-time +.RS 4 +Code 1\&. Fragment reassembly time has been exceeded\&. +.RE +.RE +.sp +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBParameter Problem\fR +.RS 4 +.PP +pointer\-indicates\-error, poin\-ind, pointer +.RS 4 +Code 0\&. The pointer field indicates the location of the problem\&. See the +\fB\-\-icmp\-param\-pointer\fR +option\&. +.RE +.PP +missing\-required\-option, miss\-option, option\-missing +.RS 4 +Code 1\&. IP datagram was expected to have an option that is not present\&. +.RE +.PP +bad\-length, bad\-len, badlen +.RS 4 +Code 2\&. The length of the IP datagram is incorrect\&. +.RE +.RE +.SH "ARP MODE" +.PP +\fB\-\-arp\-type \fR\fB\fItype\fR\fR (ICMP Type) +.RS 4 +This option specifies which type of ARP messages should be generated\&. +\fItype\fR +can be supplied in two different ways\&. You can use the +\m[blue]\fBofficial numbers assigned by IANA\fR\m[]\&\s-2\u[2]\d\s+2 +(e\&.g\&. +\fB\-\-arp\-type 1\fR +for ARP Request), or you can use one of the mnemonics from +the section called \(lqARP Types\(rq\&. +.RE +.PP +\fB\-\-arp\-sender\-mac \fR\fB\fImac\fR\fR (Sender MAC address) +.RS 4 +This option sets the Sender Hardware Address field of the ARP header\&. Although ARP supports many types of link layer addresses, currently Nping only supports MAC addresses\&. +\fImac\fR +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)\&. +.RE +.PP +\fB\-\-arp\-sender\-ip \fR\fB\fIaddr\fR\fR (Sender IP address) +.RS 4 +This option sets the Sender IP field of the ARP header\&. +\fIaddr\fR +can be given as an IPv4 address or a hostname\&. +.RE +.PP +\fB\-\-arp\-target\-mac \fR\fB\fImac\fR\fR (target MAC address) +.RS 4 +This option sets the Target Hardware Address field of the ARP header\&. +.RE +.PP +\fB\-\-arp\-target\-ip \fR\fB\fIaddr\fR\fR (target ip address) +.RS 4 +This option sets the Target IP field of the ARP header\&. +.RE +.SS "ARP Types" +.PP +These identifiers may be used as mnemonics for the ARP type numbers given to the +\fB\-\-arp\-type\fR +option\&. +.PP +arp\-request, arp, a +.RS 4 +ARP Request (type 1)\&. 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\&. +.RE +.PP +arp\-reply, arp\-rep, ar +.RS 4 +ARP Reply (type 2)\&. An ARP reply is a message that a host sends in response to an ARP request to provide its link layer address\&. +.RE +.PP +rarp\-request, rarp, r +.RS 4 +RARP Requests (type 3)\&. 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\*(Aqt 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\&. +.RE +.PP +rarp\-reply, rarp\-rep, rr +.RS 4 +RARP Reply (type 4)\&. 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\&. +.RE +.PP +drarp\-request, drarp, d +.RS 4 +Dynamic RARP Request (type 5)\&. 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\*(Aqs but now it\*(Aqs no longer used\&. See RFC 1931 +for more information\&. +.RE +.PP +drarp\-reply, drarp\-rep, dr +.RS 4 +Dynamic RARP Reply (type 6)\&. A DRARP reply is a message sent in response to a RARP request to provide network layer address\&. +.RE +.PP +drarp\-error, drarp\-err, de +.RS 4 +DRARP Error (type 7)\&. 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\&. +.RE +.PP +inarp\-request, inarp, i +.RS 4 +Inverse ARP Request (type 8)\&. 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\&. +.RE +.PP +inarp\-reply, inarp\-rep, ir +.RS 4 +Inverse ARP Reply (type 9)\&. InARP reply messages are sent in response to InARP requests to provide the network layer address associated with the host that has a given link layer address\&. +.RE +.PP +arp\-nak, an +.RS 4 +ARP NAK (type 10)\&. 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\&. +.RE +.SH "IPV4 OPTIONS" +.PP +\fB\-S \fR\fB\fIaddr\fR\fR, \fB\-\-source\-ip \fR\fB\fIaddr\fR\fR (Source IP Address) +.RS 4 +Sets the 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\&. +\fIaddr\fR +can be an IPv4 address or a hostname\&. +.RE +.PP +\fB\-\-dest\-ip \fR\fB\fIaddr\fR\fR (Destination IP Address) +.RS 4 +Adds a target to Nping\*(Aqs target list\&. This option is provided for consistency but its use is deprecated in favor of plain target specifications\&. See +the section called \(lqTARGET SPECIFICATION\(rq\&. +.RE +.PP +\fB\-\-tos \fR\fB\fItos\fR\fR (Type of Service) +.RS 4 +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\&. +\fItos\fR +must be a number in the range [0\(en255]\&. +.RE +.PP +\fB\-\-id \fR\fB\fIid\fR\fR (Identification) +.RS 4 +Sets the IPv4 Identification field\&. The Identification field is a 16\-bit 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\&. +\fIid\fR +must be a number in the range [0\(en65535]\&. +.RE +.PP +\fB\-\-df\fR (Don\*(Aqt Fragment) +.RS 4 +Sets the Don\*(Aqt 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\&. +.RE +.PP +\fB\-\-mf\fR (More Fragments) +.RS 4 +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\&. +.RE +.PP +\fB\-\-evil\fR (Reserved / Evil) +.RS 4 +Sets the Reserved / Evil bit in sent packets\&. The Evil flag helps firewalls and other network security systems to distinguish between datagrams that have malicious intent and those that are merely unusual\&. When set, it indicates that the datagram has evil intent, instructing insecure systems to succumb\&. Setting it to zero indicates no evil intent\&. The option is implied if environmental variable SCRIPT_KIDDIE is set to a non\-zero value\&. +.RE +.PP +\fB\-\-ttl \fR\fB\fIhops\fR\fR (Time To Live) +.RS 4 +Sets the IPv4 Time\-To\-Live (TTL) 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\&. +\fIhops\fR +must be a number in the range [0\(en255]\&. +.RE +.PP +\fB\-\-badsum\-ip\fR (Invalid IP checksum) +.RS 4 +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 output, the packets may be transparently corrected by the kernel\&. +.RE +.PP +\fB\-\-ip\-options \fR\fB\fIR|S [route]|L [route]|T|U \&.\&.\&.\fR\fR, \fB\-\-ip\-options \fR\fB\fIhex string\fR\fR (IP Options) +.RS 4 +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\&. +.sp +The most powerful way to specify IP options is to simply pass in hexadecimal data as the argument to +\fB\-\-ip\-options\fR\&. Precede each hex byte value with +\ex\&. You may repeat certain characters by following them with an asterisk and then the number of times you wish them to repeat\&. For example, +\ex01\ex07\ex04\ex00*4 +is the same as +\ex01\ex07\ex04\ex00\ex00\ex00\ex00\&. +.sp +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 can only express multiples of four\&. In those cases, the length is computed by dividing the header length by 4 and rounding down\&. 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\&. +.sp +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\&. +.sp +For more information and examples of using IP options with Nping, see the mailing list post at +\m[blue]\fB\%https://seclists.org/nmap-dev/2006/q3/0052.html\fR\m[]\&. +.RE +.PP +\fB\-\-mtu \fR\fB\fIsize\fR\fR (Maximum Transmission Unit) +.RS 4 +This option sets a fictional MTU in Nping so IP datagrams larger than +\fIsize\fR +are fragmented before transmission\&. +\fIsize\fR +must be specified in bytes and corresponds to the number of octets that can be carried on a single link\-layer frame\&. +.RE +.SH "IPV6 OPTIONS" +.PP +\fB\-6\fR, \fB\-\-ipv6\fR (Use IPv6) +.RS 4 +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 +\fB\-6\fR +option\&. Of course, you must use IPv6 syntax if you specify an address rather than a hostname\&. An address might look like +\fB3ffe:7501:4819:2000:210:f3ff:fe03:14d0\fR, so hostnames are recommended\&. +.sp +While IPv6 hasn\*(Aqt 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 +\m[blue]\fB\%http://www.tunnelbroker.net\fR\m[]\&. +.sp +Please note that IPv6 support is still highly experimental and many modes and options may not work with it\&. +.RE +.PP +\fB\-S \fR\fB\fIaddr\fR\fR, \fB\-\-source\-ip \fR\fB\fIaddr\fR\fR (Source IP Address) +.RS 4 +Sets the 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\&. +\fIaddr\fR +can be an IPv6 address or a hostname\&. +.RE +.PP +\fB\-\-dest\-ip \fR\fB\fIaddr\fR\fR (Destination IP Address) +.RS 4 +Adds a target to Nping\*(Aqs target list\&. This option is provided for consistency but its use is deprecated in favor of plain target specifications\&. See +the section called \(lqTARGET SPECIFICATION\(rq\&. +.RE +.PP +\fB\-\-flow \fR\fB\fIlabel\fR\fR (Flow Label) +.RS 4 +Sets the IPv6 Flow Label\&. The Flow Label field is 20 bits long and is intended to provide certain quality\-of\-service properties for real\-time datagram delivery\&. However, it has not been widely adopted, and not all routers or endpoints support it\&. Check RFC 2460 +for more information\&. +\fIlabel\fR +must be an integer in the range [0\(en1048575]\&. +.RE +.PP +\fB\-\-traffic\-class \fR\fB\fIclass\fR\fR (Traffic Class) +.RS 4 +Sets the IPv6 Traffic Class\&. This field is similar to the TOS field in IPv4, and is intended to provide the Differentiated Services method, enabling scalable service discrimination in the Internet without the need for per\-flow state and signaling at every hop\&. Check RFC 2474 +for more information\&. +\fIclass\fR +must be an integer in the range [0\(en255]\&. +.RE +.PP +\fB\-\-hop\-limit \fR\fB\fIhops\fR\fR (Hop Limit) +.RS 4 + +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 the TTL in IPv4, IPv6 Hop Limit tries to avoid a situation in which undeliverable datagrams keep being forwarded from one router to another endlessly\&. +\fIhops\fR +must be a number in the range [0\(en255]\&. +.RE +.SH "ETHERNET OPTIONS" +.PP +In most cases Nping sends packets at the 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\&. +.PP +\fB\-\-dest\-mac \fR\fB\fImac\fR\fR (Ethernet Destination MAC Address) +.RS 4 +This option sets the destination MAC address that should be set in outgoing Ethernet frames\&. This is useful in case Nping can\*(Aqt determine the next hop\*(Aqs MAC address or when you want to route probes through a router other than the configured default gateway\&. The MAC address should have the usual format of six colon\-separated bytes, e\&.g\&. +00:50:56:d4:01:98\&. Alternatively, hyphens may be used instead of colons\&. Use the word +random +or +rand +to generate a random address, and +broadcast +or +bcast +to use ff:ff:ff:ff:ff:ff\&. If you set up a bogus destination MAC address your probes may not reach the intended targets\&. +.RE +.PP +\fB\-\-source\-mac \fR\fB\fImac\fR\fR (Ethernet Source MAC Address) +.RS 4 +This option sets the source MAC address that should be set in outgoing Ethernet frames\&. This is useful in case Nping can\*(Aqt determine your network interface MAC address or when you want to inject traffic into the network while hiding your network card\*(Aqs real address\&. The syntax is the same as for +\-\-dest\-mac\&. If you set up a bogus source MAC address you may not receive probe replies\&. +.RE +.PP +\fB\-\-ether\-type \fR\fB\fItype\fR\fR (Ethertype) +.RS 4 +This option sets the Ethertype field of the ethernet frame\&. The Ethertype is used to indicate which protocol is encapsulated in the payload\&. +\fItype\fR +can be supplied in two different ways\&. You can use the +\m[blue]\fBofficial numbers listed by the IEEE\fR\m[]\&\s-2\u[3]\d\s+2 +(e\&.g\&. +\fB\-\-ether\-type 0x0800\fR +for IP version 4), or one of the mnemonics from +the section called \(lqEthernet Types\(rq\&. +.RE +.SS "Ethernet Types" +.PP +These identifiers may be used as mnemonics for the Ethertype numbers given to the +\fB\-\-arp\-type\fR +option\&. +.PP +ipv4, ip, 4 +.RS 4 +Internet Protocol version 4 (type 0x0800)\&. +.RE +.PP +ipv6, 6 +.RS 4 +Internet Protocol version 6 (type 0x86DD)\&. +.RE +.PP +arp +.RS 4 +Address Resolution Protocol (type 0x0806)\&. +.RE +.PP +rarp +.RS 4 +Reverse Address Resolution Protocol (type 0x8035)\&. +.RE +.PP +frame\-relay, frelay, fr +.RS 4 +Frame Relay (type 0x0808)\&. +.RE +.PP +ppp +.RS 4 +Point\-to\-Point Protocol (type 0x880B)\&. +.RE +.PP +gsmp +.RS 4 +General Switch Management Protocol (type 0x880C)\&. +.RE +.PP +mpls +.RS 4 +Multiprotocol Label Switching (type 0x8847)\&. +.RE +.PP +mps\-ual, mps +.RS 4 +Multiprotocol Label Switching with Upstream\-assigned Label (type 0x8848)\&. +.RE +.PP +mcap +.RS 4 +Multicast Channel Allocation Protocol (type 0x8861)\&. +.RE +.PP +pppoe\-discovery, pppoe\-d +.RS 4 +PPP over Ethernet Discovery Stage (type 0x8863)\&. +.RE +.PP +pppoe\-session, pppoe\-s +.RS 4 +PPP over Ethernet Session Stage (type 0x8864)\&. +.RE +.PP +ctag +.RS 4 +Customer VLAN Tag Type (type 0x8100)\&. +.RE +.PP +epon +.RS 4 +Ethernet Passive Optical Network (type 0x8808)\&. +.RE +.PP +pbnac +.RS 4 +Port\-based network access control (type 0x888E)\&. +.RE +.PP +stag +.RS 4 +Service VLAN tag identifier (type 0x88A8)\&. +.RE +.PP +ethexp1 +.RS 4 +Local Experimental Ethertype 1 (type 0x88B5)\&. +.RE +.PP +ethexp2 +.RS 4 +Local Experimental Ethertype 2 (type 0x88B6)\&. +.RE +.PP +ethoui +.RS 4 +OUI Extended Ethertype (type 0x88B7)\&. +.RE +.PP +preauth +.RS 4 +Pre\-Authentication (type 0x88C7)\&. +.RE +.PP +lldp +.RS 4 +Link Layer Discovery Protocol (type 0x88CC)\&. +.RE +.PP +mac\-security, mac\-sec, macsec +.RS 4 +Media Access Control Security (type 0x88E5)\&. +.RE +.PP +mvrp +.RS 4 +Multiple VLAN Registration Protocol (type 0x88F5)\&. +.RE +.PP +mmrp +.RS 4 +Multiple Multicast Registration Protocol (type 0x88F6)\&. +.RE +.PP +frrr +.RS 4 +Fast Roaming Remote Request (type 0x890D)\&. +.RE +.SH "PAYLOAD OPTIONS" +.PP +\fB\-\-data \fR\fB\fIhex string\fR\fR (Append custom binary data to sent packets) +.RS 4 +This option lets you include binary data as payload in sent packets\&. +\fIhex string\fR +may be specified in any of the following formats: +0xAABBCCDDEEFF\fI\&.\&.\&.\fR, +AABBCCDDEEFF\fI\&.\&.\&.\fR +or +\exAA\exBB\exCC\exDD\exEE\exFF\fI\&.\&.\&.\fR\&. Examples of use are +\fB\-\-data 0xdeadbeef\fR +and +\fB\-\-data \exCA\exFE\ex09\fR\&. Note that if you specify a number like +0x00ff +no byte\-order conversion is performed\&. Make sure you specify the information in the byte order expected by the receiver\&. +.RE +.PP +\fB\-\-data\-string \fR\fB\fIstring\fR\fR (Append custom string to sent packets) +.RS 4 +This option lets you include a regular string as payload in sent packets\&. +\fIstring\fR +can contain any string\&. However, note that some characters may depend on your system\*(Aqs locale and the receiver may not see the same information\&. Also, make sure you enclose the string in double quotes and escape any special characters from the shell\&. Example: +\fB\-\-data\-string "Jimmy Jazz\&.\&.\&."\fR\&. +.RE +.PP +\fB\-\-data\-length \fR\fB\fIlen\fR\fR (Append random data to sent packets) +.RS 4 +This option lets you include +\fIlen\fR +random bytes of data as payload in sent packets\&. +\fIlen\fR +must be an integer in the range [0\(en65400]\&. However, values higher than 1400 are not recommended because it may not be possible to transmit packets due to network MTU limitations\&. +.RE +.SH "ECHO MODE" +.PP +The "Echo Mode" is a novel technique implemented by Nping which lets users see how network packets change in transit, from the host where they originated to the target machine\&. Basically, the Echo mode turns Nping into two different pieces: the Echo server and the Echo client\&. The Echo server is a network service that has the ability to capture packets from the network and send a copy ("echo them") to the originating client through a side TCP channel\&. The Echo client is the part that generates such network packets, transmits them to the server, and receives their echoed version through a side TCP channel that it has previously established with the Echo server\&. +.PP +This scheme lets the client see the differences between the packets that it sends and what is actually received by the server\&. By having the server send back copies of the received packets through the side channel, things like NAT devices become immediately apparent to the client because it notices the changes in the source IP address (and maybe even source port)\&. Other devices like those that perform traffic shaping, changing TCP window sizes or adding TCP options transparently between hosts, turn up too\&. +.PP +The Echo mode is also useful for troubleshooting routing and firewall issues\&. Among other things, it can be used to determine if the traffic generated by the Nping client is being dropped in transit and never gets to its destination or if the responses are the ones that don\*(Aqt get back to it\&. +.PP +Internally, client and server communicate over an encrypted and authenticated channel, using the Nping Echo Protocol (NEP), whose technical specification can be found in +\m[blue]\fB\%https://nmap.org/svn/nping/docs/EchoProtoRFC.txt\fR\m[] +.PP +The following paragraphs describe the different options available in Nping\*(Aqs Echo mode\&. +.PP +\fB\-\-ec \fR\fB\fIpassphrase\fR\fR, \fB\-\-echo\-client \fR\fB\fIpassphrase\fR\fR (Run Echo client) +.RS 4 +This option tells Nping to run as an Echo client\&. +\fIpassphrase\fR +is a sequence of ASCII characters that is used used to generate the cryptographic keys needed for encryption and authentication in a given session\&. The passphrase should be a secret that is also known by the server, and it may contain any number of printable ASCII characters\&. Passphrases that contain whitespace or special characters must be enclosed in double quotes\&. +.sp +When running Nping as an Echo client, most options from the regular raw probe modes apply\&. The client may be configured to send specific probes using flags like +\fB\-\-tcp\fR, +\fB\-\-icmp\fR +or +\fB\-\-udp\fR\&. Protocol header fields may be manipulated normally using the appropriate options (e\&.g\&. +\fB\-\-ttl\fR, +\fB\-\-seq\fR, +\fB\-\-icmp\-type\fR, etc\&.)\&. The only exceptions are ARP\-related flags, which are not supported in Echo mode, as protocols like ARP are closely related to the data link layer and its probes can\*(Aqt pass through different network segments\&. +.RE +.PP +\fB\-\-es \fR\fB\fIpassphrase\fR\fR, \fB\-\-echo\-server \fR\fB\fIpassphrase\fR\fR (Run Echo server) +.RS 4 +This option tells Nping to run as an Echo server\&. +\fIpassphrase\fR +is a sequence of ASCII characters that is used used to generate the cryptographic keys needed for encryption and authentication in a given session\&. The passphrase should be a secret that is also known by the clients, and it may contain any number of printable ASCII characters\&. Passphrases that contain whitespace or special characters must be enclosed in double quotes\&. Note that although it is not recommended, it is possible to use empty passphrases, supplying +\fB\-\-echo\-server ""\fR\&. However, if what you want is to set up an open Echo server, it is better to use option +\fB\-\-no\-crypto\fR\&. See below for details\&. +.RE +.PP +\fB\-\-ep \fR\fB\fIport\fR\fR, \fB\-\-echo\-port \fR\fB\fIport\fR\fR (Set Echo TCP port number) +.RS 4 +This option asks Nping to use the specified TCP port number for the Echo side channel connection\&. If this option is used with +\fB\-\-echo\-server\fR, it specifies the port on which the server listens for connections\&. If it is used with +\fB\-\-echo\-client\fR, it specifies the port to connect to on the remote host\&. By default, port number 9929 is used\&. +.RE +.PP +\fB\-\-nc\fR, \fB\-\-no\-crypto\fR (Disable encryption and authentication) +.RS 4 +This option asks Nping not to use any cryptographic operations during an Echo session\&. In practical terms, this means that the Echo side channel session data will be transmitted in the clear, and no authentication will be performed by the server or client during the session establishment phase\&. When +\fB\-\-no\-crypto\fR +is used, the passphrase supplied with +\fB\-\-echo\-server\fR +or +\fB\-\-echo\-client\fR +is ignored\&. +.sp +This option must be specified if Nping was compiled without openSSL support\&. Note that, for technical reasons, a passphrase still needs to be supplied after the \-\-echo\-client or \-\-echo\-server flags, even though it will be ignored\&. +.sp +The \-\-no\-crypto flag might be useful when setting up a public Echo server, because it allows users to connect to the Echo server without the need for any passphrase or shared secret\&. However, it is strongly recommended to not use \-\-no\-crypto unless absolutely necessary\&. Public Echo servers should be configured to use the passphrase "public" or the empty passphrase (\-\-echo\-server "") as the use of cryptography does not only provide confidentiality and authentication but also message integrity\&. +.RE +.PP +\fB\-\-once\fR (Serve one client and quit) +.RS 4 +This option asks the Echo server to quit after serving one client\&. This is useful when only a single Echo session wants to be established as it eliminates the need to access the remote host to shutdown the server\&. +.RE +.PP +\fB\-\-safe\-payloads\fR (Zero application data before echoing a packet) +.RS 4 +This option asks the Echo server to erase any application layer data found in client packets before echoing them\&. When the option is enabled, the Echo server parses the packets received from Echo clients and tries to determine if they contain data beyond the transport layer\&. If such data is found, it is overwritten with zeroes before transmitting the packets to the appropriate Echo client\&. +.sp +Echo servers can handle multiple simultaneous clients running multiple echo sessions in parallel\&. In order to determine which packet needs to be echoed to which client and through which session, the Echo server uses an heuristic algorithm\&. Although we have taken every security measure that we could think of to prevent that a client receives an echoed packet that it did not generate, there is always a risk that our algorithm makes a mistake and delivers a packet to the wrong client\&. The \-\-safe\-payloads option is useful for public echo servers or critical deployments where that kind of mistake cannot be afforded\&. +.RE +.PP +The following examples illustrate how Nping\*(Aqs Echo mode can be used to discover intermediate devices\&. +.PP +\fBExample\ \&2.\ \&Discovering NAT devices\fR +.sp +.if n \{\ +.RS 4 +.\} +.nf + # \fBnping \-\-echo\-client "public" echo\&.nmap\&.org \-\-udp \fR + + Starting Nping ( https://nmap\&.org/nping ) + SENT (1\&.0970s) UDP 10\&.1\&.20\&.128:53 > 178\&.79\&.165\&.17:40125 ttl=64 id=32523 iplen=28 + CAPT (1\&.1270s) UDP 80\&.38\&.10\&.21:45657 > 178\&.79\&.165\&.17:40125 ttl=54 id=32523 iplen=28 + RCVD (1\&.1570s) ICMP 178\&.79\&.165\&.17 > 10\&.1\&.20\&.128 Port unreachable (type=3/code=3) ttl=49 id=16619 iplen=56 + [\&.\&.\&.] + SENT (5\&.1020s) UDP 10\&.1\&.20\&.128:53 > 178\&.79\&.165\&.17:40125 ttl=64 id=32523 iplen=28 + CAPT (5\&.1335s) UDP 80\&.38\&.10\&.21:45657 > 178\&.79\&.165\&.17:40125 ttl=54 id=32523 iplen=28 + RCVD (5\&.1600s) ICMP 178\&.79\&.165\&.17 > 10\&.1\&.20\&.128 Port unreachable (type=3/code=3) ttl=49 id=16623 iplen=56 + + Max rtt: 60\&.628ms | Min rtt: 58\&.378ms | Avg rtt: 59\&.389ms + Raw packets sent: 5 (140B) | Rcvd: 5 (280B) | Lost: 0 (0\&.00%)| Echoed: 5 (140B) + Tx time: 4\&.00459s | Tx bytes/s: 34\&.96 | Tx pkts/s: 1\&.25 + Rx time: 5\&.00629s | Rx bytes/s: 55\&.93 | Rx pkts/s: 1\&.00 + Nping done: 1 IP address pinged in 6\&.18 seconds + +.fi +.if n \{\ +.RE +.\} +.PP +The output clearly shows the presence of a NAT device in the client\*(Aqs local network\&. Note how the captured packet (CAPT) differs from the SENT packet: the source address for the original packets is in the reserved 10\&.0\&.0\&.0/8 range, while the address seen by the server is 80\&.38\&.10\&.21, the Internet side address of the NAT device\&. The source port was also modified by the device\&. The line starting with RCVD corresponds to the responses generated by the TCP/IP stack of the machine where the Echo server is run\&. +.PP +\fBExample\ \&3.\ \&Discovering a transparent proxy\fR +.sp +.if n \{\ +.RS 4 +.\} +.nf + # \fBnping \-\-echo\-client "public" echo\&.nmap\&.org \-\-tcp \-p80\fR + + Starting Nping ( https://nmap\&.org/nping ) + SENT (1\&.2160s) TCP 10\&.0\&.1\&.77:41659 > 178\&.79\&.165\&.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480 + RCVD (1\&.2180s) TCP 178\&.79\&.165\&.17:80 > 10\&.0\&.1\&.77:41659 SA ttl=128 id=13177 iplen=44 seq=3647106954 win=16384 <mss 1460> + SENT (2\&.2150s) TCP 10\&.0\&.1\&.77:41659 > 178\&.79\&.165\&.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480 + SENT (3\&.2180s) TCP 10\&.0\&.1\&.77:41659 > 178\&.79\&.165\&.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480 + SENT (4\&.2190s) TCP 10\&.0\&.1\&.77:41659 > 178\&.79\&.165\&.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480 + SENT (5\&.2200s) TCP 10\&.0\&.1\&.77:41659 > 178\&.79\&.165\&.17:80 S ttl=64 id=3317 iplen=40 seq=567704200 win=1480 + + Max rtt: 2\&.062ms | Min rtt: 2\&.062ms | Avg rtt: 2\&.062ms + Raw packets sent: 5 (200B) | Rcvd: 1 (46B) | Lost: 4 (80\&.00%)| Echoed: 0 (0B) + Tx time: 4\&.00504s | Tx bytes/s: 49\&.94 | Tx pkts/s: 1\&.25 + Rx time: 5\&.00618s | Rx bytes/s: 9\&.19 | Rx pkts/s: 0\&.20 + Nping done: 1 IP address pinged in 6\&.39 seconds + +.fi +.if n \{\ +.RE +.\} +.PP +In this example, the output is a bit more tricky\&. The absence of error messages shows that the Echo client has successfully established an Echo session with the server\&. However, no CAPT packets can be seen in the output\&. This means that none of the transmitted packets reached the server\&. Interestingly, a TCP SYN\-ACK packet was received in response to the first TCP\-SYN packet (and also, it is known that the target host does not have port 80 open)\&. This behavior reveals the presence of a transparent web proxy cache server (which in this case is an old MS ISA server)\&. +.SH "TIMING AND PERFORMANCE OPTIONS" +.PP +\fB\-\-delay \fR\fB\fItime\fR\fR (Delay between probes) +.RS 4 +This option lets you control for how long will Nping wait before sending the next probe\&. Like in many other ping tools, the default delay is one second\&. +\fItime\fR +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)\&. +.RE +.PP +\fB\-\-rate \fR\fB\fIrate\fR\fR (Send probes at a given rate) +.RS 4 +This option specifies the number of probes that Nping should send per second\&. This option and +\fB\-\-delay\fR +are inverses; +\fB\-\-rate 20\fR +is the same as +\fB\-\-delay 0\&.05\fR\&. If both options are used, only the last one in the parameter list counts\&. +.RE +.SH "MISCELLANEOUS OPTIONS" +.PP +\fB\-h\fR, \fB\-\-help\fR (Display help) +.RS 4 +Displays help information and exits\&. +.RE +.PP +\fB\-V\fR, \fB\-\-version\fR (Display version) +.RS 4 +Displays the program\*(Aqs version number and quits\&. +.RE +.PP +\fB\-c \fR\fB\fIrounds\fR\fR, \fB\-\-count \fR\fB\fIrounds\fR\fR (Stop after a given number of rounds) +.RS 4 +This option lets you specify the number of times that Nping should loop over target hosts (and in some cases target ports)\&. Nping calls these +\(lqrounds\(rq\&. 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 and 433, then 256 \(mu 2\ \&=\ \&512 packets are sent in one round\&. So if you specify +\fB\-c 100\fR, Nping will loop over the different target hosts and ports 100 times, sending a total of 256 \(mu 2 \(mu 100\ \&=\ \&51200 packets\&. By default Nping runs for 5 rounds\&. If a value of 0 is specified, Nping will run continuously\&. +.RE +.PP +\fB\-e \fR\fB\fIname\fR\fR, \fB\-\-interface \fR\fB\fIname\fR\fR (Set the network interface to be used) +.RS 4 +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\&. +\fIname\fR +must be the name of an existing network interface with an assigned IP address\&. +.RE +.PP +\fB\-\-privileged\fR (Assume that the user is fully privileged) +.RS 4 +Tells Nping to simply assume that it is privileged enough to perform raw socket sends, packet sniffing, and similar operations that usually require special privileges\&. By default Nping quits if such operations are requested by a user that has no root or administrator privileges\&. This option may be useful on Linux, BSD or similar systems that can be configured to allow unprivileged users to perform raw\-packet transmissions\&. The +\fBNPING_PRIVILEGED\fR +environment variable may be set as an alternative to using +\fB\-\-privileged\fR\&. +.RE +.PP +\fB\-\-unprivileged\fR (Assume that the user lacks raw socket privileges) +.RS 4 +This option is the opposite of +\fB\-\-privileged\fR\&. 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 +\fBNPING_UNPRIVILEGED\fR +environment variable may be set as an alternative to using +\fB\-\-unprivileged\fR\&. +.RE +.PP +\fB\-\-send\-eth\fR (Use raw ethernet sending) +.RS 4 +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\&. Nping still uses raw IP packets despite this option when there is no other choice (such as non\-ethernet connections)\&. +.RE +.PP +\fB\-\-send\-ip\fR (Send at raw IP level) +.RS 4 +Asks Nping to send packets via raw IP sockets rather than sending lower level ethernet frames\&. It is the complement to the +\fB\-\-send\-eth\fR +option\&. +.RE +.PP +\fB\-\-bpf\-filter \fR\fB\fIfilter spec\fR\fR \fB\-\-filter \fR\fB\fIfilter spec\fR\fR (Set custom BPF filter) +.RS 4 +This option lets you use 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 packets, the filter is set to capture packets whose destination port matches the probe\*(Aqs source port or ICMP error messages that may be generated by the target or any intermediate device as a result of the probe\&. 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 BPF syntax used by tools like tcpdump\&. +See the documentation at +\m[blue]\fB\%http://www.tcpdump.org/\fR\m[] +for more information\&. +.RE +.PP +\fB\-H\fR, \fB\-\-hide\-sent\fR (Do not display sent packets) +.RS 4 +This option tells Nping not to print information about sent packets\&. This can be useful when using very short inter\-probe delays (i\&.e\&., when flooding), because printing information to the standard output has a computational cost and disabling it can probably speed things up a bit\&. Also, it may be useful when using Nping to detect active hosts or open ports (e\&.g\&. sending probes to all TCP ports in a /24 subnet)\&. In that case, users may not want to see thousands of sent probes but just the replies generated by active hosts\&. +.RE +.PP +\fB\-N\fR, \fB\-\-no\-capture\fR (Do not attempt to capture replies) +.RS 4 +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\&. +.RE +.SH "OUTPUT OPTIONS" +.PP +\fB\-v\fR\fB[\fIlevel\fR]\fR, \fB\-\-verbose \fR\fB[\fIlevel\fR]\fR (Increase or set verbosity level) +.RS 4 +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 +\fB\-v\fR +increments the verbosity level by one (from its default value, level 0)\&. Every instance of option +\fB\-q\fR +decrements the verbosity level by one\&. Alternatively you can specify the level directly, as in +\fB\-v3\fR +or +\fB\-v\-1\fR\&. These are the available levels: +.PP +Level \-4 +.RS 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 \-4 can be useful because although you won\*(Aqt see any response packets, probes will still be sent\&. +.RE +.PP +Level \-3 +.RS 4 +Like level \-4 but displays fatal error messages so you can actually see if Nping is running or it failed due to some error\&. +.RE +.PP +Level \-2 +.RS 4 +Like level \-3 but also displays warnings and recoverable errors\&. +.RE +.PP +Level \-1 +.RS 4 +Displays traditional run\-time information (version, start time, statistics, etc\&.) but does not display sent or received packets\&. +.RE +.PP +Level 0 +.RS 4 +This is the default verbosity level\&. It behaves like level \-1 but also displays sent and received packets and some other important information\&. +.RE +.PP +Level 1 +.RS 4 +Like level 0 but it displays detailed information about timing, flags, protocol details, etc\&. +.RE +.PP +Level 2 +.RS 4 +Like level 1 but displays very detailed information about sent and received packets and other interesting information\&. +.RE +.PP +Level 3 +.RS 4 +Like level 2 but also displays the raw hexadecimal dump of sent and received packets\&. +.RE +.PP +Level 4 and higher +.RS 4 +Same as level 3\&. +.RE +.RE +.PP +\fB\-q\fR\fB[\fIlevel\fR]\fR, \fB\-\-reduce\-verbosity \fR\fB[\fIlevel\fR]\fR (Decrease verbosity level) +.RS 4 +Decreases the verbosity level, causing Nping to print less information during its execution\&. +.RE +.PP +\fB\-d\fR\fB[\fIlevel\fR]\fR (Increase or set debugging level) +.RS 4 +When even verbose mode doesn\*(Aqt provide sufficient data for you, debugging is available to flood you with much more! As with the +\fB\-v\fR, debugging is enabled with a command\-line flag +\fB\-d\fR +and the debug level can be increased by specifying it multiple times\&. There are 7 debugging levels (0 to 6)\&. Every instance of +\fB\-d\fR +increments debugging level by one\&. Provide an argument to +\fB\-d\fR +to set the level directly; for example +\fB\-d4\fR\&. +.sp +Debugging output is useful when you suspect a bug 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\*(Aqt always self\-explanatory\&. You may get something like + +.sp +.if n \{\ +.RS 4 +.\} +.nf +NSOCK (1\&.0000s) Callback: TIMER SUCCESS for EID 12; tcpconnect_event_handler(): Received callback of type TIMER with status SUCCESS +.fi +.if n \{\ +.RE +.\} +.sp +If you don\*(Aqt 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: +.PP +Level 0 +.RS 4 +Level 0\&. No debug information at all\&. This is the default level\&. +.RE +.PP +Level 1 +.RS 4 +In this level, only very important or high\-level debug information will be printed\&. +.RE +.PP +Level 2 +.RS 4 +Like level 1 but also displays important or medium\-level debug information +.RE +.PP +Level 3 +.RS 4 +Like level 2 but also displays regular and low\-level debug information\&. +.RE +.PP +Level 4 +.RS 4 +Like level 3 but also displays messages only a real Nping freak would want to see\&. +.RE +.PP +Level 5 +.RS 4 +Like level 4 but it enables basic debug information related to external libraries like Nsock\&. +.RE +.PP +Level 6 +.RS 4 +Like level 5 but it enables full, very detailed, debug information related to external libraries like Nsock\&. +.RE +.RE +.SH "BUGS" +.PP +Like its authors, Nping isn\*(Aqt perfect\&. But you can help make it better by sending bug reports or even writing patches\&. If Nping doesn\*(Aqt behave the way you expect, first upgrade to the latest version available from +\m[blue]\fB\%https://nmap.org\fR\m[]\&. If the problem persists, do some research to determine whether it has already been discovered and addressed\&. Try searching for the problem or error message on Google since that aggregates so many forums\&. If nothing comes of this, create an Issue on our tracker (\m[blue]\fB\%http://issues.nmap.org\fR\m[]) and/or mail a bug report to +<dev@nmap\&.org>\&. If you subscribe to the nmap\-dev list before posting, your message will bypass moderation and get through more quickly\&. Subscribe at +\m[blue]\fB\%https://nmap.org/mailman/listinfo/dev\fR\m[]\&. Please include everything you have learned about the problem, as well as what version of Nping you are using and what operating system version it is running on\&. Other suggestions for improving Nping may be sent to the Nmap dev mailing list as well\&. +.PP +If you are able to write a patch improving Nping or fixing a bug, that is even better! Instructions for submitting patches or git pull requests are available from +\m[blue]\fB\%https://github.com/nmap/nmap/blob/master/CONTRIBUTING.md\fR\m[] +.PP +Particularly sensitive issues such as a security reports may be sent directly to Fyodor directly at +<fyodor@nmap\&.org>\&. All other reports and comments should use the dev list or issue tracker instead because more people read, follow, and respond to those\&. +.SH "AUTHORS" +.PP +Luis MartinGarcia +<luis\&.mgarc@gmail\&.com> +(\m[blue]\fB\%http://www.luismg.com\fR\m[]) +.PP +Fyodor +<fyodor@nmap\&.org> +(\m[blue]\fB\%https://insecure.org\fR\m[]) +.SH "NOTES" +.IP " 1." 4 +official type numbers assigned by IANA +.RS 4 +\%http://www.iana.org/assignments/icmp-parameters +.RE +.IP " 2." 4 +official numbers assigned by IANA +.RS 4 +\%http://www.iana.org/assignments/arp-parameters/ +.RE +.IP " 3." 4 +official numbers listed by the IEEE +.RS 4 +\%http://standards.ieee.org/regauth/ethertype/eth.txt +.RE diff --git a/nping/docs/npingmanhtml.xml b/nping/docs/npingmanhtml.xml new file mode 100644 index 0000000..bf801fe --- /dev/null +++ b/nping/docs/npingmanhtml.xml @@ -0,0 +1,13 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" + "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" +[ +<!ENTITY refguide SYSTEM "nping-man.xml"> +<!ENTITY nping-usage SYSTEM "nping-usage.xml"> +]> +<article id="npingman"> +<artheader> +<title>Nping Reference Guide (Man Page)</title> +</artheader> +&refguide; +</article> |