Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Dirk Ziegelmeier <dirk@ziegelmeier.net>
(cherry picked from commit 9bbb741247cc4dc6bb748498218addbd79d82372)
while ((q != NULL) && (options[offset] != DHCP_OPTION_END) && (offset < offset_max)) {
should be
while ((q != NULL) && (offset < offset_max) && (options[offset] != DHCP_OPTION_END)) {
See https://jira.reactos.org/browse/CORE-8978 for more info.
(cherry picked from commit 32aa9a41e2013e5ee6eee09317a848647e37badf)
The value should be dereferenced after
assertion is performed. This can lead
to crash
(cherry picked from commit 7eba14cb76a131f262c2a760df4bb9402f315a64)
In assertion the pointer that is potentialy
null is dereferenced. The check for null was
located after.
(cherry picked from commit eba1b971c024e489c4dadff98ed4a4c4aeb64465)
Moved the debug output to a location where we know that newpcb != NULL
Fixes possible NULL pointer dereferencing in debug message output
(cherry picked from commit 9e20fe2cfb01428e366e97fc0366cff9920ae921)
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 b90a54f989d0edafa36b29bb0c346d1b30e1bf8f
This fixes the test by enforcing the requirement of starting in
congestion avoidance
Signed-off-by: goldsimon <goldsimon@gmx.de>
(cherry picked from commit 8bf402fd678def9396d7f951531e75a239de8a12)
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.
(cherry picked from commit 5827c168c28b43d98ffbf91f45c38a054e848eda)
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
(cherry picked from commit b90a54f989d0edafa36b29bb0c346d1b30e1bf8f)
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).
(cherry picked from commit e16d10ade6204a2f896eb872fb5075bec8e5164f)
