test_tcp_fast_rexmit_wraparound correctness relied on the congestion
window being in congestion avoidance so that only a single TCP_MSS
segment is sent upon ACKing the first segment.
It's not known whether the test was relying tcp_alloc() to set ssthresh
to 0 and thus start in congestion avoidance or if the test was working by
accident until changes in b90a54f989
This fixes the test by enforcing the requirement of starting in
congestion avoidance
Signed-off-by: goldsimon <goldsimon@gmx.de>
If a locally generated TCP SYN packet is replied to with an ACK
packet, lwIP immediately sends a RST packet followed by resending the
SYN packet. This is expected, but on loopback interfaces the resent
SYN packet may immediately get another ACK reply, typically when the
other endpoint is in TIME_WAIT state (which ignores the RSTs). The
result is an endless loop of SYN, ACK, RST packets.
This patch applies the normal SYN retransmission limit in this
scenario, such that the endless loop is limited to a brief storm.
This commit changes ssthresh to be the largest effective congestion
window (amount of in-flight data). This follows the guidance of RFC
5681 which recommends setting ssthresh arbitrarily high.
LwIP was previously using the receive window value at the end of the
3-way handshake and in the case of an active open where the receiver
used window scaling and/or window auto-tuning, this resulted in a very
small ssthresh value even though the window ramped up once the connection
was established
User should not use ppp_connect or ppp_listen return value to retry
later, it must wait for the callback to be called. This is primarily
done this way to have a consistent behavior with and without the
holdoff feature.
Remove returned error value from PPP link level API connect and listen
callbacks because we are not using them anymore, then make ppp_connect
or ppp_listen to always return ERR_OK, thus we are not breaking the PPP
user API.
We don't need the return code here, all PPP link level drivers can't
fail at all (e.g. PPPoS) or retry if necessary (PPPoE and PPPoL2TP).
A bug was introduced in the atomic vector feature for blocking netconns
where if we couldn't write the entire vector due to send buffer being
full (write_more is 0), we would not update the vector state and then
when sent_tcp() is called, it would actually re-send the previous vector
and if additional calls were required to finish the write, msg.w.offset
would eventually exceed msg.w.len, This was found by testing "stats"
from the shell and hitting the LWIP_ASSERT in do_writemore() that
checks offset < len
The fix simply updates the vector state after every ERR_OK return from
tcp_write(). While not all cases (non-blocking sockets) need to update
the state in this case, it keeps the logic simple and also makes
debugging simpler because you don't have stale vector state at any
point
This commit adds support to the netconn write APIs to take an input of
vectors instead of a single data pointer
This allows vectors sent on a TCP connection via sendmsg to be treated
atomically. The set of vectors is segmented into as much data as can
fit into the send buffer and then the TCP output function is called
Previously, each vector was passed to netconn_write_partly and tcp_write
segmented it into its own packet, which was then it was sent via
tcp_output (if not Nagleing)
This commit adds vector support to lwip_netconn_do_writemore() which
is the meat of the TCP write functionality from netconn/sockets layer.
A new netconn API netconn_write_vectors_partly() takes a set of vectors
as input and hooks up to do_writemore()
This commit also defines IOV_MAX because we are limited to only
supporting 65535 vectors due to choice of u16_t for the vector count
