From 0d47952611198ef6b1163f366dc03922d20b1475 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 17 Apr 2024 09:42:04 +0200 Subject: Adding upstream version 7.94+git20230807.3be01efb1+dfsg. Signed-off-by: Daniel Baumann --- nping/docs/AUTHORS | 16 + nping/docs/EchoProtoRFC.txt | 1158 ++++++++++++ nping/docs/leet-nping-ascii-art.txt | 18 + nping/docs/nping-man.xml | 3575 +++++++++++++++++++++++++++++++++++ nping/docs/nping-usage.txt | 120 ++ nping/docs/nping-usage.xml | 2 + nping/docs/nping.1 | 1797 ++++++++++++++++++ nping/docs/npingmanhtml.xml | 13 + 8 files changed, 6699 insertions(+) create mode 100644 nping/docs/AUTHORS create mode 100644 nping/docs/EchoProtoRFC.txt create mode 100644 nping/docs/leet-nping-ascii-art.txt create mode 100644 nping/docs/nping-man.xml create mode 100644 nping/docs/nping-usage.txt create mode 100644 nping/docs/nping-usage.xml create mode 100644 nping/docs/nping.1 create mode 100644 nping/docs/npingmanhtml.xml (limited to 'nping/docs') 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 @@ + + + nping + 1 + Nping + Nping Reference Guide + + + nping + Network packet generation tool / ping utility + + + + + nping + + Options + + + targets + + + + + Description + Npingdescription of + + This document describes the very latest version of + Nping available from Please + ensure you are using the latest version before reporting that a + feature doesn't work as described. + + Nping is an open-source tool for network packet generation, + response analysis and response time measurement. Nping allows + 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. + + 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. + + + 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. + + + A typical Nping execution is shown in . The only Nping arguments used in + this example are , to specify the number of times to + target each host, to specify TCP Probe Mode, + to specify the target ports; and then the two + target hostnames. + +A representative Nping execution + (Nping option)example of + (Nping option)example of + (Nping option)example of + +# nping -c 1 --tcp -p 80,433 scanme.nmap.org google.com + +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 + + + + +The newest version of Nping can be obtained with Nmap at . The newest version of this man page +is available at . +--> + + + + Options Summary + + +This options summary is printed when Nping is run +with no arguments. It helps people remember the most common options, +but is no substitute for the in-depth documentation in the rest of this manual. +Some obscure options aren't even included here. + + +summary of options (Nping) +command-line optionsof Nping + +&nping-usage; + + + + + + + + + Target Specification + target specificationin Nping + + 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. + + + + Nping supports + CIDR-styleCIDR (Classless Inter-Domain Routing) + addressing. You can append /numbits to an + IPv4 address or hostname and Nping will send probes to every IP + address for which the first numbits are the same as for the + reference IP or hostname given. For example, 192.168.10.0/24 would + send probes to the 256 hosts between 192.168.10.0 + (binary: 11000000 10101000 00001010 00000000) + and 192.168.10.255 + (binary: 11000000 10101000 00001010 11111111), + inclusive. 192.168.10.40/24 would ping exactly the same targets. + Given that the host scanme.nmap.orgscanme.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. + + + address ranges + CIDR notation is short but not always flexible enough. For example, + you might want to send probes to 192.168.0.0/16 but skip any IPs + ending with .0 or .255 because they may be used as subnet network + and broadcast addresses. Nping supports this through octet range + addressing. Rather than specify a normal IP address, you can specify + a comma-separated list of numbers or ranges for each octet. For + example, 192.168.0-255.1-254 will skip all addresses in the range + that end in .0 or .255, and 192.168.3-5,7.1 will target the four + addresses 192.168.3.1, 192.168.4.1, 192.168.5.1, and 192.168.7.1. + Either side of a range may be omitted; the default values are 0 on + the left and 255 on the right. Using + - by itself is the same as 0-255, + but remember to use 0- in the first octet so the target + specification doesn't look like a command-line option. Ranges need + not be limited to the final octets: the specifier 0-.-.13.37 will send probes + to all IP addresses on the Internet ending in .13.37. This sort of + broad sampling can be useful for Internet surveys and research. + + + IPv6 addresses can only be specified by their fully qualified IPv6 + address or hostname. CIDR and octet ranges aren't supported for + IPv6 because they are rarely useful. + + Nping accepts multiple host specifications on the command line, + and they don't need to be the same type. The command + nping scanme.nmap.org + 192.168.0.0/8 10.0.0,1,3-7.- does what you would expect. + + + + + + + Option Specification + + + 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. + + + + 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. + + + + 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. + + + + 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. + + + + + + + General Operation + general operation + + 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. + + + + 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. + + + + The loop around targets is the inner loop and the + loop around ports is the outer loop. 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 inter-probe delay, which is controlled by + the option. These examples show how it + works. + + + + + + One target, three ports, and two rounds. + + + +# nping --tcp -c 2 1.1.1.1 -p 100-102 + +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 + + + + + + Three targets, one port, and two rounds. + + + +# nping --tcp -c 2 1.1.1.1 2.2.2.2 3.3.3.3 -p 8080 + +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 + + + + + + Three hosts, three ports, one round, inter-probe delay of 500 ms. + + + +# nping --tcp -c 1 --delay 500ms 1.1.1.1 2.2.2.2 3.3.3.3 -p 137-139 + +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 + + + + + + + + + Probe Modes + probe modes + + 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. + + + + + + + (TCP Connect mode) + (Nping option) + TCP connectin Nping + TCP connectconnect scan + + + TCP connect mode is the default mode when a user does not have + raw packet privileges. Instead of writing raw packets as most + other modes do, Nping asks the underlying operating system to + establish a connection with the target machine and port by + issuing the connect system call. This is the same high-level + system call that web browsers, P2P clients, and most other + network-enabled applications use to establish a connection. + It is part of a programming interface known as the Berkeley + Sockets API. Rather than read raw packet responses off the wire, + Nping uses this API to obtain status information on each + connection attempt. For this reason, you will not be able to + see the contents of the packets that are sent or received but + only status information about the TCP connection establishment + taking place. + + + + + + + + + (TCP mode) + (Nping option) + + + 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. + + + + + + + + (UDP mode) + (Nping option) + + + 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-packetport knocking + authorization daemons. + + + + + + + + (ICMP mode) + (Nping option) + + + 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. + + + + + + + + (ARP/RARP mode) + (Nping option) + + + 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. + + + + + + + + (Traceroute mode) + (Nping option) + + + 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. + + + + + + + + + + + + + + TCP Connect Mode + + + + + + , + (Target ports) + (Nping option) + (Nping option) + + + + 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. + + + + + + + , + (Spoof source port) + (Nping option) + (Nping option) + + + + 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]. + + + + + + + + + + + + + + TCP Mode + + + + + + + , + (Target ports) + + + + This option specifies which destination ports you want to send + probes to. It can be a single port, a comma-separated list of + ports (e.g. 80,443,8080), a range + (e.g. 1-1023), and any combination + of those (e.g. 21-25,80,443,1024-2048). + The beginning and/or end values + of a range may be omitted, causing Nping to use 1 and 65535, + respectively. So you can specify -p- to target ports from 1 through + 65535. Using port zero is allowed if you specify it explicitly. + + + + + + + , + (Spoof source port) + + + + 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]. + + + + + + + (Sequence Number) + (Nping option) + + + + Specifies the TCP sequence number. In SYN packets this is the initial + sequence number (ISN). In a normal transmission this corresponds to + the sequence number of the first byte of data in the segment. + seqnumber must be a number in the range + [0–4294967295]. + + + + + + + + (TCP Flags) + (Nping option) + + + + This option specifies which flags should be set in the TCP packet. + flags may be specified in three different + ways: + + + + + As a comma-separated list of flags, e.g. + + + As a list of one-character flag initials, e.g. tells Nping to set flags SYN, ACK, and RST. + + + As an 8-bit hexadecimal number, where the supplied number + is the exact value that will be placed in the flags field of the + TCP header. The number should start with the prefix + 0x and should be in the range + [0x00–0xFF], e.g. --flags 0x20 sets the + URG flag as 0x20 corresponds to binary 00100000 and the URG flag + is represented by the third bit. + + + + + 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'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: + + + + + + CWR (Congestion Window Reduced) + CWR (TCP flag) + + + + Set by an ECN-Capable sender + when it reduces its congestion window (due to a retransmit + timeout, a fast retransmit or in response to an ECN + notification. + + + + + + ECN (Explicit Congestion Notification) + ECN (TCP flag) + + + + 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 3168RFC 3168 + for more information. + + + + + + URG (Urgent) + URG (TCP flag) + + + + Segment is urgent and the urgent pointer field + carries valid information. + + + + + + ACK (Acknowledgement) + ACK (TCP flag) + + + + The segment carries an acknowledgement + and the value of the acknowledgement number field is valid and + contains the next sequence number that is expected from the + receiver. + + + + + + PSH (Push) + PSH (TCP flag) + + + + The data in this segment should be immediately + pushed to the application layer on arrival. + + + + + + RST (Reset) + RST (TCP flag) + + + + There was some problem and the sender wants to + abort the connection. + + + + + + SYN (Synchronize) + SYN (TCP flag) + + + + The segment is a request to synchronize + sequence numbers and establish a connection. The sequence + number field contains the sender's initial sequence + number. + + + + + + FIN (Finish) + FIN (TCP flag) + + + + The sender wants to close the connection. + + + + + + + + + + + + + + (Window Size) + (Nping option) + + + + 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. size + must be a number in the range [0–65535]. + + + + + + + + (Invalid Checksum) + (Nping option) + + + + 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 + . + + + + + + + + + + + + + UDP Mode + + + + + + + , + (Target ports) + (Nping option) + + + + 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. + + + + + + + , + (Spoof source port) + (Nping option) + + + + 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]. + + + + + + + + (Invalid Checksum) + + + + 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 + . + + + + + + + + + + + + + ICMP Mode + + + + + + + (ICMP type) + (Nping option) + + + + This option specifies which type of ICMP messages should be + generated. type can be supplied in + two different ways. You can use the + official type numbers assigned by IANA + (e.g. for ICMP Echo Request), or you + can use any of the mnemonics listed in + . + + + + + + + + (ICMP code) + (Nping option) + + + + This option specifies which ICMP code should be included in + the generated ICMP messages. code can be + supplied in two different ways. You can use the + official code numbers assigned by IANA + (e.g. for Fragment Reassembly Time + Exceeded), or you can use any of the mnemonics listed in + . + + + + + + + + (ICMP identifier) + (Nping option) + + + + This option specifies the value of the identifier used in some of + the ICMP messages. In general it is used to match request and + reply messages. id must be a number in + the range [0–65535]. + + + + + + + + (ICMP sequence) + (Nping option) + + + + 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. id must be a number in + the range [0–65535]. + + + + + + + + (ICMP Redirect address) + (Nping option) + + + + This option sets the address field in ICMP Redirect messages. In + other words, it sets the IP address of the router that should be + used when sending IP datagrams to the original destination. + addr can be either an IPv4 address + or a hostname. + + + + + + + + (ICMP Parameter Problem pointer) + (Nping option) + + + + This option specifies the pointer that indicates the location of + the problem in ICMP Parameter Problem messages. pointer + should be a number in the range [0–255]. Normally this option is + only used when ICMP code is set to 0 ("Pointer indicates the error"). + + + + + + + + (ICMP Router Advertisement Lifetime) + (Nping option) + + + + This option specifies the router advertisement lifetime, this is, + the number of seconds the information carried in an ICMP Router + Advertisement can be considered valid for. ttl + must be a positive integer in the range [0–65535]. + + + + + + + + (ICMP Router Advertisement Entry) + (Nping option) + + + + This option adds a Router Advertisement entry to an ICMP Router + Advertisement message. The parameter must be two + values separated by a comma. addr is + the router's IP and can be specified either as an IP address in + dot-decimal notation or as a hostname. pref + is the preference level for the specified IP. It must be a number + in the range [0–4294967295]. An example is + . + + + + + + + + + (ICMP Originate Timestamp) + (Nping option) + + + + This option sets the Originate Timestamp in ICMP Timestamp messages. + The Originate Timestamp is expressed as the number of milliseconds + since midnight UTC and it corresponds to the time the sender + last touched the Timestamp message before its transmission. + timestamp can be specified as a regular + time (e.g. 10s, 3h, 1000ms), or the special string + now. You can add or subtract + values from now, for example + , + , + . + + + + + + + (ICMP Receive Timestamp) + (Nping option) + + + + This option sets the Receive Timestamp in ICMP Timestamp messages. + The Receive Timestamp is expressed as the number of milliseconds + since midnight UTC and it corresponds to the time the echoer + first touched the Timestamp message on receipt. + timestamp is as with + . + + + + + + + (ICMP Transmit Timestamp) + (Nping option) + + + + This option sets the Transmit Timestamp in ICMP Timestamp messages. + The Transmit Timestamp is expressed as the number of milliseconds + since midnight UTC and it corresponds to the time the echoer + last touched the Timestamp message before its transmission. + timestamp is as with + . + + + + + + + + ICMP typesmnemonics of, in Nping + ICMP Types + + + These identifiers may be used as mnemonics for the ICMP type numbers given + to the + (Nping option) + 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. + + + + + echo-reply + echo-rep + er + + + Echo Reply (type 0). This message is sent in response to an Echo + Request message. + + + + + destination-unreachable + dest-unr + du + + + Destination Unreachable (type 3). This message indicates that + a datagram could not be delivered to its destination. + + + + + source-quench + sour-que + sq + + + 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. + + + + + redirect + redi + r + + + 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. + + + + + echo-request + echo + e + + + Echo Request (type 8). This message is used to test the + connectivity of another device on a network. + + + + + router-advertisement + rout-adv + ra + + + Router Advertisement (type 9). This message is used by + routers to let hosts know of their existence and capabilities. See + also the option. + + + + + router-solicitation + rout-sol + rs + + + Router Solicitation (type 10). This message is used by hosts + to request Router Advertisement messages from any listening + routers. + + + + + time-exceeded + time-exc + te + + + 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. + + + + + parameter-problem + member-pro + pp + + + 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. + + + + + timestamp + time + tm + + + 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 + , + , and + . + + + + + timestamp-reply + time-rep + tr + + + Timestamp Reply (type 14). This message is sent in response + to a Timestamp Request message. + + + + + information + info + i + + + Information Request (type 15). This message is now obsolete + but it was originally used to request configuration information + from another device. + + + + + information-reply + info-rep + ir + + + 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. + + + + + mask-request + mask + m + + + Address Mask Request (type 17). This message is used to + ask a device to send its subnet mask. + + + + + mask-reply + mask-rep + mr + + + Address Mask Reply (type 18). This message contains a subnet + mask and is sent in response to a Address Mask Request message. + + + + + traceroute + trace + tc + + + 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 1393RFC 1393 + for more information. + + + + + + + + + + ICMP codesmnemonics of, in Nping + ICMP Codes + + + These identifiers may be used as mnemonics for the ICMP code numbers given + to the + (Nping option) + option. They are listed by the ICMP type they correspond to. + + + + Destination Unreachable + + + + network-unreachable + netw-unr + net + + + Code 0. Datagram could not be delivered to its destination + network (probably due to some routing problem). + + + + + host-unreachable + host-unr + host + + + Code 1. Datagram was delivered to the destination network but it + was impossible to reach the specified host (probably due to some + routing problem). + + + + + protocol-unreachable + prot-unr + proto + + + 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. + + + + + port-unreachable + port-unr + port + + + Code 3. The TCP/UDP destination port was invalid. + + + + + needs-fragmentation + need-fra + frag + + + 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. + + + + + source-route-failed + sour-rou + routefail + + + Code 5. IP datagram had a Source Route option but a router + couldn't pass it to the next hop. + + + + + network-unknown + netw-unk + net? + + + Code 6. Destination network is unknown. This code is never used. + Instead, Network Unreachable is used. + + + + + host-unknown + host-unk + host? + + + Code 7. Specified host is unknown. Usually generated by a router + local to the destination host to inform of a bad address. + + + + + host-isolated + host-iso + isolated + + + Code 8. Source Host Isolated. Not used. + + + + + network-prohibited + netw-pro + !net + + + Code 9. Communication with destination network is + administratively prohibited (source device is not allowed to send + packets to the destination network). + + + + + host-prohibited + host-pro + !host + + + 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.) + + + + + network-tos + unreachable-network-tos + netw-tos + tosnet + + + Code 11. Destination network unreachable because it cannot + provide the type of service specified in the IP TOS field. + + + + + host-tos + unreachable-host-tos + toshost + + + Code 12. Destination host unreachable because it cannot provide + the type of service specified in the IP TOS field. + + + + + communication-prohibited + comm-pro + !comm + + + Code 13. Datagram could not be forwarded due to filtering that + blocks the message based on its contents. + + + + + host-precedence-violation + precedence-violation + prec-vio + violation + + + Code 14. Precedence value in the IP TOS field is not permitted. + + + + + precedence-cutoff + prec-cut + cutoff + + + Code 15. Precedence value in the IP TOS field is lower than the + minimum allowed for the network. + + + + + + + + Redirect + + + + redirect-network + redi-net + net + + + 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.RFC 1812 + + + + + redirect-host + redi-host + host + + + Code 1. Redirect all future datagrams with the same destination + host as the original datagram, to the router specified in the + Address field. + + + + + redirect-network-tos + redi-ntos + redir-ntos + + + 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. + + + + + redirect-host-tos + redi-htos + redir-htos + + + 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. + + + + + + + + Router Advertisement + + + + normal-advertisement + norm-adv + normal + zero + default + def + + + Code 0. Normal router advertisement. In Mobile IP: Mobility agent + can act as a router for IP datagrams not related to mobile nodes. + + + + + not-route-common-traffic + not-rou + mobile-ip + !route + !commontraffic + + + 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 + + + + + + + + Time Exceeded + + + + ttl-exceeded-in-transit + ttl-exc + ttl-transit + + + Code 0. IP Time To Live expired during transit. + + + + + fragment-reassembly-time-exceeded + frag-exc + frag-time + + + Code 1. Fragment reassembly time has been exceeded. + + + + + + + + Parameter Problem + + + + pointer-indicates-error + poin-ind + pointer + + + Code 0. The pointer field indicates the location of the problem. + See the option. + + + + + missing-required-option + miss-option + option-missing + + + Code 1. IP datagram was expected to have an option that is not + present. + + + + + bad-length + bad-len + badlen + + + Code 2. The length of the IP datagram is incorrect. + + + + + + + + + + + + + + + ARP Mode + + + + + + + (ICMP Type) + (Nping option) + + + + This option specifies which type of ARP messages should be + generated. type can be supplied in + two different ways. You can use the + official + numbers assigned by IANA + (e.g. for ARP Request), or you can use + one of the mnemonics from . + + + + + + + + (Sender MAC address) + (Nping option) + + + + 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. + mac must be specified using the + traditional MAC notation (e.g. 00:0a:8a:32:f4:ae). You can also use + hyphens as separators (e.g. 00-0a-8a-32-f4-ae). + + + + + + + (Sender IP address) + (Nping option) + + + + This option sets the Sender IP field of the ARP header. + addr can be given as an IPv4 address or a + hostname. + + + + + + + + (target MAC address) + (Nping option) + + + + This option sets the Target Hardware Address field of the ARP header. + + + + + + + (target ip address) + (Nping option) + + + + This option sets the Target IP field of the ARP header. + + + + + + + + ARP typesmnemonics of, in Nping + ARP Types + + + These identifiers may be used as mnemonics for the ARP type numbers given + to the + (Nping option) + option. + + + + + arp-request + arp + a + + + 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. + + + + + arp-reply + arp-rep + ar + + + 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. + + + + + rarp-request + rarp + r + + + 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.RFC 903 + + + + + rarp-reply + rarp-rep + rr + + + 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. + + + + + drarp-request + drarp + d + + + 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 1931RFC 1931 + for more information. + + + + + drarp-reply + drarp-rep + dr + + + Dynamic RARP Reply (type 6). A DRARP reply is a message sent in + response to a RARP request to provide network layer address. + + + + + drarp-error + drarp-err + de + + + 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. + + + + + inarp-request + inarp + i + + + 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.RFC 2390 + + + + + inarp-reply + inarp-rep + ir + + + 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. + + + + + arp-nak + an + + + 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 1577RFC 1577 + for more information. + + + + + + + + + + + + + + + IPv4 Options + + + + + + , + (Source IP Address) + (Nping option) + (Nping option) + + + + 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. + addr can be an IPv4 address or a hostname. + + + + + + + (Destination IP Address) + (Nping option) + + + + 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 + . + + + + + + + (Type of Service) + (Nping option) + + + + 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 2474RFC 2474 + for + more information. tos must be a number + in the range [0–255]. + + + + + + + (Identification) + (Nping option) + + + + 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. id + must be a number in the range [0–65535]. + + + + + + + (Don't Fragment) + (Nping option) + + + + Sets the Don't Fragment bit in sent packets. When an + IP datagram has its DF flag set, intermediate devices are not + allowed to fragment it so if it needs to travel across a network + with a MTU smaller that datagram length the datagram will have + to be dropped. Normally an ICMP Destination Unreachable message + is generated and sent back to the sender. + + + + + + + (More Fragments) + (Nping option) + + + + Sets the More Fragments bit in sent packets. The MF + flag is set to indicate the receiver that the current datagram is + a fragment of some larger datagram. When set to zero it indicates + that the current datagram is either the last fragment in the set + or that it is the only fragment. + + + + + + + (Reserved / Evil) + (Nping option) + + + + 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. + + + + + + + (Time To Live) + (Nping option) + + + + 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. + hops must be a number in the range [0–255]. + + + + + + + (Invalid IP checksum) + (Nping option) + + + + 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. + + + + + + + + , + (IP Options) + (Nping option) + + + + The IP protocol offers several options which may be placed in + packet headers. Unlike the ubiquitous TCP options, IP options are + rarely seen due to practicality and security concerns. In fact, + many Internet routers block the most dangerous options such as + source routing. Yet options can still be useful in some cases for + determining and manipulating the network route to target machines. + For example, you may be able to use the record route option to + determine a path to a target even when more traditional + traceroute-style approaches fail. Or if your packets are being + dropped by a certain firewall, you may be able to specify a + different route with the strict or loose source routing options. + + + + The most powerful way to specify IP options is to simply pass in hexadecimal data + as the argument to . Precede each hex byte value + with \x. You may repeat certain characters by + following them with an asterisk and then the number of times you + wish them to repeat. For example, + \x01\x07\x04\x00*4 is the same as + \x01\x07\x04\x00\x00\x00\x00. + + + + 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. + + + + Nping also offers a shortcut mechanism for specifying options. + Simply pass the letter R, T, or U to request record-route, + record-timestamp, or both options together, respectively. Loose + or strict source routing may be specified with an L or S followed + by a space and then a space-separated list of IP addresses. + + + + For more information and examples of using IP options with Nping, + see the mailing list post at + . + + + + + + + (Maximum Transmission Unit) + (Nping option) + + + + This option sets a fictional MTU in Nping so IP datagrams larger than + size are fragmented before transmission. + size must be specified in bytes and + corresponds to the number of octets that can be carried on a + single link-layer frame. + + + + + + + + + + + + + + + IPv6 Options + + + + + + , + (Use IPv6) + (Nping option) + (Nping option) + + + + 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. + Of course, you must use IPv6 syntax if you specify an address + rather than a hostname. An address might look like + , so hostnames are + recommended. + + + While IPv6 hasn't exactly taken the world by storm, it gets + significant use in some (usually Asian) countries and most modern + operating systems support it. To use Nping with IPv6, both the + source and target of your packets must be configured for IPv6. If your + ISP (like most of them) does not allocate IPv6 addresses to you, + free tunnel brokers are widely available and work fine with Nping. + You can use the free IPv6 tunnel broker service at + . + + + Please note that IPv6 support is still highly experimental and + many modes and options may not work with it. + + + + + + + + + + , + (Source IP Address) + (Nping option) + + + + 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. + addr can be an IPv6 address or a hostname. + + + + + + + (Destination IP Address) + (Nping option) + + + + 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 + . + + + + + + + + (Flow Label) + (Nping option) + + + + 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 2460RFC 2560 + for more information. label must be an + integer in the range [0–1048575]. + + + + + + + (Traffic Class) + (Nping option) + + + + 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 2474RFC 2474 + for more information. class must + be an integer in the range [0–255]. + + + + + + + + (Hop Limit) + (Nping option) + + + + hop limit (IPv6)TTL + 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. + hops must be a number in the range [0–255]. + + + + + + + + + + + + + + + + Ethernet Options + + + 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. + + + + + + + (Ethernet Destination MAC Address) + (Nping option) + + + + 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. 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. + + + + + + + (Ethernet Source MAC Address) + (Nping option) + + + + 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 --dest-mac. + If you set up a bogus source MAC address + you may not receive probe replies. + + + + + + + (Ethertype) + (Nping option) + + + + This option sets the Ethertype field of the ethernet frame. + The Ethertype is used to indicate which protocol is encapsulated + in the payload. type can be supplied in + two different ways. You can use the + official + numbers listed by the IEEE + (e.g. for IP version 4), + or one of the mnemonics from + . + + + + + + + + + + Ethernet typesmnemonics of, in Nping + Ethernet Types + + + These identifiers may be used as mnemonics for the Ethertype numbers given + to the + (Nping option) + option. + + + + + ipv4 + ip + 4 + + + Internet Protocol version 4 (type 0x0800). + + + + + ipv6 + 6 + + + Internet Protocol version 6 (type 0x86DD). + + + + + arp + + + Address Resolution Protocol (type 0x0806). + + + + + rarp + + + Reverse Address Resolution Protocol (type 0x8035). + + + + + frame-relay + frelay + fr + + + Frame Relay (type 0x0808). + + + + + ppp + + + Point-to-Point Protocol (type 0x880B). + + + + + gsmp + + + General Switch Management Protocol (type 0x880C). + + + + + mpls + + + Multiprotocol Label Switching (type 0x8847). + + + + + mps-ual + mps + + + Multiprotocol Label Switching with Upstream-assigned Label (type 0x8848). + + + + + mcap + + + Multicast Channel Allocation Protocol (type 0x8861). + + + + + pppoe-discovery + pppoe-d + + + PPP over Ethernet Discovery Stage (type 0x8863). + + + + + pppoe-session + pppoe-s + + + PPP over Ethernet Session Stage (type 0x8864). + + + + + ctag + + + Customer VLAN Tag Type (type 0x8100). + + + + + epon + + + Ethernet Passive Optical Network (type 0x8808). + + + + + pbnac + + + Port-based network access control (type 0x888E). + + + + + stag + + + Service VLAN tag identifier (type 0x88A8). + + + + + ethexp1 + + + Local Experimental Ethertype 1 (type 0x88B5). + + + + + ethexp2 + + + Local Experimental Ethertype 2 (type 0x88B6). + + + + + ethoui + + + OUI Extended Ethertype (type 0x88B7). + + + + + preauth + + + Pre-Authentication (type 0x88C7). + + + + + lldp + + + Link Layer Discovery Protocol (type 0x88CC). + + + + + mac-security + mac-sec + macsec + + + Media Access Control Security (type 0x88E5). + + + + + mvrp + + + Multiple VLAN Registration Protocol (type 0x88F5). + + + + + mmrp + + + Multiple Multicast Registration Protocol (type 0x88F6). + + + + + frrr + + + Fast Roaming Remote Request (type 0x890D). + + + + + + + + + + + + + + + Payload Options + + + + + + (Append custom binary data to sent packets) + (Nping option) + + + + This option lets you include binary data as payload in sent packets. + hex string may be specified in any of + the following formats: 0xAABBCCDDEEFF..., + AABBCCDDEEFF... or + \xAA\xBB\xCC\xDD\xEE\xFF.... + Examples of use are and + . 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. + + + + + + + + (Append custom string to sent packets) + (Nping option) + + + + This option lets you include a regular string as payload in + sent packets. string 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: . + + + + + + + (Append random data to sent packets) + (Nping option) + + + + This option lets you include len + random bytes of data as payload in sent packets. + len must be an integer in the range + [0–65400]. However, values higher than 1400 are not recommended + because it may not be possible to transmit packets due to + network MTU limitations. + + + + + + + + + + + + + + + + Echo Mode + + + 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. + + + + 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. + + + + 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. + + + + Internally, client and server communicate over an encrypted and + authenticated channel, using the Nping Echo Protocol (NEP), whose technical + specification can be found in + + + + + The following paragraphs describe the different options available in Nping's + Echo mode. + + + + + + + , + (Run Echo client) + (Nping option) + (Nping option) + + + + This option tells Nping to run as an Echo client. + passphrase 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. + + + + 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 , + or . Protocol header + fields may be manipulated normally using the appropriate options + (e.g. , , + , 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. + + + + + + + + , + (Run Echo server) + (Nping option) + (Nping option) + + + + This option tells Nping to run as an Echo server. + passphrase 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 + . However, if what you + want is to set up an open Echo server, it is better to use option + . See below for details. + + + + + + + + + , + (Set Echo TCP port number) + (Nping option) + (Nping option) + + + + This option asks Nping to use the specified TCP port number for the + Echo side channel connection. If this option is used with + , it specifies the port on which the + server listens for connections. If it is used with + , it specifies the port to connect to + on the remote host. By default, port number 9929 is used. + + + + + + + , + (Disable encryption and authentication) + (Nping option) + (Nping option) + + + + 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 + is used, the passphrase supplied with + or is ignored. + + + + 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. + + + + 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. + + + + + + + + (Serve one client and quit) + (Nping option) + + + + 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. + + + + + + + + (Zero application data before echoing a packet) + (Nping option) + + + + 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. + + + + 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. + + + + + + + + The following examples illustrate how Nping's Echo mode can be used + to discover intermediate devices. + + + Discovering NAT devices + (Nping option)example of + + # nping --echo-client "public" echo.nmap.org --udp + + 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 + + + + + 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. + + + Discovering a transparent proxy + + # nping --echo-client "public" echo.nmap.org --tcp -p80 + + 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 + + + + + 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). + + + + + + + + Timing and Performance Options + + + + + + (Delay between probes) + (Nping option) + + + + 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. + time must be a positive + integer or floating point number. By default it is specified in + seconds, however you can give an explicit unit by appending + ms for milliseconds, s for seconds, + m for minutes, or h for hours + (e.g. 2.5s, 45m, 2h). + + + + + + + + (Send probes at a given rate) + (Nping option) + + + + This option specifies the number of probes that Nping should send + per second. This option and are inverses; + is the same as + . If both options are used, only the + last one in the parameter list counts. + + + + + + + + + + + + + + + + + + + Miscellaneous Options + + + + + , + (Display help) + (Nping option) + (Nping option) + + + + Displays help information and exits. + + + + + + + + , + (Display version) + (Nping option) + (Nping option) + + + + Displays the program's version number and quits. + + + + + + + , + (Stop after a given number of rounds) + (Nping option) + (Nping option) + + + + 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 rounds. In a basic execution with only one target (and only + one target port in TCP/UDP modes), the number of rounds matches the + number of probes sent to the target host. However, in more complex + executions where Nping is run against multiple targets and multiple + ports, the number of rounds is the number of times that Nping sends + a complete set of probes that covers all target IPs and all + target ports. For example, if Nping is asked to send TCP SYN packets + to hosts 192.168.1.0-255 and ports 80 and 433, then 256 × 2 = 512 packets + are sent in one round. So if you specify , 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. + + + + + + + , + (Set the network interface to be used) + (Nping option) + (Nping option) + + + + This option tells Nping what interface should be used to send and + receive packets. Nping should be able to detect this automatically, + but it will tell you if it cannot. name + must be the name of an existing network interface with an assigned + IP address. + + + + + + + + + (Assume that the user is fully privileged) + (Nping option) + + + + 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 + NPING_PRIVILEGEDNPING_PRIVILEGED environment variable + environment variable + may be set as an alternative to using . + + + + + + + (Assume that the user lacks raw socket privileges) + (Nping option) + + + + This option is the opposite of . It tells Nping to treat + the user as lacking network raw socket and sniffing privileges. + This is useful for testing, debugging, or when the raw network + functionality of your operating system is somehow broken. The + NPING_UNPRIVILEGEDNPING_UNPRIVILEGED environment variable + environment variable may be set as an + alternative to using . + + + + + + + + (Use raw ethernet sending) + (Nping option) + + + + 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). + + + + + + + (Send at raw IP level) + (Nping option) + + + + Asks Nping to send packets via raw IP sockets rather than sending + lower level ethernet frames. It is the complement to the + option. + + + + + + + + + (Set custom BPF filter) + (Nping option) + (Nping option)--bpf-filter + + + + 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.tcpdump + See the documentation at for + more information. + + + + + + + + , + (Do not display sent packets) + (Nping option) + (Nping option)--hide-sent + + + + 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. + + + + + + + , + (Do not attempt to capture replies) + (Nping option) + (Nping option) + + + + This option tells Nping to skip packet capture. This means that + packets in response to sent probes will not be processed or + displayed. This can be useful when doing flooding and network stack + stress tests. Note that when this option is specified, most of + the statistics shown at the end of the execution will be useless. + This option does not work with TCP Connect mode. + + + + + + + + + + + + + + + Output Options + + + + + + , + (Increase or set verbosity level) + (Nping option) + (Nping option) + + + + 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 increments the verbosity level by one + (from its default value, level 0). Every instance of option + decrements the verbosity level by one. Alternatively you can specify + the level directly, as in or + . These are the available levels: + + + verbosity levels of Nping + + + Level -4 + + + No output at all. In some circumstances you may not want + Nping to produce any output (like when one of your work mates is + watching over your shoulder). In that case level -4 can be useful + because although you won't see any response packets, probes will + still be sent. + + + + + Level -3 + + + Like level -4 but displays fatal error messages so you can + actually see if Nping is running or it failed due to some error. + + + + + Level -2 + + + Like level -3 but also displays warnings and recoverable errors. + + + + + Level -1 + + + Displays traditional run-time information (version, start time, + statistics, etc.) but does not display sent or received packets. + + + + + Level 0 + + + This is the default verbosity level. It behaves like level -1 but + also displays sent and received packets and some other important information. + + + + + Level 1 + + + Like level 0 but it displays detailed information about + timing, flags, protocol details, etc. + + + + + Level 2 + + + Like level 1 but displays very detailed information + about sent and received packets and other interesting information. + + + + + Level 3 + + + Like level 2 but also displays the raw hexadecimal dump of sent + and received packets. + + + + + Level 4 and higher + + + Same as level 3. + + + + + + + + + + + + , + (Decrease verbosity level) + (Nping option) + (Nping option)--reduce-verbosity + + + + Decreases the verbosity level, causing Nping to print less + information during its execution. + + + + + + + + + + (Increase or set debugging level) + (Nping option) + + + + + When even verbose mode doesn't provide sufficient data for you, + debugging is available to flood you with much more! As with the + , debugging is enabled with a command-line + flag and the debug level can be increased by + specifying it multiple times. There are 7 debugging levels (0 to 6). + Every instance of increments debugging level by + one. Provide an argument to to set the level + directly; for example . + + + + 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 +Nsockdebug output of + +NSOCK (1.0000s) Callback: TIMER SUCCESS for EID 12; tcpconnect_event_handler(): Received callback of type TIMER with status SUCCESS + + If you don't understand a line, your only + recourses are to ignore it, look it up in the source code, or + request help from the development list (nmap-dev). Some lines are + self-explanatory, but the messages become more obscure as the debug + level is increased. These are the available levels: + + + debug levels of Nping + + + Level 0 + + + Level 0. No debug information at all. This is the default level. + + + + + Level 1 + + + In this level, only very important or high-level debug information + will be printed. + + + + + Level 2 + + + Like level 1 but also displays important or medium-level debug + information + + + + + Level 3 + + + Like level 2 but also displays regular and low-level debug information. + + + + + Level 4 + + + Like level 3 but also displays messages only a real Nping freak would + want to see. + + + + + Level 5 + + + Like level 4 but it enables basic debug information related to + external libraries like Nsock.Nsock + + + + + Level 6 + + + Like level 5 but it enables full, very detailed, debug information + related to external libraries like Nsock. + + + + + + + + + + + + + Bugs + bugs, reporting + + 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 . 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 + () 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 . 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. + + 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 + + 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. + + + + + Authors + + Luis MartinGarcia luis.mgarc@gmail.com () + + Fyodor fyodor@nmap.org () + + + + + 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 : Set destination port(s). + -g, --source-port : Try to use a custom source port. +TCP PROBE MODE: + -g, --source-port : Set source port. + -p, --dest-port : Set destination port(s). + --seq : Set sequence number. + --flags : Set TCP flags (ACK,PSH,RST,SYN,FIN...) + --ack : Set ACK number. + --win : Set window size. + --badsum : Use a random invalid checksum. +UDP PROBE MODE: + -g, --source-port : Set source port. + -p, --dest-port : Set destination port(s). + --badsum : Use a random invalid checksum. +ICMP PROBE MODE: + --icmp-type : ICMP type. + --icmp-code : ICMP code. + --icmp-id : Set identifier. + --icmp-seq : Set sequence number. + --icmp-redirect-addr : Set redirect address. + --icmp-param-pointer : Set parameter problem pointer. + --icmp-advert-lifetime