Age | Commit message (Collapse) | Author |
|
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
|
|
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
|
|
- 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
|
|
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
|
|
PiperOrigin-RevId: 313878910
|
|
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
|
|
PiperOrigin-RevId: 313821986
|
|
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
|
|
Fixes #2654
PiperOrigin-RevId: 310642216
|
|
This fixed the corresponding packetimpact test.
PiperOrigin-RevId: 310593470
|
|
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: 308940886
|
|
Tested:
When run on Linux, a correct ICMPv6 response is received. On netstack, no
ICMPv6 response is received.
PiperOrigin-RevId: 308343113
|
|
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
|
|
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
|
|
PiperOrigin-RevId: 305879441
|
|
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: 301382690
|