When building a large mtu probe packet, TCP may coalesce packets.
Verify that it also correctly coalesces the tx timestamp request.
This exposes a bug due to missing support in tcp_mtu_probe. Though
with the following change to that function:
- size_needed = probe_size + (tp->reordering + 1) * tp->mss_cache;
+ size_needed = probe_size;
Because
1. TCP associates a timestamp request with the last byte from send()
2. tcp_mtu_probe builds a probe from the oldest unacked bytes and
3. sized_needed exceeds probe_size
So the last byte in the current send call always > probe_size.
So this bug is rare and not easy to trigger deterministically from a
script without the above hack. But it may happen with more outstanding
unacked data.
Signed-off-by: Willem de Bruijn <willemb@google.com>

Add tests that combine MSG_ZEROCOPY with MSG_FASTOPEN.
The fastopen-client test verifies that an active fastopen with
zerocopy will result in a zerocopy notification on the socket.
The fastopen-server test verifies that a server with the SO_ZEROCOPY
option set can send in SYN_RECV state. Also that this data generates
a notification -- but as it uses the normal send path, that is more
obvious.
Based on earlier patches by Neal Cardwell and Yuchung Cheng.
Signed-off-by: Willem de Bruijn <willemb@google.com>

Verify that a sendmsg() on a socket with SO_ZEROCOPY set does not
increment the notification counter (sk_zckey) when sendmsg is called
in a wrong tcp state.
Signed-off-by: Willem de Bruijn <willemb@google.com>

Fix the following misleading error msg introduced in commit:
net-test: packetdrill: loose segmentation checks (non-strict by default now)
which implements loose segment check:
1. Subtract isn from tcp_seq/ack_seq for all segments so error msg
displays those sequence number correctly
2. when segment length is not expected, print expected and actual total
length seen apart from the expected and actual length of this segment.
Change-Id: I4138c357d5b69ac6025156ee7e91fa2bb128707a

…lt now)
This patch adds "loose segmentation checks" for packetdrill.
Now, by default, if a packetdrill test says the kernel under test
should send a TCP segment with N bytes, the test will pass as long as
the kernel under test sends some combination of in-order packets
starting at that sequence number that add (in a reasonable way) up to
N bytes.
This allows tests written assuming TSO/GSO to pass whether the system
under test is using TSO/GSO or not. The packetdrill interpreter will
allow either. And if the TCP stack changes its TSO autosizing
decisions, most tests should still pass.
If you want the old-style behavior, with strict checks, pass the new
command line flag: --strict_segments. Tests that are testing that TSO
autosizing behaves in a certain way can use this flag.
---
Background:
We want to improve remote mode support for existing packetdrill tests.
This patch adds packet aggregation for outbound packet events to allow
remote mode execution of scripts that expect TSO or GSO segmentation.
Note:
This design idea is from Neal Cardwell <ncardwell@google.com>.
This change is mostly written by Gabriel Marin <gmx@google.com>
and small change made by Wei Wang <weiwan@google.com>.
Change-Id: Ie30490fc40e52b1bf94f9fece74c3ad7cd1022b1

…s in code.c
This is a fix for a bug reported this week upstream on the packetdrill
list:
https://groups.google.com/d/msg/packetdrill/N_-UyvGrtIM/QKEtQljTCgAJ
We recently pushed an update to packetdrill that knows about more
recent fields of tcp_info (192 bytes worth of fields). But some
distributions have kernels that are older. In a recent bug report, the
OS only exports 104 bytes, which met packetdrill's previous
expectations, but does not meet the expectations of the more recent
packetdrill release.
In general, there is no easy way for packetdrill to tell how old the
kernel is in order to validate the amount of data returned by
tcp_info. So this commit removes this size check from the packetdrill
tool. This will mean that fields not exported by the kernel under test
will be zero (get_data() in code.c uses calloc()).
There are other potential approaches, but this seems like a simple
fix.
Reported-by: Wang Jian <jianjian.wang1@gmail.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Change-Id: I968718c37b387cbb38eda570a1261e6b917aec8c

As far as TCP is concerned, a GRO packet simply has a gso_size attribute,
which express the size of every MSS included in the packet.
A normal GRO packet would also have a gso_segs, but TCP stack does not
use this information (yet). User space can not set it, linux stack
uses the SKB_GSO_DODGY bit because we would not trust user space to
provide this information.
For the moment, we do not expect changing gso_size dynamically,
but this could be done later if needed.
--mss=xxxx can be used as a command line parameter or in
a packetdrill scenario.
Change-Id: I7431bbefde79619adab5fcc89bccb0b48d6b909d

It can cost a little more than 10ms to enable timestamps in
net_enable_timestamp(), due to the static key operation.
This commit uses a fix from Eric Dumazet: tweak packetdrill to pay the
non-trivial latency cost to enable timestamps during initialization,
before the test script starts, to avoid significant delays in the
middle of tests.
Since there is no timestamp yet from this socket, this call will
return -1 with errno=ENOENT, but we don't care, and I would rather not
bake in a dependency on that exact result by asserting that we always
get exactly that error.
Change-Id: Iac2915b1c5db7e3c7df1be0d81c3fef795d87e58

…ept(), and open()
This commit makes it possible for a packetdrill script to declare that
it expects failure (negative return code) from socket(), accept(), or
open(). This patch is identical to one written by Neal Cardwell, plus
also includes very simple unit tests for the new functionality.
Change-Id: I4f1182d886ab49a1ea094b82cefe319e24514d8a

Implement the sendfile system call. Offset is treated as only an input
parameter, though still in brackets.
sendfile is useful when we want the stack to send non linear skbs, as this is
helpful for reproducing some bugs and scenarios.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>

When doing getsockopt, the c-string stored in the expression string may
not be null terminated, so the latter strcmp() in syscall_getsockopt()
may fail randomly.
A similar fix was independently provided by Thadeu Lima de Souza
Cascardo <cascardo@redhat.com> as:
[PATCH] packetdrill: Zero out last string byte
Change-Id: I946beb0b63afd378c454ecf65c57a1862f8407d7

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

…mote mode
Fix the packet header location calculations in packet_append_header()
forgot to account for the fact that there might be layer 2 headers.
Remote mode has been broken since the addition of encapsulation
support, partly due to this issue.
Change-Id: Idfb0670da8799e11fe1b72771ed13d52d8e991fe

packet_buffer_to_string() needs to accont for the fact that
packet->ip_bytes does not capture the full length of the packet (in
remote mode there will be layer 2 ethernet headers as well).
Change-Id: If2c95e68071545a27078141b6ba5f98cd2c46fb9

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

…art a run.
The --dry_run command line flag causes packetdrill to verify command
line args, load and parse the given script, but not execute it. If any
errors are found during these steps, packetdrill will print an error
as before. Otherwise, it will exit(0) and produce no output.
Change-Id: Ibf4502c6ea326539346a58b58d7feb29d4b3da69