not yet used.

MacOS does not support pcap_setdirection() for PCAP_D_OUT.
Instead use only a single pcap handle (as it was originally) and
add a capture filter to only filter the packets in the expected
direction.
Only packets sent by the machine under test needs to be captured.

This requires the tunneling devices to be used in P2P mode. So
pass the gateway address around.
This is not working:
* Can't configure IPv6 addresses on utun devices.
* Can't use libpcap on utun devices
* Can't use libpcap as currently being used (taking the direction
  into account.

On *BSD platforms the original version always used the tun0 device
in local mode and never deleted it, except on NetBSD. This was
handy when using for example Wireshark for capturing trafic.
The last commit removed this possibility, since it removes the
interface. Add the --persistent_tun_dev command line option
to bring it back.

To get the behaviour of the original version, use on *BSD
platforms --tun-dev=tun0 --persistent_tun_dev.

When using local mode on *BSD, using the tun0 device was hard
coded in contrast to Linux, where the next unused tun device
was used.
This patch changes the behaviour on *BSD to use the next unused
tun device. This also requires that the device is removed when
packetdrill terminates. This was the case on Linux, but not on
*BSD.
On *BSD there is also a new command line option (--tun-dev) to
set the device name and not select an ephemerial one.

This adds support for SCTP/UDP and TCP/UDP including ICMP
support.

Sponsored by:	Netflix, Inc.

Thanks to bz@ for providing a hint how to work around a FreeBSD
bug.

For FreeBSD use ioctl() to set the speed and mtu of the tun
interface instead of the Linux specific ethtool for the speed.
Also ensure that you can set the MTU to the default value in
case it is configured to a different one.
On non-FreeBSD platforms restore the old behaviour.
This fixes https://github.com/nplab/packetdrill/issues/17

If the interface MTU was previously set to a non-default value
and in a later run should be set to the default value, it was
not set correctly. With this patch, the MTU is always set.

linux/version.h. At least not on Rasbian. So take out the last
change and just try to set TUN_F_UFO and ignore if it worked
or not.
This allows to run packetdrill on a Raspberry Pi running Rasbian.

Current limitations:
* Chunk parameters are not yet supported.
* Error causes are not yet supported.
* Chunks can't be bundled with COOKIE-ECHO chunks.
* Chunk flags are not supported.
* Chunk lengths are not supported.
* Gap reports and duplicate TSNs are not supported for SACK chunks.
* SCTP related ICMP messages are not supported.
This version is only tested in a limited way, only on FreeBSD and
only in local mode.

This commit adds support for UDPLite as specified in RFC 3828
and the corresponding socket options.
It is tested on FreeBSD 10.1 and Linux, the platforms supporting
UDPLite.

Signed-off-by: Michael Tuexen <tuexen@fh-muenster.de>

This patch makes sure that all heaaders start at a four byte
boundary. This is done by not having the ethernet header, which
is 14 bytes long, in the packet buffer.
This fixes the remote mode for platforms having strict alignment
restrictions, like ARM. Without this patch you can't use the remote
mode on a Rasperry Pi running FreeBSD.
This patch has been tested on Linux (Intel) in local and remote mode
and one FreeBSD (Intel and ARM) in local and remote mode.

Signed-off-by: Michael Tuexen <tuexen@fh-muenster.de>

In local mode, read the outbound packets from the tun device.

A recent Linux patch "tcp: avoid retransmits of TCP packets hanging in
host queues" means that TCP behavior now depends on whether and when
the network device (tun device here) consumes the packets. We now read
all these packets so that the kernel can exercise its normal code
paths for packet transmit completion.

An alternative approach would be to set the tun txqueuelen to 0, but
this would impact qdisc behavior. It is more realistic, and has fewer
side-effects, to make sure the network device has a non-zero queue
length, but packets are still consumed.

Change-Id: Ia922994d4eeea12e61d7876b4c4ef34bc9cef34e

Fix wire_server_netdev_receive() to reflect the fact that in remote
mode the server is sniffing packets that are inbound (whereas in local
mode we are sniffing *outbound* packets).

This was a bug introduced in "net-test: packetdrill encap
support: refactor packet receive loops into one loop".

Remote mode has been broken since the addition of encapsulation
support, partly due to this issue.

Change-Id: Ia92f70f48ae90cb2e089ee51d728473a12c63595

Allow the --remote_ip config parameter to be a prefix, not just a
single address. The entire remote prefix is routed to the tun device
or remote packetdrill machine.

The goal here is to all tests to use more than one remote IP. The
immediate motivation is testing GRE, where there is a remote IP for
the TCP endpoint and a separate remote IP for the GRE decapsulator.
But eventually we'll also want to allow testing multiple concurrent
TCP connections from multiple remote IPs addresses as well.

Here are examples of the remote prefix you get for various values of
the --remote_ip field. These are chosen for convenience and backwards
compatibility with existing tests that are already using the
--remote_ip parameter.

o Default:

configuration                      remote prefix
------------------------------     -----------------
IPv4, no --remote_ip            -> 192.0.2.0/24   (default)
v4/6, no --remote_ip            -> 192.0.2.0/24   (default)
IPv6, no --remote_ip            -> 2001:DB8::0/32 (default)

o Explicit IP without prefix length (prefix includes all bits):

configuration                      remote prefix
------------------------------     -----------------
IPv4 --remote_ip=10.248.0.3     -> 10.248.0.3/32
v4/6 --remote_ip=10.248.0.3     -> 10.248.0.3/32
IPv6 --remote_ip=2001:db8::3    -> 2001:db8::3/128

o Explicit with prefix length:

configuration                      remote prefix
------------------------------     -----------------
IPv4 --remote_ip=10.248.0.3/16  -> 10.248.0.0/16
v4/6 --remote_ip=10.248.0.3/16  -> 10.248.0.0/16
IPv6 --remote_ip=2001:db8::3/16 -> 2001::0/16

Change-Id: Ibc95c3419d66bcf1bbfd8a1fc7650d0003345ef2

When we sniff an unknown packet, free it and allocate another packet
at the top of the sniffing loop. Previously we were not clearing state
after parsing an unknown packet, so state from the unkbown packet
could linger on, co-mingling with state from the next sniffed packet.


Change-Id: Ia9a330766969b114fd6084a087ff3f0d6b11d9d4

Factor out the packet sniffing loop that's common to local and remote
mode, since it is nearly identical in both cases. This is in
preparation for fixing a bug that is found in both loops, so we can
make the fix in just one place.


Change-Id: Ic9a9b84b66a9f812866b1e29cd7c897f7c1d40cf

Initial commit for the packetdrill network stack testing tool:

  https://code.google.com/p/packetdrill/



Signed-off-by: Neal Cardwell <ncardwell@google.com>