Primary flow re-establishes as a subflow but immediately closes #512
Assignees
Labels
Comments
|
Hi @arinc9, Thank you for the bug report What are the limits on both sides? (It looks like it is 5 on the client side, but what about the server side?) It is a bit confusing, but the limits are for the "additional subflows". It means that if you have 2 additional subflows, and you remove and re-add the endpoint used by the initial subflow, the new created subflow will be counting as an additional one. So in this case, if the subflow limits are set to 2, that's fine, until you recreate the endpoint used by the initial subflow: there you need the limit to be at least 3. |
|
Also, do you have the same issue if you force re-using the same ID? (what should be done in theory, to re-use the 'local ID 0'): |
|
@arinc9: please also include |
|
@arinc9: I found another issue when removing the ID0 where the |
|
@arinc9: there were some issues in my previous patch. This should be applied on top: I'm still investigating stuff, proper patches will come later on |
|
@matttbe these two diffs resolved the issue, thank you so much! Let me know if you want further testing. |
|
Great, thank you for having tested! I need to cleanup that and send proper patches. Once it is done, it would be great if you could validate the new series :) |
|
Sure, I'll leave my tested-by. CC me! |
|
@arinc9 sorry, I forgot to CC you, but the new series has been sent on our ML: https://lore.kernel.org/all/[email protected]/T/#u Feel free to send your Tested-By tag(s) |
|
@matttbe sorry, I'm a bit late. Both hosts run export/20240809T121429 with this series applied. When adding the endpoint manually a second time, a subflow won't be established using the endpoint. Same behaviour if I add the subflow without an ID, remove it, then add it without an ID again. We did not have this behaviour with your custom patch. |
|
@arinc9 : thank you for having tested! Indeed, the 're-re-creation' of the ID 0 endpoint was not working. I think it was a regression from my previous version. Please note that in the 'ip mptcp monitor' output, we can see that the SF_CLOSED event is wrongly generated twice. Sometimes with no source address and destination port. All of that should be fixed with this new series: https://lore.kernel.org/mptcp/[email protected]/T/ Do you mind checking that please? |
MPTCPimporter
pushed a commit
that referenced
this issue
Aug 15, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: #512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Message-Id: <[email protected]>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Aug 16, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
arinc9
pushed a commit
to arinc9/linux
that referenced
this issue
Aug 16, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
|
@matttbe thank you. Re-re-creation works now. However, deleting the endpoint for the third time results in a warning. Other than that, a subflow using the endpoint will be created every time so my issue is resolved. Let me know when should I close this issue. |
Thanks! I managed to reproduce it as well. Should be fixed in the v2. |
MPTCPimporter
pushed a commit
that referenced
this issue
Aug 16, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: #512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Message-Id: <[email protected]>
arinc9
pushed a commit
to arinc9/linux
that referenced
this issue
Aug 16, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
|
Perfect. I don't encounter any issues whatsoever with establishing flows anymore. Thank you very much! You can close the issue if it's time. |
|
Thank you for having tested! (sorry, I forgot to report your Tested-by).
It will be automatically closed when the patches will be applied. |
arinc9
pushed a commit
to arinc9/linux
that referenced
this issue
Aug 21, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
matttbe
added a commit
that referenced
this issue
Aug 24, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: #512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
matttbe
added a commit
that referenced
this issue
Aug 24, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: #512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
matttbe
added a commit
that referenced
this issue
Aug 24, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: #512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
matttbe
added a commit
that referenced
this issue
Aug 24, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: #512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Aug 28, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Aug 29, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Aug 29, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Aug 29, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: NipaLocal <nipa@local>
kuba-moo
pushed a commit
to linux-netdev/testing
that referenced
this issue
Aug 29, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Aug 31, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Aug 31, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Sep 1, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Sep 1, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
mj22226
pushed a commit
to mj22226/linux
that referenced
this issue
Sep 1, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Sep 2, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Sep 2, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Sep 2, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Sep 2, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Sep 2, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
flukejones
pushed a commit
to flukejones/linux
that referenced
this issue
Sep 3, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
zhuyj
pushed a commit
to zhuyj/linux
that referenced
this issue
Sep 3, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Sep 4, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
johnny-mnemonic
pushed a commit
to linux-ia64/linux-stable-rc
that referenced
this issue
Sep 4, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
gregkh
pushed a commit
to gregkh/linux
that referenced
this issue
Sep 4, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
gregkh
pushed a commit
to gregkh/linux
that referenced
this issue
Sep 4, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
opsiff
pushed a commit
to opsiff/UOS-kernel
that referenced
this issue
Sep 4, 2024
commit 9366922adc6a71378ca01f898c41be295309f044 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 53e2173172d26c0617b29dd83618b71664bed1fb)
Avenger-285714
pushed a commit
to deepin-community/kernel
that referenced
this issue
Sep 5, 2024
commit 9366922adc6a71378ca01f898c41be295309f044 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> (cherry picked from commit 53e2173172d26c0617b29dd83618b71664bed1fb)
mj22226
pushed a commit
to mj22226/linux
that referenced
this issue
Sep 5, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Whissi
pushed a commit
to Whissi/linux-stable
that referenced
this issue
Sep 8, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
morimoto
pushed a commit
to morimoto/linux
that referenced
this issue
Sep 9, 2024
commit 9366922 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Mr-Bossman
pushed a commit
to Mr-Bossman/linux
that referenced
this issue
Sep 16, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
rene
pushed a commit
to rene/eve-kernel
that referenced
this issue
Oct 15, 2024
commit 9366922adc6a71378ca01f898c41be295309f044 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
wanghao75
pushed a commit
to openeuler-mirror/kernel
that referenced
this issue
Oct 21, 2024
stable inclusion from stable-v6.6.49 commit 53e2173172d26c0617b29dd83618b71664bed1fb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAX3M8 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=53e2173172d26c0617b29dd83618b71664bed1fb -------------------------------- commit 9366922adc6a71378ca01f898c41be295309f044 upstream. 'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Wen Zhiwei <[email protected]>
yhamamachi
pushed a commit
to yhamamachi/linux-pcie-virtio-net
that referenced
this issue
Oct 23, 2024
'local_addr_used' and 'add_addr_accepted' are decremented for addresses not related to the initial subflow (ID0), because the source and destination addresses of the initial subflows are known from the beginning: they don't count as "additional local address being used" or "ADD_ADDR being accepted". It is then required not to increment them when the entrypoint used by the initial subflow is removed and re-added during a connection. Without this modification, this entrypoint cannot be removed and re-added more than once. Reported-by: Arınç ÜNAL <[email protected]> Closes: multipath-tcp/mptcp_net-next#512 Fixes: 3ad14f5 ("mptcp: more accurate MPC endpoint tracking") Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Cc: [email protected] Tested-by: Arınç ÜNAL <[email protected]> Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Both hosts run the export/20240726T103611 tree with v5 of "mptcp: fix endpoints with 'signal' and 'subflow' flags" patch series applied.
Other paths won't be closed after being re-established. This is not an issue with the eth1 path; if it's not the primary flow, it won't be closed after being re-established.
The text was updated successfully, but these errors were encountered: