Similar to the previous commit, not setting either the 'signal' or
'subflow' flag is usually a mistake from the user. This would bring
unexpected behaviours as mentioned in some bug reports on the MPTCP
project.

It is then important to guide the users by printing a warning on stderr.
Users can ignore this message if they have an atypical environment where
it is required to reserve an ID for some obscure reasons.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
---
 ip/ipmptcp.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/ip/ipmptcp.c b/ip/ipmptcp.c
index 0f09cf75..d40a50d5 100644
--- a/ip/ipmptcp.c
+++ b/ip/ipmptcp.c
@@ -188,6 +188,15 @@ static int mptcp_parse_opt(int argc, char **argv, struct nlmsghdr *n, int cmd)
 		    "         for the client side. It is not typical to both initiate, and accept\n"
 		    "         new connections with the same peer. Continuing as requested.\n");
 
+	if (adding && !(flags & (MPTCP_PM_ADDR_FLAG_SIGNAL |
+	                         MPTCP_PM_ADDR_FLAG_SUBFLOW)))
+		fprintf(stderr,
+		    "Warning: Not setting either the 'signal' or 'subflow' flag is usually a mistake:\n"
+		    "         'signal' is used to announce additional addresses, typically for the\n"
+		    "         server side, while 'subflow' is used to create new paths, typically\n"
+		    "         for the client side. Not setting either of these flags will reserve\n"
+		    "         the endpoint ID, but that's it. Continuing as requested.\n");
+
 	if (setting && id_set && port)
 		invarg("port can't be used with id", "port");
 

-- 
2.43.0