From: Kishen Maloor <kishen.maloor@intel.com>
To: Paolo Abeni <pabeni@redhat.com>,
Matthieu Baerts <matthieu.baerts@tessares.net>,
<mptcp@lists.linux.dev>
Subject: Re: [PATCH mptcp-next 07/21] mptcp: netlink: process IPv6 addrs in creating listening sockets
Date: Wed, 22 Dec 2021 12:27:55 -0800 [thread overview]
Message-ID: <ec2f7644-0f41-705e-e111-992cdf7fb9b5@intel.com> (raw)
In-Reply-To: <0c44a4f2371ca515edce8ba67f60778f9c990cb9.camel@redhat.com>
On 12/21/21 1:45 AM, Paolo Abeni wrote:
> On Mon, 2021-12-20 at 23:32 -0800, Kishen Maloor wrote:
>> On 12/17/21 8:29 AM, Matthieu Baerts wrote:
>>> Hi Kishen,
>>>
>>> On 16/12/2021 23:23, Kishen Maloor wrote:
>>>> This change updates mptcp_pm_nl_create_listen_socket() to create
>>>> listening sockets bound to IPv6 addresses (where IPv6 is supported).
>>>
>>> Should we consider this as a bug?
>>
>> We could I suppose, at least for lack of completeness. But you're right that we've
>> now updated the behavior in this series in attempting to create listening sockets (lsks)
>> corresponding to every announcement, which necessitates this handling of
>> IPv6 addresses.
>>
>> But prior to this series:
>> -lsk creation (through a subflow's port) did not happen in the kernel under the assumption
>> that MPTCP server applications would've established a listener,
>> -lsks were created only for port-based endpoints which (I believe) would not work with
>> IPv6 (lack of option space), and,
>> -the stack did not allow incoming MP_JOINs at machines running MPTCP client
>> applications (with this series, subflows can be established from either end so there
>> needs to be an lsk).
>
> Could you please elaborate more this last point? If the stack does not
> allow the latter, it's definitely a bug. The port-based endpoint
> implementation was aimed [also] at that goal.
>
Prior to changes here:
https://lore.kernel.org/mptcp/4cb68f04-5732-e1fe-4b3b-82a418d87f00@intel.com/T/#m637d52ce80f1ff21b20e9de9b877c016fdb4729d
I believe that MPJs received at endpoints running MPTCP client applications would fail to establish a subflow due to logic in mptcp_finish_join().
> Thanks!
>
> Paolo
>
next prev parent reply other threads:[~2021-12-22 20:28 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-16 22:22 [PATCH mptcp-next 00/21] mptcp: support userspace path management Kishen Maloor
2021-12-16 22:22 ` [PATCH mptcp-next 01/21] mptcp: do not restrict subflows with non-kernel PMs Kishen Maloor
2021-12-16 22:22 ` [PATCH mptcp-next 02/21] mptcp: store remote id from MP_JOIN SYN/ACK in local ctx Kishen Maloor
2021-12-16 22:22 ` [PATCH mptcp-next 03/21] mptcp: reflect remote port (not 0) in ANNOUNCED events Kishen Maloor
2021-12-16 22:22 ` [PATCH mptcp-next 04/21] mptcp: establish subflows from either end of connection Kishen Maloor
2021-12-17 17:41 ` Paolo Abeni
2021-12-21 7:35 ` Kishen Maloor
2021-12-16 22:22 ` [PATCH mptcp-next 05/21] mptcp: netlink: store per namespace list of refcounted listen socks Kishen Maloor
2021-12-17 16:24 ` Matthieu Baerts
2021-12-16 22:22 ` [PATCH mptcp-next 06/21] mptcp: netlink: store lsk ref in mptcp_pm_addr_entry Kishen Maloor
2021-12-17 16:25 ` Matthieu Baerts
2021-12-21 7:29 ` Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 07/21] mptcp: netlink: process IPv6 addrs in creating listening sockets Kishen Maloor
2021-12-17 16:29 ` Matthieu Baerts
2021-12-21 7:32 ` Kishen Maloor
2021-12-21 9:45 ` Paolo Abeni
2021-12-22 20:27 ` Kishen Maloor [this message]
2021-12-29 13:52 ` Matthieu Baerts
2022-01-05 3:35 ` Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 08/21] mptcp: attempt to add listening sockets for announced addrs Kishen Maloor
2021-12-17 16:34 ` Matthieu Baerts
2021-12-21 7:34 ` Kishen Maloor
2021-12-29 14:03 ` Matthieu Baerts
2022-01-05 3:37 ` Kishen Maloor
2021-12-17 18:04 ` Paolo Abeni
2021-12-18 1:17 ` Mat Martineau
2021-12-21 7:44 ` Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 09/21] mptcp: allow ADD_ADDR reissuance by userspace PMs Kishen Maloor
2021-12-17 18:38 ` Paolo Abeni
2021-12-21 7:33 ` Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 10/21] mptcp: handle local addrs announced " Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 11/21] mptcp: read attributes of addr entries managed " Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 12/21] mptcp: netlink: split mptcp_pm_parse_addr into two functions Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 13/21] mptcp: netlink: Add MPTCP_PM_CMD_ANNOUNCE Kishen Maloor
2021-12-17 18:39 ` Paolo Abeni
2021-12-16 22:23 ` [PATCH mptcp-next 14/21] mptcp: selftests: support MPTCP_PM_CMD_ANNOUNCE Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 15/21] mptcp: netlink: Add MPTCP_PM_CMD_REMOVE Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 16/21] mptcp: selftests: support MPTCP_PM_CMD_REMOVE Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 17/21] mptcp: netlink: allow userspace-driven subflow establishment Kishen Maloor
2021-12-17 2:52 ` kernel test robot
2021-12-17 2:52 ` kernel test robot
2021-12-17 5:46 ` kernel test robot
2021-12-17 5:46 ` kernel test robot
2021-12-16 22:23 ` [PATCH mptcp-next 18/21] mptcp: selftests: support MPTCP_PM_CMD_SUBFLOW_CREATE Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 19/21] mptcp: selftests: support MPTCP_PM_CMD_SUBFLOW_DESTROY Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 20/21] mptcp: selftests: capture netlink events Kishen Maloor
2021-12-16 22:23 ` [PATCH mptcp-next 21/21] selftests: mptcp: functional tests for the userspace PM type Kishen Maloor
2021-12-16 22:44 ` selftests: mptcp: functional tests for the userspace PM type: Build Failure MPTCP CI
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ec2f7644-0f41-705e-e111-992cdf7fb9b5@intel.com \
--to=kishen.maloor@intel.com \
--cc=matthieu.baerts@tessares.net \
--cc=mptcp@lists.linux.dev \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.