History log of /freebsd/sys/netinet/tcp_var.h (Results 1 – 25 of 765)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 0e58542f 25-Feb-2025 Peter Lei <peterlei@netflix.com>

tcp: remove unused field from struct tcpcb

Reviewed by: tuexen
Sponsored by: Netflix, Inc.


Revision tags: release/14.2.0-p2, release/14.1.0-p8, release/13.4.0-p4
# 5dc99e9b 06-Feb-2025 Mark Johnston <markj@FreeBSD.org>

tcp: Add a sysctl to modify listening socket FIB inheritance

Introduce the net.inet.tcp.bind_all_fibs tunable, set to 1 by default
for compatibility with current behaviour. When set to 0, all TCP
l

tcp: Add a sysctl to modify listening socket FIB inheritance

Introduce the net.inet.tcp.bind_all_fibs tunable, set to 1 by default
for compatibility with current behaviour. When set to 0, all TCP
listening sockets are private to their FIB. Inbound connection requests
will only succeed if a matching inpcb is bound to the same FIB as the
request.

No functional change intended, as the new behaviour is not enabled by
default.

Reviewed by: glebius
MFC after: 2 weeks
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D48663

show more ...


Revision tags: release/14.1.0-p7, release/14.2.0-p1, release/13.4.0-p3, release/14.2.0
# b80c06cc 21-Nov-2024 Gleb Smirnoff <glebius@FreeBSD.org>

tcp: use const argument in the TCP hostcache KPI

The hostcache can't modify tcpcb, inpcb or connection info.


# 09000cc1 21-Nov-2024 Gleb Smirnoff <glebius@FreeBSD.org>

tcp: mechanically rename hostcache metrics structure fields

Use hc_ prefix instead of rmx_. The latter stands for "route metrix" and
is an artifact from the 90-ies, when TCP caching was embedded in

tcp: mechanically rename hostcache metrics structure fields

Use hc_ prefix instead of rmx_. The latter stands for "route metrix" and
is an artifact from the 90-ies, when TCP caching was embedded into the
routing table. The rename should have happened back in 97d8d152c28bb.

No functional change. Done with sed(1) command:

s/rmx_(mtu|ssthresh|rtt|rttvar|cwnd|sendpipe|recvpipe|granularity|expire|q|hits|updates)/hc_\1/g

show more ...


# 994a82a0 18-Oct-2024 Gleb Smirnoff <glebius@FreeBSD.org>

tcp: garbage collect unused macros

Fixes: d40c0d47cd2a8100b8b9719bea092dde0512937a


# 440f4ba1 10-Oct-2024 Richard Scheffenegger <rscheff@FreeBSD.org>

tcp: fix duplicate retransmissions when RTO happens during SACK loss recovery

When snd_nxt doesn't track snd_max, partial SACK ACKs may elicit
unexpected duplicate retransmissions. This is usually m

tcp: fix duplicate retransmissions when RTO happens during SACK loss recovery

When snd_nxt doesn't track snd_max, partial SACK ACKs may elicit
unexpected duplicate retransmissions. This is usually masked by
LRO not necessarily ACKing every individual segment, and prior
to RFC6675 SACK loss recovery, harder to trigger even when an
RTO happens while SACK loss recovery is ongoing.

Address this by improving the logic when to start a SACK loss recovery
and how to deal with a RTO, as well as improvements to the adjusted
congestion window during transmission selection.

Reviewed By: tuexen, cc, #transport
Sponsored by: NetApp, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D43355

show more ...


Revision tags: release/13.4.0
# 52eacec9 03-Aug-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: fix t_flags2 collision

Fix the collision of TF2_IPSEC_TSO and TF2_NO_ISS_CHECK

Fixes: 646c28ea80cb ("tcp: improve SEG.ACK validation")
MFC after: 1 week
Sponsored by: Netflix, Inc.


# 4036380e 28-Jul-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: vnetify sysctl variables ack_war_timewindow and ack_war_cnt

As suggested by glebius@. While there, improve the documentation.

Reviewed by: Peter Lei, cc
MFC after: 1 week
Sponsored by: Netf

tcp: vnetify sysctl variables ack_war_timewindow and ack_war_cnt

As suggested by glebius@. While there, improve the documentation.

Reviewed by: Peter Lei, cc
MFC after: 1 week
Sponsored by: Netflix, Inc
Differential Revision: https://reviews.freebsd.org/D46140

show more ...


# 40299c55 25-Jul-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: implement challenge ACK throttling for the base stack

Implement ACK throttling of challenge ACKs as described in RFC 5961.

Reviewed by: Peter Lei, rscheff, cc
MFC after: 1 week
Sponsored by:

tcp: implement challenge ACK throttling for the base stack

Implement ACK throttling of challenge ACKs as described in RFC 5961.

Reviewed by: Peter Lei, rscheff, cc
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D46066

show more ...


# 7f2411b1 22-Jul-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: improve whitespace consistency

No functional change.

Sponsored by: Netflix, Inc.


# 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 ...


# baee801c 21-Jul-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: simplify endpoint creation at the passive side

Use the intended TCP stack when creating a TCP endpoint instead of
creating it the endpoint the default stack first and after that
switching it to

tcp: simplify endpoint creation at the passive side

Use the intended TCP stack when creating a TCP endpoint instead of
creating it the endpoint the default stack first and after that
switching it to use the intended TCP stack.
Reviewed by: Peter Lei, rrs and jtl (older version)
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D45411

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 ...


# 859f0f0d 13-Jul-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: refactor register_tcp_functions_as_names()

Refactor register_tcp_functions_as_names() such that either all or
no (in error cases) registrations happen atomically (while holding
the tcp_function

tcp: refactor register_tcp_functions_as_names()

Refactor register_tcp_functions_as_names() such that either all or
no (in error cases) registrations happen atomically (while holding
the tcp_function_lock write lock). Also ensure that the TCP function
block is not already registered.
This avoids situations, where some registrations were performed and
then they were removed without holding a lock in between or checking
ref counts.

Reviewed by: cc
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D45947

show more ...


Revision tags: release/14.1.0, release/13.3.0
# b6919741 14-Nov-2023 Konstantin Belousov <kib@FreeBSD.org>

ipsec_offload: handle TSO if supported

Allow for TSO to operate if network interface supports ipsec inline
offload and supports TSO over it.

Reviewed by: tuexen
Sponsored by: NVIDIA networking
Diff

ipsec_offload: handle TSO if supported

Allow for TSO to operate if network interface supports ipsec inline
offload and supports TSO over it.

Reviewed by: tuexen
Sponsored by: NVIDIA networking
Differential revision: https://reviews.freebsd.org/D44222

show more ...


# 86c9325d 06-Jun-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: simplify stack switching protocol

Before this patch, a stack (tfb) accepts a tcpcb (tp), if the
tp->t_state is TCPS_CLOSED or tfb->tfb_tcp_handoff_ok is not NULL
and tfb->tfb_tcp_handoff_ok(tp)

tcp: simplify stack switching protocol

Before this patch, a stack (tfb) accepts a tcpcb (tp), if the
tp->t_state is TCPS_CLOSED or tfb->tfb_tcp_handoff_ok is not NULL
and tfb->tfb_tcp_handoff_ok(tp) returns 0.
After this patch, the only check is tfb->tfb_tcp_handoff_ok(tp)
returns 0. tfb->tfb_tcp_handoff_ok must always be provided.
For existing TCP stacks (FreeBSD, RACK and BBR) there is no
functional change. However, the logic is simpler.

Reviewed by: lstewart, peter_lei_ieee_.org, rrs
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D45253

show more ...


# ea916b64 18-May-2024 Randall Stewart <rrs@FreeBSD.org>

Remove TCP_SAD optional code now that the sack filter performs this function.

With the commit of D44903 we no longer need the SAD option. Instead all stacks that
use the sack filter inherit its prot

Remove TCP_SAD optional code now that the sack filter performs this function.

With the commit of D44903 we no longer need the SAD option. Instead all stacks that
use the sack filter inherit its protection against sack-attack.

Reviewed by: tuexen@
Differential Revision:https://reviews.freebsd.org/D45216

show more ...


# 2a9aae9e 08-May-2024 Richard Scheffenegger <rscheff@FreeBSD.org>

tcp: add counter to track when SACK loss recovery uses TSO

Add a counter to track how frequently SACK has transmitted
more than one MSS using TSO. Instances when this will be
beneficial is the use o

tcp: add counter to track when SACK loss recovery uses TSO

Add a counter to track how frequently SACK has transmitted
more than one MSS using TSO. Instances when this will be
beneficial is the use of PRR, or when ACK thinning due to
GRO/LRO or ACK discards by the network are present.

Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D45070

show more ...


# dcdfe449 08-May-2024 Richard Scheffenegger <rscheff@FreeBSD.org>

tcp: add sysctl to allow/disallow TSO during SACK loss recovery

Introduce net.inet.tcp.sack.tso for future use when TSO is ready
to be used during loss recovery.

Reviewed By: tuexen, #transport
Sp

tcp: add sysctl to allow/disallow TSO during SACK loss recovery

Introduce net.inet.tcp.sack.tso for future use when TSO is ready
to be used during loss recovery.

Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D45068

show more ...


# 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 ...


# 1d14e88e 08-Apr-2024 Mark Johnston <markj@FreeBSD.org>

tcp: Make tcp_var.h more self-contained

struct tcpcb embeds a struct osd and a struct callout. Rather than
forcing all consumers to pull in the same headers, include the headers
directly.

No funct

tcp: Make tcp_var.h more self-contained

struct tcpcb embeds a struct osd and a struct callout. Rather than
forcing all consumers to pull in the same headers, include the headers
directly.

No functional change intended.

Reviewed by: glebius
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44685

show more ...


# 60d8dbbe 18-Jan-2024 Kristof Provost <kp@FreeBSD.org>

netinet: add a probe point for IP, IP6, ICMP, ICMP6, UDP and TCP stats counters

When debugging network issues one common clue is an unexpectedly
incrementing error counter. This is helpful, in that

netinet: add a probe point for IP, IP6, ICMP, ICMP6, UDP and TCP stats counters

When debugging network issues one common clue is an unexpectedly
incrementing error counter. This is helpful, in that it gives us an
idea of what might be going wrong, but often these counters may be
incremented in different functions.

Add a static probe point for them so that we can use dtrace to get
futher information (e.g. a stack trace).

For example:
dtrace -n 'mib:ip:count: { printf("%d", arg0); stack(); }'

This can be disabled by setting the following kernel option:
options KDTRACE_NO_MIB_SDT

Reviewed by: gallatin, tuexen (previous version), gnn (previous version)
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43504

show more ...


# 5a268d86 03-Apr-2024 Michael Tuexen <tuexen@FreeBSD.org>

tcp: fix comment

Make the comment consistent with the code.

Reviewed by: rscheff
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D44611


# 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 ...


# 220ee18f 13-Mar-2024 Konstantin Belousov <kib@FreeBSD.org>

netinet/tcp_var.h: always define IS_FASTOPEN() for kernel compilation env

and drop the definition for userspace (which matched TCP_RFC7413) since
it depends on presence of the kernel option.

Review

netinet/tcp_var.h: always define IS_FASTOPEN() for kernel compilation env

and drop the definition for userspace (which matched TCP_RFC7413) since
it depends on presence of the kernel option.

Reviewed by: glebius, rscheff
Sponsored by: NVIDIA networking
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D44349

show more ...


12345678910>>...31