GitLab

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

Differential Revision: https://phabricator.freedesktop.org/D1123

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

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

Differential Revision: https://phabricator.freedesktop.org/D1107

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

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

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

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

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

Reported by Capricornus (zhushengliang)

https://phabricator.freedesktop.org/T7763

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

There’s no point in installing them; their benefit is in providing
example code to developers.

Debian doesn’t package them; Fedora packages them in a separate
subpackage which will have to disappear.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Olivier Crête <olivier.crete@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D1737

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

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

If we disable ice-tcp or ice-udp, ignore the remote
candidates for those types.

It was checking when the pair was created, but the role may have
already changed when the request is sent.

https://phabricator.freedesktop.org/T104Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Differential Revision: https://phabricator.freedesktop.org/D1717

This is required by the WebRTC spec.

Remove test-mainloop as it doesnt even try to do
a negotiation.

https://phabricator.freedesktop.org/T104

Differential Revision: https://phabricator.freedesktop.org/D1716

Add a function that can check if two candidates point to the same place.

https://phabricator.freedesktop.org/T104Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Differential Revision: https://phabricator.freedesktop.org/D1715

This fixes the valgrind integration with the new test drivers.

The same variable was used for return values from NiceSocket and
for the internal enum, but 0 and -1 have different meanings in both.

Various little things, none of which should make a functional difference.

It exits the loop immediately, so no point to set the variable.
And it makes the clang static analyzer happy.

It's now an array, not a pointer, so needs to test to emptyness.

It's a bugfix on the previous commit, 59ce41df

Consider that the answer is received when remote credentials
are set instead of when a remote candidate is set,
which could not happen or could cause more delay for the
connection establishment.

Ported to git master by Olivier Crête

Differential Revision: https://phabricator.freedesktop.org/D1704

There was a confusion and it tested against a value not in the enum.

We don't have or call noreturn functions in practice and it makes
the stun test build fail on clang.

This makes clang happy.

clang on recent macOS seems to only emit a warning on unknown flags
which makes this test fail and then when using Werror, it makes the
compiler test fail too.

It's only nonce level randomness, not long term key level.

Differential Revision: https://phabricator.freedesktop.org/D1711