SendIP allows detailed control of all header fields, but defaults to reasonable values for those fields you are not interested in. As a simple command-line program, SendIP is trivially scriptable.
SendIP was originally written by Mike Ricketts of Project Purple. The version distributed here is based on 2.5, with numerous additions, particularly in the areas of IPv6 extension headers and IPsec support.
Q: What is SendIP good for? A: SendIP allows creation of IP packets with arbitrary contents. As such, it should be useful for many purposes: protocol implementation testing, firewall and IDS testing, network test gear testing, etc.
Q: What is it not good for? A: As SendIP works at the individual packet level, it is less suitable for higher-level testing, e.g., testing some new html feature. The new version of SendIP can create multiple packets, but isn't exactly a stress testing tool - with each field being set individually on each packet created, it limits the send rate to perhaps some low number of thousands per second.
Some level of stress testing can be achieved by running multiple invocations of SendIP in parallel - SendIP is almost entirely CPU-bound, so if the number of invocations of it is limited to the number of CPU cores on the system, all can run with almost perfect parallelism. As one example, on a 24-core system (Intel E5-2640 CPUs at 2.50GHz), we were able to generate and send over 500,000 packets per second using 20 invocations of SendIP in parallel.
Q: Which headers and protocols are supported? A: ipv4 (including ipip, aka 4in4), ipv6 (including 6in4, 4in6 and 6in6), icmp, icmpv6, tcp, udp, bgp, rip, ripng, ntp, ah, dest, esp, frag, gre, hop, route, wesp. For more information, see the manual entry.
Q: What operating systems does SendIP run on? A: The original SendIP has support for a number of operating systems, including various versions of FreeBSD, Solaris, and Linux. The additions here have only been tested on Linux (specifically, recent Fedora and Ubuntu releases); they may well work elsewhere as well, but this is totally untested.
Q: How does looping work? A: Normally, each invocation of sendip produces exactly one packet. If, however, a -l N argument is supplied, it runs N times, producing N packets. The packets will all be identical unless one or more arguments are either random (rN) or taken from a file (fF); see below.
Q: How are string and numeric arguments handled? A: Many of the header fields, and the packet data area, can be specified via the following syntax:
Q: How do file (fF) arguments work? A: Argument values may be stored in files; every time a file argument of the form fF appears, the next line from file F is then read in and substituted for the corresponding argument.
For example, assume the file F contains the four lines:
Then the arguments
would produce two UDP packets, one to 10.1.1.1:1000 and one to 10.1.1.2:2000. When the lines in the file are exhausted, it is rewound and read from the beginning again. (Actually, for the sake of efficiency, the entire file is read into memory at the start of the program, so "rewinding" simply means moving a pointer back to the start of the memory area.)
Q: How do timestamp (tN) arguments work? A: An argument of the form tN is replaced by a struct timeval timestamp, produced by a call to gettimeofday(), padded out with the appropriate number of nulls. (On 64-bit systems, the timestamp occupies 16 bytes, so this would be N-16 nulls. If N is less than 16, the timestamp is truncated.) The timestamp is in host byte order, simply the exact binary form obtained by gettimeofday().
If this is embedded in the data portion of a packet, the receiver can get an idea of the end-to-end latency by comparing this value with that produced by gettimeofday() on the local system - assuming, of course, that sender and receiver clocks are sufficiently well coordinated. A test program which demonstrates this (udptimer) is included with the source.
Q: What is the IPsec support? A: Basic creation of AH and ESP headers (and trailers, in the case of ESP) is supported. In addition, external authentication and/or encryption modules may be called, to give more realistic emulation of IPsec behavior.
Demonstration authentication and encryption modules are included, which simply xor a "key" with the appropriate packet contents; these are obviously not intended to provide any actual security, but rather as an indication of how the module interfaces work. They should suffice for some purposes, though, such as testing heuristics for identifying ESP NULL packets.
Q: Why is the Wrapped ESP (WESP) support "provisional"? A: As of this writing, WESP is still in draft form, with no real implementations to compare against. So the code will quite likely need some revision when the final RFC is issued.
Q: How "alpha" is the alpha version? A: Pretty alpha. Much of the code has not been tested yet, since we are still developing the code we were going to test it against. It compiles nicely, though.
Q: Will you make RPMs for SendIP A: Probably. There's already a spec file, so it's really just a matter of housekeeping. Perhaps when the next non-alpha version is released.
Q: What is the license for SendIP? A: The original version is distributed under the GNU General Public License (GPL) version 2, and hence this version is, too. More precisely, the code developed here, as being, in a sense, a U.S. government publication, is technically in the public domain, but since it consists of extensions to GPL code and is provided along with such code, in practice the GPL applies to it as well.
Point Of Contact:
Last update: Mon, April 27, 2015