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.
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.
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: Thu, February 12, 2015