1. 25 9月, 2021 2 次提交
  2. 27 8月, 2021 4 次提交
  3. 25 8月, 2021 4 次提交
  4. 24 8月, 2021 1 次提交
  5. 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
  6. 14 8月, 2021 1 次提交
  7. 10 7月, 2021 1 次提交
  8. 23 6月, 2021 2 次提交
  9. 22 6月, 2021 1 次提交
  10. 19 6月, 2021 7 次提交
  11. 11 6月, 2021 1 次提交
  12. 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
  13. 17 4月, 2021 1 次提交
  14. 08 4月, 2021 6 次提交
  15. 03 4月, 2021 2 次提交
  16. 27 3月, 2021 2 次提交
  17. 16 3月, 2021 1 次提交
  18. 13 3月, 2021 1 次提交