]> git.ipfire.org Git - thirdparty/iproute2.git/commitdiff
man: mptcp: clarify 'signal' and 'subflow' flags
authorMatthieu Baerts (NGI0) <matttbe@kernel.org>
Sat, 27 Jul 2024 10:10:31 +0000 (12:10 +0200)
committerStephen Hemminger <stephen@networkplumber.org>
Fri, 2 Aug 2024 17:47:39 +0000 (10:47 -0700)
According to some bug reports on the MPTCP project, these options might
be a bit confusing for some.

Mentioning that the 'signal' flag is typically for a server, and the
'subflow' one is typically for a client should help the user knowing in
which context which flag should be picked.

Acked-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
man/man8/ip-mptcp.8

index 89fcb64ff5a58d60f95c79d4d87632461030a822..2b693564fe2c33fb340e31d3a7ecc9e865a8fa48 100644 (file)
@@ -150,7 +150,8 @@ is a unique numeric identifier for the given endpoint
 .TP
 .BR signal
 The endpoint will be announced/signaled to each peer via an MPTCP ADD_ADDR
-sub-option. Upon reception of an ADD_ADDR sub-option, the peer can try to
+sub-option. Typically, a server would be responsible for this. Upon reception of
+an ADD_ADDR sub-option, the other peer, typically the client side, can try to
 create additional subflows, see
 .BR ADD_ADDR_ACCEPTED_NR.
 
@@ -158,7 +159,8 @@ create additional subflows, see
 .BR subflow
 If additional subflow creation is allowed by the MPTCP limits, the MPTCP
 path manager will try to create an additional subflow using this endpoint
-as the source address after the MPTCP connection is established.
+as the source address after the MPTCP connection is established. A client would
+typically do this.
 
 .TP
 .BR backup