summaryrefslogtreecommitdiffhomepage
path: root/test/packetimpact/tests/BUILD
AgeCommit message (Collapse)Author
2020-08-06Join IPv4 all-systems group on NIC enableGhanan Gowripalan
Test: - stack_test.TestJoinLeaveMulticastOnNICEnableDisable - integration_test.TestIncomingMulticastAndBroadcast PiperOrigin-RevId: 325185259
2020-07-29Test UDP socket bound to ANY can receive unicastJay Zhuang
PiperOrigin-RevId: 323773771
2020-07-22make connect(2) fail when dest is unreachableKevin Krakauer
Previously, ICMP destination unreachable datagrams were ignored by TCP endpoints. This caused connect to hang when an intermediate router couldn't find a route to the host. This manifested as a Kokoro error when Docker IPv6 was enabled. The Ruby image test would try to install the sinatra gem and hang indefinitely attempting to use an IPv6 address. Fixes #3079.
2020-07-17Test UDP packets with mcast source addr are discardedJay Zhuang
PiperOrigin-RevId: 321790802
2020-07-14Test IPv6 fragment reassemblyZeling Feng
A packetimpact test for: "A node must be able to accept a fragmented packet that, after reassembly, is as large as 1500 octets." PiperOrigin-RevId: 321210729
2020-07-13Create packetimpact test for UDP broadcastJay Zhuang
PiperOrigin-RevId: 321000340
2020-07-07Set IPv4 ID on all non-atomic datagramsTony Gong
RFC 6864 imposes various restrictions on the uniqueness of the IPv4 Identification field for non-atomic datagrams, defined as an IP datagram that either can be fragmented (DF=0) or is already a fragment (MF=1 or positive fragment offset). In order to be compliant, the ID field is assigned for all non-atomic datagrams. Add a TCP unit test that induces retransmissions and checks that the IPv4 ID field is unique every time. Add basic handling of the IP_MTU_DISCOVER socket option so that the option can be used to disable PMTU discovery, effectively setting DF=0. Attempting to set the sockopt to anything other than disabled will fail because PMTU discovery is currently not implemented, and the default behavior matches that of disabled. PiperOrigin-RevId: 320081842
2020-07-01TCP receive should block when in SYN-SENT state.Mithun Iyer
The application can choose to initiate a non-blocking connect and later block on a read, when the endpoint is still in SYN-SENT state. PiperOrigin-RevId: 319311016
2020-06-30Fix two bugs in TCP sender.Bhasker Hariharan
a) When GSO is in use we should not cap the segment to maxPayloadSize in sender.maybeSendSegment as the GSO logic will cap the segment to the correct size. Without this the host GSO is not used as we end up breaking up large segments into small MSS sized segments before writing the packets to the host. b) The check to not split a segment due to it not fitting in the receiver window when there are pending segments is incorrect as segments in writeList can be really large as we just take the write call's buffer size and create a single large segment. So a write of say 128KB will just be 1 segment in the writeList. The linux code checks if 1 MSS sized segments fits in the receiver's window and if not then does not split the current segment. gVisor's check was incorrect that it was checking if the whole segment which could be >>> 1 MSS would fit in the receiver's window. This was causing us to prematurely stop sending and falling back to retransmit timer/probe from the other end to send data. This was seen when running HTTPD benchmarks where @ HEAD when sending large files the benchmark was taking forever to run. The tcp_splitseg_mss_test.go is being deleted as the test as written doesn't test what is intended correctly. This is because GSO is enabled by default and the reason the MSS+1 sized segment is sent is because GSO is in use. A proper test will require disabling GSO on linux and netstack which is going to take a bit of work in packetimpact to do it correctly. Separately a new test probably should be written that verifies that a segment > availableWindow is not split if the availableWindow is < 1 MSS. Fixes #3107 PiperOrigin-RevId: 319172089
2020-06-26Packetimpact test for IPv6 unknown options actionZeling Feng
The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: 00 - skip over this option and continue processing the header. 01 - discard the packet. 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. PiperOrigin-RevId: 318566613
2020-06-15TCP to honor updated window size during handshake.Mithun Iyer
In passive open cases, we transition to Established state after initializing endpoint's sender and receiver. With this we lose out on any updates coming from the ACK that completes the handshake. This change ensures that we uniformly transition to Established in all cases and does minor cleanups. Fixes #2938 PiperOrigin-RevId: 316567014
2020-06-11Add test for reordering.Ian Gudger
Tests the effect of reordering on retransmission and window size. Test covers the expected behavior of both Linux and netstack, however, netstack does not behave as expected. Further, the current expected behavior of netstack is not ideal and should be adjusted in the future. PiperOrigin-RevId: 316015184
2020-06-05Handle TCP segment split cases as per MSS.Mithun Iyer
- Always split segments larger than MSS. Currently, we base the segment split decision as a function of the send congestion window and MSS, which could be greater than the MSS advertised by remote. - While splitting segments, ensure the PSH flag is reset when there are segments that are queued to be sent. - With TCP_CORK, hold up segments up until MSS. Fix a bug in computing available send space before attempting to coalesce segments. Fixes #2832 PiperOrigin-RevId: 314802928
2020-06-03Avoid TCP segment split when out of sender window.Mithun Iyer
If the entire segment cannot be accommodated in the receiver advertised window and if there are still unacknowledged pending segments, skip splitting the segment. The segment transmit would get retried by the retransmit handler. PiperOrigin-RevId: 314538523
2020-05-29Test TCP should queue RECEIVE request in SYN-SENTZeling Feng
PiperOrigin-RevId: 313878910
2020-05-29Move TCP to CLOSED from SYN-RCVD on RST.Mithun Iyer
RST handling is broken when the TCP state transitions from SYN-SENT to SYN-RCVD in case of simultaneous open. An incoming RST should trigger cleanup of the endpoint. RFC793, section 3.9, page 70. Fixes #2814 PiperOrigin-RevId: 313828777
2020-05-29Internal change.gVisor bot
PiperOrigin-RevId: 313821986
2020-05-26Automated rollback of changelist 311424257gVisor bot
PiperOrigin-RevId: 313300554
2020-05-20Test that we have PAWS mechanismZeling Feng
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
2020-05-20Internal change.gVisor bot
PiperOrigin-RevId: 312559963
2020-05-14Internal change.gVisor bot
PiperOrigin-RevId: 311645222
2020-05-13Fix TCP segment retransmit timeout handling.Mithun Iyer
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
2020-05-13Automated rollback of changelist 311285868Bhasker Hariharan
PiperOrigin-RevId: 311424257
2020-05-13Replace test_runner.sh bash script with Go.Ian Gudger
PiperOrigin-RevId: 311285868
2020-05-08Add UDP send/recv packetimpact tests.Bhasker Hariharan
Fixes #2654 PiperOrigin-RevId: 310642216
2020-05-08Send ACK to OTW SEQs/unacc ACKs in CLOSE_WAITZeling Feng
This fixed the corresponding packetimpact test. PiperOrigin-RevId: 310593470
2020-05-05Support TCP zero window probes.Mithun Iyer
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
2020-04-28Internal change.gVisor bot
PiperOrigin-RevId: 308940886
2020-04-24Add ICMP6 param problem testEyal Soha
Tested: When run on Linux, a correct ICMPv6 response is received. On netstack, no ICMPv6 response is received. PiperOrigin-RevId: 308343113
2020-04-19Don't accept segments outside the receive windowEyal Soha
Fixed to match RFC 793 page 69. Fixes #1607 PiperOrigin-RevId: 307334892
2020-04-19Convert tcp_user_timeout test from packetdrill to packetimpact.Eyal Soha
PiperOrigin-RevId: 307328289
2020-04-16Test TCP behavior when receiving unacceptable segment in CLOSE_WAITgVisor bot
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
2020-04-15Add tests for segments outside the receive window.Eyal Soha
The tests are based on RFC 793 page 69. Updates #1607 PiperOrigin-RevId: 306768847
2020-04-15Reset pending connections on listener closeMithun Iyer
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
2020-04-14Test TCP should piggyback ACK in ESTAB stategVisor bot
TCP, in ESTABLISHED state, SHOULD piggyback acknowledgement with a segment being transmitted (whenever possible) without incurring undue delay PiperOrigin-RevId: 306474550
2020-04-10Test that RST is sent after ABORT in ESTABLISHED TCP state.Eyal Soha
PiperOrigin-RevId: 305879441
2020-04-07Test TCP sender behavior against window shrinkinggVisor bot
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
2020-03-31Test receiving multicast packets over UDPEyal Soha
PiperOrigin-RevId: 304098611
2020-03-17Packetimpact in Go with c++ stubEyal Soha
PiperOrigin-RevId: 301382690
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 17:18:21 +0000