1. 24 May, 2017 2 commits
    • Fabrice Bellet's avatar
      stun timer: move back to 5 retransmissions · 14362bdd
      Fabrice Bellet authored
      With the pacing behaviour of the ICE RFC 5245, the stun packets are
      send with an initial timeout that cannot be lower that 100ms, and that
      increases of 20ms for each new in-progress/waiting conncheck above 5.
      Typical initial timeout is in the range 100ms - 400ms (obtained when
      there are 20 in-progress/waiting connchecks).
      The rationale with this modification is that we consider that 4
      retransmissions with an initial timeout of 100ms and a last timeout of 4
      * 100 ms, gives (1 + 2 + 4 + 8 + 4) * 100ms = 1900ms for a response to
      be received after the initial stun request has been sent, which is
      probably enough in most situations. With an initial timeout of 400ms,
      this delay extends to 7600ms (this is proportional to the value of the
      initial timeout).
      Differential Revision: https://phabricator.freedesktop.org/D1109
    • Fabrice Bellet's avatar
      interfaces: ignore predefined network interfaces · 4f5b991e
      Fabrice Bellet authored
      Some interfaces, like the one managed by libvirtd to provide a network
      bridge to locally hosted virtual machines, can be completely ignored
      when gathering ICE candidates. The motivation for adding this
      possibility is that, ignoring them doesn't remove capabilities, and
      improves the overall speed of the connection check method, by reducing
      the number of pairs to be tested. This patch adds the possibility to
      define such interfaces in the configuration script.
      Differential Revision: https://phabricator.freedesktop.org/D948
  2. 01 May, 2017 1 commit
  3. 12 Apr, 2017 2 commits
    • Fabrice Bellet's avatar
      agent: do not create a GSource for UDP TURN socket · 0a2cb0a9
      Fabrice Bellet authored
      With this patch, we don't create a new GSource for udp-turn socket,
      because it would duplicate the packets already received on the base UDP
      socket, as the underlying GSocket is the same. This is a race condition,
      because an UDP packet arriving on the base socket, may randomly be
      handled by the GSource callback created for the base socket (udp-bsd) of
      the callback created for the udp-turn socket. Moreover this callback
      already knows how to parse UDP datagrams received from a known turn
      This patch also prevents a subtle bug, when a STUN request is received
      directly from a peer, is handled by the udp turn socket. If the agent
      already has a valid permission for this remote candidate, established
      for another pair, it will happily send the STUN reply through the turn
      relay. This generates a source address mismatch on the peer agent, when
      it'll receive the STUN response from the turn relay instead of the
      initial address the request has been sent to.
      Differential Revision: https://phabricator.freedesktop.org/D932
    • Fabrice Bellet's avatar
      stun timer: fix timeout of the last retransmission · f6f704c5
      Fabrice Bellet authored
      According to RFC 5389, section 7.2.1, a special timeout is applied to
      the last retransmission (Rm * RTO), with Rm default value of 16, instead
      of (64 * RTO), 2^6 when the number of transmissions Rc is set to 7.
      As spotted by Olivier Crete, stun_timer_* is a public API, that cannot
      be changed, and the initial delay (RTO) is not preserved in the
      stun_timer_s struct. So we use a hack that implicitely guess Rm from the
      number of transmissions Rc, by generalizing the default value of the
      spec for Rm and Rc to other values of Rc passed in stun_timer_start(
      According to the spec, with the default value of Rc=7, the last delay
      should be (64 * RTO), and it is instead (16 * RTO). So the last delay
      can be computed by dividing the penultimate delay by two, instead of
      multiplying it by two.
      Differential Revision: https://phabricator.freedesktop.org/D1108
  4. 11 Apr, 2017 5 commits
  5. 05 Apr, 2017 3 commits
  6. 04 Apr, 2017 7 commits
  7. 03 Apr, 2017 15 commits
  8. 01 Apr, 2017 2 commits
  9. 31 Mar, 2017 3 commits