#
e7fbf52a |
| 09-Jan-2025 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: remove dead code
No functional change intended.
Reviewed by: Peter Lei, rrs (earlier version) CID: 1523802 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https:/
TCP BBR: remove dead code
No functional change intended.
Reviewed by: Peter Lei, rrs (earlier version) CID: 1523802 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48341
show more ...
|
#
061727ef |
| 06-Jan-2025 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: remove dead code
No functional change intended.
Reviewed by: rrs CID: 1523808 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48338
|
#
c28fefe1 |
| 06-Jan-2025 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: remove dead code
bw is unsigned and not zero. So it cannot be smaller than 1. No functional change intended.
Reviewed by: rrs, cc CID: 1523791 MFC after: 1 week Sponsored by: Netflix,
TCP BBR: remove dead code
bw is unsigned and not zero. So it cannot be smaller than 1. No functional change intended.
Reviewed by: rrs, cc CID: 1523791 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48323
show more ...
|
#
4bce1a19 |
| 04-Jan-2025 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: remove code which is not needed
rc_bbr_substate is a 3-bit unsigned int, so it can't be larger than or equal to 8. The wrap around already happens. No functional change intended.
Reviewed
TCP BBR: remove code which is not needed
rc_bbr_substate is a 3-bit unsigned int, so it can't be larger than or equal to 8. The wrap around already happens. No functional change intended.
Reviewed by: rrs CID: 1523795 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48320
show more ...
|
#
305c40dc |
| 04-Jan-2025 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: simplify expression
There is no need to check partially for bbr->r_ctl.crte being NULL, since this can't be true in this path. No functional change intended.
Reviewed by: rrs CID: 15238
TCP BBR: simplify expression
There is no need to check partially for bbr->r_ctl.crte being NULL, since this can't be true in this path. No functional change intended.
Reviewed by: rrs CID: 1523810 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48312
show more ...
|
#
88766e7a |
| 03-Jan-2025 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: fix integer overflow
Use 64-bit arithmetic.
Reviewed by: rrs CID: 1523806 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48302
|
#
4173a3a0 |
| 03-Jan-2025 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: simplify expression
rsm cannot be NULL, when calling bbr_update_bbr_info(). So no need to check partially for it. No functional change intended.
Reviewed by: rrs CID: 1523803 MFC after:
TCP BBR: simplify expression
rsm cannot be NULL, when calling bbr_update_bbr_info(). So no need to check partially for it. No functional change intended.
Reviewed by: rrs CID: 1523803 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48293
show more ...
|
#
c7e81cc0 |
| 02-Jan-2025 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: do not log an uninitialized value
Reviewed by: rrs CID: 1523789 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48281
|
#
1781324d |
| 01-Jan-2025 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: remove code which is never executed
USEC_2_TICKS() returns at least 1.
Reviewed by: rrs CID: 1523775 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://revie
TCP BBR: remove code which is never executed
USEC_2_TICKS() returns at least 1.
Reviewed by: rrs CID: 1523775 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D4827
show more ...
|
#
5ec914e0 |
| 31-Dec-2024 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: fix condition when sending a tail loss probe
Reviewed by: rrs CID: 1523793 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48274
|
#
b47dcb4b |
| 31-Dec-2024 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: fix getsockopt() for TCP_BBR_USEDEL_RATE
Actually implement the IPPROTO_TCP-level socket option TCP_BBR_USEDEL_RATE.
Reviewed by: rrs CID: 1523813 CID: 1523814 MFC after: 1 week Spon
TCP BBR: fix getsockopt() for TCP_BBR_USEDEL_RATE
Actually implement the IPPROTO_TCP-level socket option TCP_BBR_USEDEL_RATE.
Reviewed by: rrs CID: 1523813 CID: 1523814 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48261
show more ...
|
#
895347fc |
| 30-Dec-2024 |
Michael Tuexen <tuexen@FreeBSD.org> |
TCP BBR: remove assignments without effect
No functional change intended.
Reviewed by: rrs CID: 1523772 CID: 1523777 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: http
TCP BBR: remove assignments without effect
No functional change intended.
Reviewed by: rrs CID: 1523772 CID: 1523777 MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D48215
show more ...
|
Revision tags: release/14.2.0 |
|
#
12fc7961 |
| 15-Nov-2024 |
Randall Stewart <rrs@FreeBSD.org> |
Change the SOCKBUF_LOCK calls to use the more refined SOCK_XXXBUF_LOCK/UNLOCK.
The socket buffer locking used to be standard on SOCKBUF_LOCK/UNLOCK. But we are now moving to a more elegant SOCK_SEND
Change the SOCKBUF_LOCK calls to use the more refined SOCK_XXXBUF_LOCK/UNLOCK.
The socket buffer locking used to be standard on SOCKBUF_LOCK/UNLOCK. But we are now moving to a more elegant SOCK_SENDBUF_LOCK/UNLOCK and SOCK_RECVBUF_LOCK/UNLOCK. Lets get BBR and Rack to use these updated macros.
Reviewed by:glebius, tuexen, rscheff Differential Revision:https://reviews.freebsd.org/D47542
show more ...
|
#
c9047eb7 |
| 14-Nov-2024 |
Richard Scheffenegger <rscheff@FreeBSD.org> |
tcp: allow TSO even while RX path is unordered
Over IP networks, forward and return path largely act independently from each other. Do not disable LRO on the TX side, when reordering/loss is happeni
tcp: allow TSO even while RX path is unordered
Over IP networks, forward and return path largely act independently from each other. Do not disable LRO on the TX side, when reordering/loss is happening on the RX half-connection.
Reviewed By: rrs, #transport, peter.lei_ieee.org Sponsored by: NetApp, Inc. Differential Revision: https://reviews.freebsd.org/D47056
show more ...
|
#
87fbd9fc |
| 20-Sep-2024 |
Michael Tuexen <tuexen@FreeBSD.org> |
tcp: remove unused socket option names
These IPPROTO_TCP-level socket option names correspond to socket options, which are not implemented. So remove them. Thanks to Peter Lei for suggesting this ch
tcp: remove unused socket option names
These IPPROTO_TCP-level socket option names correspond to socket options, which are not implemented. So remove them. Thanks to Peter Lei for suggesting this change.
Reviewed by: rscheff, thj Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D46623
show more ...
|
Revision tags: release/13.4.0 |
|
#
b2044c45 |
| 30-Aug-2024 |
Michael Tuexen <tuexen@FreeBSD.org> |
tcp rack, bbr: improve handling of soft errors
Do not report an error, if it is stored as a soft error. This avoids, for example, the dropping of TCP connections using an interface, while enabling o
tcp rack, bbr: improve handling of soft errors
Do not report an error, if it is stored as a soft error. This avoids, for example, the dropping of TCP connections using an interface, while enabling or disabling LRO on that interface.
Reviewed by: cc MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D46427
show more ...
|
#
e0b080f8 |
| 21-Jul-2024 |
Michael Tuexen <tuexen@FreeBSD.org> |
tcp: mark TCP stacks which can serve as a default stack
Allow a TCP function block (tfb) to become the default stack only if tfb->tfb_flags has the TCP_FUNC_DEFAULT_OK flags set. This allows a TCP f
tcp: mark TCP stacks which can serve as a default stack
Allow a TCP function block (tfb) to become the default stack only if tfb->tfb_flags has the TCP_FUNC_DEFAULT_OK flags set. This allows a TCP function block, that is not suitable as a default function block to ensure that it is not set as the default via sysctl. In this case sysctl would return EINVAL.
Reviewed by: gallatin, Peter Lei Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D45419
show more ...
|
#
646c28ea |
| 21-Jul-2024 |
Michael Tuexen <tuexen@FreeBSD.org> |
tcp: improve SEG.ACK validation
Implement the improved SEG.ACK validation described in RFC 5961. In addition to that, also detect ghost ACKs, which are ACKs for data that has never been sent. The ad
tcp: improve SEG.ACK validation
Implement the improved SEG.ACK validation described in RFC 5961. In addition to that, also detect ghost ACKs, which are ACKs for data that has never been sent. The additional checks are enabled by default, but can be disabled by setting the sysctl-variable net.inet.tcp.insecure_ack to a non-zero value.
PR: 250357 Reviewed by: Peter Lei, rscheff (older version) MFC after: 1 week Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D45894
show more ...
|
#
c02a8caf |
| 28-Jun-2024 |
Ryan Libby <rlibby@FreeBSD.org> |
tcp_bbr: avoid gcc -Werror=pointer-to-int-cast on 32-bit arch
Reviewed by: tuexen Differential Revision: https://reviews.freebsd.org/D45751
|
Revision tags: release/14.1.0 |
|
#
fce03f85 |
| 05-May-2024 |
Randall Stewart <rrs@FreeBSD.org> |
TCP can be subject to Sack Attacks lets fix this issue.
There is a type of attack that a TCP peer can launch on a connection. This is for sure in Rack or BBR and probably even the default stack if i
TCP can be subject to Sack Attacks lets fix this issue.
There is a type of attack that a TCP peer can launch on a connection. This is for sure in Rack or BBR and probably even the default stack if it uses lists in sack processing. The idea of the attack is that the attacker is driving you to look at 100's of sack blocks that only update 1 byte. So for example if you have 1 - 10,000 bytes outstanding the attacker sends in something like:
ACK 0 SACK(1-512) SACK(1024 - 1536), SACK(2048-2536), SACK(4096 - 4608), SACK(8192-8704) This first sack looks fine but then the attacker sends
ACK 0 SACK(1-512) SACK(1025 - 1537), SACK(2049-2537), SACK(4097 - 4609), SACK(8193-8705) ACK 0 SACK(1-512) SACK(1027 - 1539), SACK(2051-2539), SACK(4099 - 4611), SACK(8195-8707) ... These blocks are making you hunt across your linked list and split things up so that you have an entry for every other byte. Has your list grows you spend more and more CPU running through the lists. The idea here is the attacker chooses entries as far apart as possible that make you run through the list. This example is small but in theory if the window is open to say 1Meg you could end up with 100's of thousands link list entries.
To combat this we introduce three things.
when the peer requests a very small MSS we stop processing SACK's from them. This prevents a malicious peer from just using a small MSS to do the same thing. Any time we get a sack block, we use the sack-filter to remove sacks that are smaller than the smallest v4 mss (minus 40 for max TCP options) unless it ties up to snd_max (since that is legal). All other sacks in theory should be at least an MSS. If we get such an attacker that means we basically start skipping all but MSS sized Sacked blocks. The sack filter used to throw away data when its bounds were exceeded, instead now we increase its size to 15 and then throw away sack's if the filter gets over-run to prevent the malicious attacker from over-running the sack filter and thus we start to process things anyway. The default stack will need to start using the sack-filter which we have talked about in past conference calls to take full advantage of the protections offered by it (and reduce cpu consumption when processing sacks).
After this set of changes is in rack can drop its SAD detection completely
Reviewed by:tuexen@, rscheff@ Differential Revision: <https://reviews.freebsd.org/D44903>
show more ...
|
#
c9cd686b |
| 18-Apr-2024 |
Michael Tuexen <tuexen@FreeBSD.org> |
tcp: drop data received after a FIN has been processed
RFC 9293 describes the handling of data in the CLOSE-WAIT, CLOSING, LAST-ACK, and TIME-WAIT states: This should not occur since a FIN has been
tcp: drop data received after a FIN has been processed
RFC 9293 describes the handling of data in the CLOSE-WAIT, CLOSING, LAST-ACK, and TIME-WAIT states: This should not occur since a FIN has been received from the remote side. Ignore the segment text. Therefore, implement this handling.
Reviewed by: rrs, rscheff MFC after: 3 days Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D44746
show more ...
|
#
605a0066 |
| 15-Apr-2024 |
Michael Tuexen <tuexen@FreeBSD.org> |
tcp bbr: improve code consistency
Improve code consistency with the RACK stack. Reviewed by: gallatin, rscheff MFC after: 3 days Sponsored by: Netflix, Inc. Differential Revision: https://reviews
tcp bbr: improve code consistency
Improve code consistency with the RACK stack. Reviewed by: gallatin, rscheff MFC after: 3 days Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D44800
show more ...
|
#
dd7b86e2 |
| 18-Mar-2024 |
Gleb Smirnoff <glebius@FreeBSD.org> |
tcp: remove IS_FASTOPEN() macro
The macro is more obfuscating than helping as it just checks a single flag of t_flags. All other t_flags bits are checked without a macro.
A bigger problem was that
tcp: remove IS_FASTOPEN() macro
The macro is more obfuscating than helping as it just checks a single flag of t_flags. All other t_flags bits are checked without a macro.
A bigger problem was that declaration of the macro in tcp_var.h depended on a kernel option. It is a bad practice to create such definitions in installable headers.
Reviewed by: rscheff, tuexen, kib Differential Revision: https://reviews.freebsd.org/D44362
show more ...
|
#
e18b97bd |
| 12-Mar-2024 |
Randall Stewart <rrs@FreeBSD.org> |
Update to bring the rack stack with all its fixes in.
This brings the rack stack up to the current level used at NF. Many fixes and improvements have been added. I also add in a fix to BBR to deal w
Update to bring the rack stack with all its fixes in.
This brings the rack stack up to the current level used at NF. Many fixes and improvements have been added. I also add in a fix to BBR to deal with the changes that have been in hpts for a while i.e. only one call no matter if mbuf queue or tcp_output.
It basically does little except BBlogs and is a placemark for future work on doing path capacity measurements.
With a bit of a struggle with git I finally got rack_pcm.c into place (apologies for not noticing this error). The LINT kernel is running on my box now .. sigh.
Reviewed by: tuexen, glebius Sponsored by: Netflix Inc. Differential Revision:https://reviews.freebsd.org/D43986
show more ...
|
#
c112243f |
| 11-Mar-2024 |
Brooks Davis <brooks@FreeBSD.org> |
Revert "Update to bring the rack stack with all its fixes in."
This commit was incomplete and breaks LINT kernels. The tree has been broken for 8+ hours.
This reverts commit f6d489f402c320f1a6eaa4
Revert "Update to bring the rack stack with all its fixes in."
This commit was incomplete and breaks LINT kernels. The tree has been broken for 8+ hours.
This reverts commit f6d489f402c320f1a6eaa473491a0b8c3878113e.
show more ...
|