1. 27 8月, 2021 1 次提交
  2. 25 8月, 2021 4 次提交
  3. 24 8月, 2021 1 次提交
  4. 19 8月, 2021 1 次提交
    • M
      mptcp: full fully established support after ADD_ADDR · 67b12f79
      Matthieu Baerts 提交于
      If directly after an MP_CAPABLE 3WHS, the client receives an ADD_ADDR
      with HMAC from the server, it is enough to switch to a "fully
      established" mode because it has received more MPTCP options.
      
      It was then OK to enable the "fully_established" flag on the MPTCP
      socket. Still, best to check if the ADD_ADDR looks valid by looking if
      it contains an HMAC (no 'echo' bit). If an ADD_ADDR echo is received
      while we are not in "fully established" mode, it is strange and then
      we should not switch to this mode now.
      
      But that is not enough. On one hand, the path-manager has be notified
      the state has changed. On the other hand, the "fully_established" flag
      on the subflow socket should be turned on as well not to re-send the
      MP_CAPABLE 3rd ACK content with the next ACK.
      
      Fixes: 84dfe367 ("mptcp: send out dedicated ADD_ADDR packet")
      Signed-off-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67b12f79
  5. 14 8月, 2021 1 次提交
  6. 10 7月, 2021 1 次提交
  7. 23 6月, 2021 2 次提交
  8. 22 6月, 2021 1 次提交
  9. 19 6月, 2021 7 次提交
  10. 11 6月, 2021 1 次提交
  11. 26 5月, 2021 2 次提交
    • D
      mptcp: validate 'id' when stopping the ADD_ADDR retransmit timer · d58300c3
      Davide Caratti 提交于
      when Linux receives an echo-ed ADD_ADDR, it checks the IP address against
      the list of "announced" addresses. In case of a positive match, the timer
      that handles retransmissions is stopped regardless of the 'Address Id' in
      the received packet: this behaviour does not comply with RFC8684 3.4.1.
      
      Fix it by validating the 'Address Id' in received echo-ed ADD_ADDRs.
      Tested using packetdrill, with the following captured output:
      
       unpatched kernel:
      
       Out <...> Flags [.], ack 1, win 256, options [mptcp add-addr v1 id 1 198.51.100.2 hmac 0xfd2e62517888fe29,mptcp dss ack 3007449509], length 0
       In  <...> Flags [.], ack 1, win 257, options [mptcp add-addr v1-echo id 1 1.2.3.4,mptcp dss ack 3013740213], length 0
       Out <...> Flags [.], ack 1, win 256, options [mptcp add-addr v1 id 1 198.51.100.2 hmac 0xfd2e62517888fe29,mptcp dss ack 3007449509], length 0
       In  <...> Flags [.], ack 1, win 257, options [mptcp add-addr v1-echo id 90 198.51.100.2,mptcp dss ack 3013740213], length 0
              ^^^ retransmission is stopped here, but 'Address Id' is 90
      
       patched kernel:
      
       Out <...> Flags [.], ack 1, win 256, options [mptcp add-addr v1 id 1 198.51.100.2 hmac 0x1cf372d59e05f4b8,mptcp dss ack 3007449509], length 0
       In  <...> Flags [.], ack 1, win 257, options [mptcp add-addr v1-echo id 1 1.2.3.4,mptcp dss ack 1672384568], length 0
       Out <...> Flags [.], ack 1, win 256, options [mptcp add-addr v1 id 1 198.51.100.2 hmac 0x1cf372d59e05f4b8,mptcp dss ack 3007449509], length 0
       In  <...> Flags [.], ack 1, win 257, options [mptcp add-addr v1-echo id 90 198.51.100.2,mptcp dss ack 1672384568], length 0
       Out <...> Flags [.], ack 1, win 256, options [mptcp add-addr v1 id 1 198.51.100.2 hmac 0x1cf372d59e05f4b8,mptcp dss ack 3007449509], length 0
       In  <...> Flags [.], ack 1, win 257, options [mptcp add-addr v1-echo id 1 198.51.100.2,mptcp dss ack 1672384568], length 0
              ^^^ retransmission is stopped here, only when both 'Address Id' and 'IP Address' match
      
      Fixes: 00cfd77b ("mptcp: retransmit ADD_ADDR when timeout")
      Signed-off-by: NDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d58300c3
    • P
      mptcp: drop unconditional pr_warn on bad opt · 3812ce89
      Paolo Abeni 提交于
      This is a left-over of early day. A malicious peer can flood
      the kernel logs with useless messages, just drop it.
      
      Fixes: f296234c ("mptcp: Add handling of incoming MP_JOIN requests")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3812ce89
  12. 17 4月, 2021 1 次提交
  13. 08 4月, 2021 6 次提交
  14. 03 4月, 2021 2 次提交
  15. 27 3月, 2021 2 次提交
  16. 16 3月, 2021 1 次提交
  17. 13 3月, 2021 2 次提交
    • G
      mptcp: add rm_list in mptcp_options_received · 5c4a824d
      Geliang Tang 提交于
      This patch changed the member rm_id in struct mptcp_options_received as a
      list of the removing address ids, and renamed it to rm_list.
      
      In mptcp_parse_option, parsed the RM_ADDR suboption and filled them into
      the rm_list in struct mptcp_options_received.
      
      In mptcp_incoming_options, passed this rm_list to the function
      mptcp_pm_rm_addr_received.
      
      It also changed the parameter type of mptcp_pm_rm_addr_received.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c4a824d
    • G
      mptcp: add rm_list in mptcp_out_options · 6445e17a
      Geliang Tang 提交于
      This patch defined a new struct mptcp_rm_list, the ids field was an
      array of the removing address ids, the nr field was the valid number of
      removing address ids in the array. The array size was definced as a new
      macro MPTCP_RM_IDS_MAX. Changed the member rm_id of struct
      mptcp_out_options to rm_list.
      
      In mptcp_established_options_rm_addr, invoked mptcp_pm_rm_addr_signal to
      get the rm_list. According the number of addresses in it, calculated
      the padded RM_ADDR suboption length. And saved the ids array in struct
      mptcp_out_options's rm_list member.
      
      In mptcp_write_options, iterated each address id from struct
      mptcp_out_options's rm_list member, set the invalid ones as TCPOPT_NOP,
      then filled them into the RM_ADDR suboption.
      
      Changed TCPOLEN_MPTCP_RM_ADDR_BASE from 4 to 3.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      Signed-off-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6445e17a
  18. 23 2月, 2021 1 次提交
    • P
      mptcp: fix DATA_FIN generation on early shutdown · d87903b6
      Paolo Abeni 提交于
      If the msk is closed before sending or receiving any data,
      no DATA_FIN is generated, instead an MPC ack packet is
      crafted out.
      
      In the above scenario, the MPTCP protocol creates and sends a
      pure ack and such packets matches also the criteria for an
      MPC ack and the protocol tries first to insert MPC options,
      leading to the described error.
      
      This change addresses the issue by avoiding the insertion of an
      MPC option for DATA_FIN packets or if the sub-flow is not
      established.
      
      To avoid doing multiple times the same test, fetch the data_fin
      flag in a bool variable and pass it to both the interested
      helpers.
      
      Fixes: 6d0060f6 ("mptcp: Write MPTCP DSS headers to outgoing data packets")
      Reviewed-by: NMat Martineau <mathew.j.martineau@linux.intel.com>
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      d87903b6
  19. 13 2月, 2021 1 次提交
  20. 12 2月, 2021 2 次提交