1. 21 Jun, 2017 13 commits
    • Fabrice Bellet's avatar
      conncheck: remove cancelled pair state · 95f8805e
      Fabrice Bellet authored
      Pairs with the state NICE_CHECK_CANCELLED are the pairs targeted for
      removal after the nomination of a pair with an higher priority,
      described in Section 8.1.2 "Updating States", item 2 of RFC 5245. They
      include also pairs that overflow the conncheck list size, but this is a
      somewhat more marginal situation. So we are mainly interested in the
      first use case of this state.
      
      This state mixes two different situations, that deserve a distinct
      handling : on one side, there are waiting or frozen pairs that must be
      removed, this is an immediate action that doesn't need a dedicated state
      for that. And on the other side, there are in-progress pairs that
      should no longer be retransmitted, because another pair with a higher
      priority has already been nominated.
      
      This patch removes the cancelled state, and adds a flag
      retransmit_on_timeout to deal with this last situation. Note that this
      case should not generate a triggered check, as per described in section
      7.2.1.4, when the state of the pair is In-Progress or Failed, since this
      pair of lower priority has no hope to replace the nominated one.
      
      Differential Revision: https://phabricator.freedesktop.org/D1114
      95f8805e
    • Fabrice Bellet's avatar
      conncheck: adjust recheck on timeout strategy · d516fca1
      Fabrice Bellet authored
      The pair recheck on timeout can easily cause repetitive rechecks in
      a ping-pong effect, if both peers with the same behaviour try to
      check the same pair almost simultaneously, and if the network rtt
      is greater than the initial timer rto. The reply to the initial
      stun request may arrive after the in-progress conncheck
      cancellation (described in RFC 5245, sect 7.2.1.4). Cancellation
      creates a new stun request, and forgets the initial one.
      The conncheck timer is restarted with the same initial value,
      so the same situation happens again later.
      
      We choose to avoid resetting the timer in such situation. After enough
      retransmissions, the timeout delay, that doubles after each timeout,
      becomes longer than the rtt, and the stun reply can be handled.
      
      Differential Revision: https://phabricator.freedesktop.org/D1115
      d516fca1
    • Fabrice Bellet's avatar
      conncheck: do not recheck a just succeeded pair · f19d209d
      Fabrice Bellet authored
      We cancel the potential in-progress transaction cancellation, caused by
      sect 7.2.1.4 "Triggered Checks", when we receive a valid reply before
      transmission timeout, or just after timeout, when the pair is
      temporarily put on the triggered check list on the way to be
      rechecked. This situation is not covered by the RFC 5245.
      
      Differential Revision: https://phabricator.freedesktop.org/D1119
      f19d209d
    • Fabrice Bellet's avatar
      conncheck: fix a state transition case · 59fe4851
      Fabrice Bellet authored
      When a new stun request hits a valid pair, of a failed component, we may
      have a transition from state failed to connected. In this situation, we
      do a logical progression failed -> connecting -> connected, like we do
      in function priv_update_check_list_state_for_ready()
      
      Similarily, when a new stun request hits a failed pair, of a failed
      component, triggering a new conncheck for this pair may also cause the
      component state to move back from failed to connecting state.
      
      Differential Revision: https://phabricator.freedesktop.org/D1118
      59fe4851
    • Fabrice Bellet's avatar
      conncheck: try to change earlier to state ready · 6a512b6e
      Fabrice Bellet authored
      We check if we can move from state connected to ready just
      after a pair expired its retransmission count. This pair
      will be marked failed, and will no longer be in-progress.
      The number of in-progress dropping down to zero is one
      of the conditions needed to make the transition to ready,
      per component (and not globally as it's the case in other
      locations where this check function is called).
      
      Differential Revision: https://phabricator.freedesktop.org/D1117
      6a512b6e
    • Fabrice Bellet's avatar
      conncheck: dont cancel a pair for triggered check · 8fa648a1
      Fabrice Bellet authored
      This patch adds another supplementary "corner" case, not covered by the
      ICE spec, sect 8.1.2, "Updating States". A pair in waiting state and in
      the triggered check list should be considered like an in-progress pair,
      and cancelled only if its priority is lower than the priority of the
      nominated pair. This is required in some aggressive nomination
      situations for both peers to select the same pair, having the highest
      priority.
      
      Differential Revision: https://phabricator.freedesktop.org/D933
      8fa648a1
    • Fabrice Bellet's avatar
      conncheck: remove a useless pair recheck · 11d4e37a
      Fabrice Bellet authored
      This exception to the ICE spec is no longer needed: when a pair is in
      the succeeded state, there is no needed to recheck it again upon
      reception of an incoming stun request on it.
      
      Differential Revision: https://phabricator.freedesktop.org/D884
      11d4e37a
    • Fabrice Bellet's avatar
      conncheck: update the pair state in triggered check list · 25b3eeec
      Fabrice Bellet authored
      With this patch, we update the state of the pair to waiting when
      it is put in the triggered check queue. We also take care to call
      priv_schedule_triggered_check() before priv_mark_pair_nominated()
      so a pair to be rechecked and put on the triggered check queue
      will have a unique state to be tested in the following call to
      priv_mark_pair_nominated() when evaluating its nomination attributes.
      
      Differential Revision: https://phabricator.freedesktop.org/D883
      25b3eeec
    • Fabrice Bellet's avatar
      conncheck: new pairs never have the nominated flag preset · afd8d41b
      Fabrice Bellet authored
      This patch disables the possibility to set the nominated flag of a
      candidate pair at creation time. This possibility was used when a new
      pair is created from a new peer reflexive remote candidate, when the
      agent is in controlled mode, and an stun request with USE-CANDIDATE is
      received. In this case, since previous commit "conncheck: fix a
      nomination corner case", we set the nominated flag when the stun
      response of this new pair will arrive, and not before.  Consequently,
      this flag is no longer required when the pair is created.
      
      Differential Revision: https://phabricator.freedesktop.org/D881
      afd8d41b
    • Fabrice Bellet's avatar
      conncheck: fix a nomination corner case · 3916b8bc
      Fabrice Bellet authored
      This patch add two supplementary cases, not covered by the ICE spec,
      sect 7.2.1.5 "Updating the Nominated Flag" when a controlled agent
      receives a STUN request with the USE-CANDIDATE flag, for a pair that is
      in the waiting state. We consider that this case is similar to the
      in-progress state, and should be handled in the same way. We also accept
      when the pair is in frozen state. This latter case happens in the
      new-dribble test, when an agent replays incoming early connchecks.
      
      Differential Revision: https://phabricator.freedesktop.org/D880
      3916b8bc
    • Fabrice Bellet's avatar
      conncheck: use the right pair when retriggering a check · 9103a5f2
      Fabrice Bellet authored
      This patch completes the previous patch by adding a link back from the
      discovered pair, to the parent pair that generated this check. This link
      is needed by the ICE spec, to comply with section 8.1.1.1, "Regular
      nomination", where the check to be retriggered is the initial check that
      caused the discovery of the valid pair. When the valid pair is a
      peer-reflexive pair, the retriggered check must target the succeeded
      pair, and not the valid discovered pair.
      
      Differential Revision: https://phabricator.freedesktop.org/D879
      9103a5f2
    • Fabrice Bellet's avatar
      conncheck: link succeeded and discovered pairs · 72ee528f
      Fabrice Bellet authored
      When the agent has the role of the stun server, is in controlled mode,
      and receives a pair with the "use-candidate" attribute set, it must find
      a matching succeded or discovered pair in its conncheck list. This is
      described in ICE spec 7.2.1.5, "Updating the Nominated Flag", item #1.
      When a matching pair is in succeeded state, the agent must nominate the
      valid pair (a discovered pair) constructed from section 7.1.3.2.2,
      that's been created from this succeeded one. To make this lookup, we
      introduce a new "discovered_pair" member of the CandidateCheckPair
      struct, that links the succeeded pair, and its discovered pair
      if any.
      
      Differential Revision: https://phabricator.freedesktop.org/D878
      72ee528f
    • Fabrice Bellet's avatar
      conncheck: improve triggered check of in-progress pairs · 2fd78084
      Fabrice Bellet authored
      This patch update the way triggered checks of in-progress pairs are
      handled, according to ICE spec, section 7.2.1.4. Previously the same
      connection check was retransmitted with an updated timeout. This causes
      problems when a controlling role switch occurs in this time frame.
      This is the reason why a new connection check must be generated
      reflecting the updated role. We introduce a new flag "recheck_on_timeout"
      in the pair indicating that the pair must be rechecked at the next timer
      expiration.
      
      Differential Revision: https://phabricator.freedesktop.org/D875
      2fd78084
  2. 12 Jun, 2017 9 commits
    • Fabrice Bellet's avatar
      ead3453d
    • Fabrice Bellet's avatar
      conncheck: improve the selection of the pairs to be checked · 15c0546f
      Fabrice Bellet authored
      This patch aims to implement more closely the algorithm described
      in RFC 5245 indicating how pairs are transitionned from state Frozen
      to Waiting. This is described in 7.1.3.2 when a check succeeded, and
      correspond to modifications in function priv_conn_check_unfreeze_related().
      This is also described in 5.7.4 when defining the initial state of the
      pairs in a conncheck, and correspond to modifications in function
      priv_conn_check_unfreeze_next().
      
      This patch introduces the notion of active and frozen check list. It
      allows us to define the timer restranmission delay as described in 16.1.
      
      Another modification in priv_conn_check_tick_unlocked() is that every
      stream in handled consecutively, and in an independant way. The pacing
      was previously of a single STUN request emitted per callback, it is now
      of a triggered check per callback OR a single STUN per callback AND per
      stream per callback.
      
      The description of ordinary checks per stream in 5.8 is detailled in
      function priv_conn_check_tick_stream(), and a remaining of the code
      used to nominate a pair by the controlling agent is put in a dedicated
      function priv_conn_check_tick_stream_nominate()
      
      Differential Revision: https://phabricator.freedesktop.org/D813
      15c0546f
    • Fabrice Bellet's avatar
      conncheck: update pair valid property selectively · 58d061df
      Fabrice Bellet authored
      With this patch, we fix a corner case when the succeeded pair is a
      peer-reflexive candidate pair, that already has been discovered
      previously, In this case, the current pair -p- should not be marked
      valid, because the valid flag is already set on the discovered pair.
      
      Differential Revision: https://phabricator.freedesktop.org/D1124
      58d061df
    • Fabrice Bellet's avatar
    • Fabrice Bellet's avatar
      conncheck: implement ice regular nomination method · 0636f9ad
      Fabrice Bellet authored
      This patch implements Regular Nomation as described in RFC5245
      8.1.1.1. The controlling agent lets valid pairs accumulate, and
      decides which pair to recheck with the use-candidate attribute set.
      priv_mark_pair_nominated() follows 7.2.1.5, to update the nominated
      pair when acting as a STUN server, and
      priv_map_reply_to_conn_check_request() implements 7.1.3.2.4 to
      update the nominated pair when acting as a STUN client. A new
      property is also added to the agent to control the nomination
      mode, which can be regular of aggressive, with default value
      set to aggressive.
      
      Two new flags are introduced in the CandidateCheckPair structure:
      
      - use_candidate_on_next_check indicates the STUN client to add the
        use-candidate attribute when the pair will be checked. At this
        time, the nominated flag has not been set on this pair yet.
      
      - mark_nominated_on_response_arrival indicates the STUN server
        to nominate the pair when its succesfull response to a
        previous triggered check will arrive (7.2.1.5, item #2)
      
      Differential Revision: https://phabricator.freedesktop.org/D811
      0636f9ad
    • Fabrice Bellet's avatar
      conncheck: fix pair state transition when successful response is received · a602ff57
      Fabrice Bellet authored
      According the ICE RFC 5245, 7.1.3.2.3, the pair that *generated* a
      successful check should go to state succeeded, not only the valid
      pair built in section 7.1.3.2.2.
      
      Differential Revision: https://phabricator.freedesktop.org/D810
      a602ff57
    • Fabrice Bellet's avatar
      conncheck: peer reflexive candidates are not paired · 3a58ba61
      Fabrice Bellet authored
      This patch makes the code compliant with ICE RFC, 7.2.1.3 "Learning
      Peer Reflexive Candidates" and 7.1.3.2.1 "Discovering Peer Reflexive
      Candidates", where discovered candidates do not cause the creation
      of new pairs to be checked.
      
      Differential Revision: https://phabricator.freedesktop.org/D805
      3a58ba61
    • Fabrice Bellet's avatar
      conncheck: update selected pair when nominated flag is set · 7a2c1edf
      Fabrice Bellet authored
      This modifies commit 8f1f615e. It is better focused to update the
      selected pair just after its nominated flag has been set. We also keep
      the code homogeneous with other places, where the call to
      priv_update_selected_pair() immediately follows the setting of
      pair->nominated. Moreover in priv_update_check_list_state_for_ready(),
      we would call priv_update_selected_pair() more times that necessary when
      iterating on all nominated pairs.
      
      Differential Revision: https://phabricator.freedesktop.org/D1125
      7a2c1edf
    • Fabrice Bellet's avatar
      stun timer: make properties for stun timer tunables · 8bb210c5
      Fabrice Bellet authored
      Three STUN binding request properties should be customisable. RFC 5245
      describes the retransmission timer of the STUN transaction 'RTO', and
      RFC 5389 describes the number of retransmissions to send until a
      response is received 'Rc'. The third property is the 'RTO' when
      a reliable connection is used.
      
      RFC 5389 introduces a supplementary property 'Rm' as a multiplier used
      to compute the final timeout RTO * Rm. However, this property is not
      added in libnice, because this would require breaking the public API for
      STUN. Currently, our STUN implementation hardcodes a division by two for
      this final timeout.
      
      Differential Revision: https://phabricator.freedesktop.org/D1109
      8bb210c5
  3. 08 Jun, 2017 2 commits
  4. 01 May, 2017 1 commit
  5. 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
      server.
      
      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
      0a2cb0a9
    • 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
      f6f704c5
  6. 11 Apr, 2017 5 commits
  7. 05 Apr, 2017 3 commits
  8. 04 Apr, 2017 5 commits