netdev - [PATCH iproute2-net 2/7] man: mptcp: clarify 'signal' and 'subflow' flags

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240727-upstream-iproute2-net-20240726-mptcp-man-user-feedback-v1-2-c6398c2014ea@kernel.org>
Date: Sat, 27 Jul 2024 12:10:31 +0200
From: "Matthieu Baerts (NGI0)" <matttbe@...nel.org>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: David Ahern <dsahern@...il.com>, netdev@...r.kernel.org, 
 MPTCP Upstream <mptcp@...ts.linux.dev>, 
 Mat Martineau <martineau@...nel.org>, Geliang Tang <geliang@...nel.org>, 
 "Matthieu Baerts (NGI0)" <matttbe@...nel.org>
Subject: [PATCH iproute2-net 2/7] man: mptcp: clarify 'signal' and
 'subflow' flags

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@...nel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@...nel.org>
---
 man/man8/ip-mptcp.8 | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/man/man8/ip-mptcp.8 b/man/man8/ip-mptcp.8
index 89fcb64f..2b693564 100644
--- a/man/man8/ip-mptcp.8
+++ b/man/man8/ip-mptcp.8
@@ -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

-- 
2.45.2