Age | Commit message (Collapse) | Author |
|
PiperOrigin-RevId: 313300554
|
|
If there is a Timestamps option in the arriving segment and SEG.TSval
< TS.Recent and if TS.Recent is valid, then treat the arriving segment
as not acceptable: Send an acknowledgement in reply as specified in
RFC-793 page 69 and drop the segment.
https://tools.ietf.org/html/rfc1323#page-19
PiperOrigin-RevId: 312590678
|
|
PiperOrigin-RevId: 312559963
|
|
PiperOrigin-RevId: 311645222
|
|
As per RFC 1122 and Linux retransmit timeout handling:
- The segment retransmit timeout needs to exponentially increase and
cap at a predefined value.
- TCP connection needs to timeout after a predefined number of
segment retransmissions.
- TCP connection should not timeout when the retranmission timeout
exceeds MaxRTO, predefined upper bound.
Fixes #2673
PiperOrigin-RevId: 311463961
|
|
PiperOrigin-RevId: 311424257
|
|
PiperOrigin-RevId: 311285868
|
|
PiperOrigin-RevId: 311011004
|
|
PiperOrigin-RevId: 310949277
|
|
Fixes #2654
PiperOrigin-RevId: 310642216
|
|
This fixed the corresponding packetimpact test.
PiperOrigin-RevId: 310593470
|
|
PiperOrigin-RevId: 310409922
|
|
As per RFC 1122 4.2.2.17, when the remote advertizes zero receive window,
the sender needs to probe for the window-size to become non-zero starting
from the next retransmission interval. The TCP connection needs to be kept
open as long as the remote is acknowledging the zero window probes.
We reuse the retransmission timers to support this.
Fixes #1644
PiperOrigin-RevId: 310021575
|
|
PiperOrigin-RevId: 309832671
|
|
PiperOrigin-RevId: 309467878
|
|
Previously the test used an out-dated window size which is advertised
during the handshake to generate testing packets, but the window size
has changed since the handshake; currently it is using the most recent
one which is advertised in DUT's ACK to our FIN packet to generate the
testing outside-the-window packets.
PiperOrigin-RevId: 309222921
|
|
PiperOrigin-RevId: 308940886
|
|
Tested:
When run on Linux, a correct ICMPv6 response is received. On netstack, no
ICMPv6 response is received.
PiperOrigin-RevId: 308343113
|
|
Display the errors as diffs between the expected and wanted frame.
PiperOrigin-RevId: 308333271
|
|
This change moves all Docker images to a standard location, and abstracts the
build process so that they can be maintained in an automated fashion. This also
allows the images to be architecture-independent.
All images will now be referred to by the test framework via the canonical
`gvisor.dev/images/<name>`, where `<name>` is a function of the path within the
source tree.
In a subsequent change, continuous integration will be added so that the images
will always be correct and available locally.
In the end, using `bazel` for Docker containers is simply not possible. Given
that we already have the need to use `make` with the base container (for
Docker), we extend this approach to get more flexibility.
This change also adds a self-documenting and powerful Makefile that is intended
to replace the collection of scripts in scripts. Canonical (self-documenting)
targets can be added here for targets that understand which images need to be
loaded and/or built.
PiperOrigin-RevId: 308322438
|
|
Tested:
Intentionally introduce an error and then run:
blaze test --test_output=streamed //third_party/gvisor/test/packetimpact/tests:tcp_outside_the_window_linux_test
PiperOrigin-RevId: 308114194
|
|
This change adds a layer of abstraction around the internal Docker APIs,
and eliminates all direct dependencies on Dockerfiles in the infrastructure.
A subsequent change will automated the generation of local images (with
efficient caching). Note that this change drops the use of bazel container
rules, as that experiment does not seem to be viable.
PiperOrigin-RevId: 308095430
|
|
This will make it easier to notice if a code change causes an existing test to
pass.
PiperOrigin-RevId: 308057978
|
|
Fixed to match RFC 793 page 69.
Fixes #1607
PiperOrigin-RevId: 307334892
|
|
PiperOrigin-RevId: 307328289
|
|
TCP, in CLOSE-WAIT state, MUST return ACK with proper SEQ and ACK numbers after
recv a seg with OTW SEQ or unacc ACK number, and remain in same state. If the
connection is in a synchronized state, any unacceptable segment (out of window
sequence number or unacceptable acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number and an
acknowledgment indicating the next sequence number expected to be received, and
the connection remains in the same state.
PiperOrigin-RevId: 306897984
|
|
The tests are based on RFC 793 page 69.
Updates #1607
PiperOrigin-RevId: 306768847
|
|
Rather than have a struct for the state of each type of connection, such as
TCP/IPv4, UDP/IPv4, TCP/IPv6, etc, have a state for each layer, such as UDP,
TCP, IPv4, IPv6. Those states can be composed into connections.
Tested:
Existing unit tests still pass/fail as expected.
PiperOrigin-RevId: 306703180
|
|
Attempt to redeliver TCP segments that are enqueued into a closing
TCP endpoint. This was being done for Established endpoints but not
for those that are listening or performing connection handshake.
Fixes #2417
PiperOrigin-RevId: 306598155
|
|
TCP, in ESTABLISHED state, SHOULD piggyback acknowledgement with a segment being
transmitted (whenever possible) without incurring undue delay
PiperOrigin-RevId: 306474550
|
|
Add Sniffer.Drain() which drains the socket's receive buffer by temporarily
setting the socket to non-blocking, and receiving in a loop until EINTR,
EWOULDBLOCK or EAGAIN. This method should be used when long periods of time
elapses without receiving on the socket, because uninteresting packets may have
piled up in the receive buffer, filling it up and causing packets critical to
test operation to be dropped.
PiperOrigin-RevId: 306380480
|
|
PiperOrigin-RevId: 305879441
|
|
PiperOrigin-RevId: 305466309
|
|
RFC 1122 Section 3.7: A sending TCP MUST be robust against window shrinking,
which may cause the "useable window" to become negative.
PiperOrigin-RevId: 305377072
|
|
PiperOrigin-RevId: 304098611
|
|
PiperOrigin-RevId: 301872161
|
|
PiperOrigin-RevId: 301382690
|