GitLab

This patch fixes the transition of a component from connecting to
failed, that previously occured due to the propagation of the
keep_timer_going variable, and to the final call to function
priv_update_check_list_failed_components(), after the global agent
timer was stopped.

Previously, the code almost never entered to failed state, because the
timer was going one, as long as the number of nominated pair was not
enough, and as long as there were valid pairs not yet nominated. Even
if all pair timers were over.

The definition of the Failed state of a conncheck list is somewhat
contradictory in the spec, depending on weather you read :

 * sect 5.7.4. "Computing States",
 "Failed:  In this state, the ICE checks have not completed successfully
 for this media stream."

 or

 * sect 7.1.3.3. "Check List and Timer State Updates",
 "If all of the pairs in the check list are now either in the Failed or
 Succeeded state: If there is not a pair in the valid list for each
 component of the media stream, the state of the check list is set to
 Failed."

Our understanding of the ICE spec is that, the proper way to enter failed
state instead in when all connchecks have no longer in-progress pairs.
All pairs are either in state succeeded, discovered, or failed. No timer
is still running, and we have no hope that the conncheck list changes
again, except if an unexpected STUN packet arrives later. All pairs in
frozen state is a special case, that is handled separately (sect
7.1.3.3).

A special grace delay is added before declaring a component in state
Failed. This delay is not part of the RFC, and it is aimed to limit the
cases when a conncheck list is reactivated just after it's been declared
failed, causing a user visible transition from connecting to failed, and
back from failed to connecting again. This is also required by the test
suite, that counts exactly the number of time each state is entered, and
doesn't expect these transcient failed states to happen (frequent due to
the nature of the testsuite, less frequent in real life).

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

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

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

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

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

This allows implementing WebRTC privacy mode.

The checks should not be sent immediately in priv_conn_check_initiate(),
but be put into the "triggered queue", see  "7.2.1.4 Triggered Checks".
This patch implements this triggered checks list, and uses it to enforce a
pacing of STUN transactions, no more than one per Ta ms, according to
"B.1. Pacing of STUN Transactions".
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
Differential Revision: https://phabricator.freedesktop.org/D802

Remove all references to the old, unnamespaced versions. This should
cause no functional changes.
Reviewed-by: Olivier Crête <olivier.crete@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D309

Remove all references to the old, unnamespaced versions. This should
cause no functional changes.
Reviewed-by: Olivier Crête <olivier.crete@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D308

A new socket created in nice_tcp_active_socket_connect() should have its
writable callback set, because it's possible for it to become a base
socket of a peer reflexive candidate, if some is discovered by
connection checks on that TCP active candidate.

Previously, when such prflx candidate became selected, without write_cb
on the socket the agent was never notified about it becoming writable
again after the socket's buffer got filled up. This caused the data flow
to hang permanently.
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Reviewed-by: Olivier Crête <olivier.crete@collabora.com>

http://phabricator.freedesktop.org/T117

This way, the regular log will only contain connection-time information.

Clean up the UPnP mappings of each stream when closing it

To allow enhanced grepping for what structs point to other structs.

Modify agent_timeout_add_with_context() to force destroying and freeing
of an existing GSource before overwriting it with a new one (probably
with an updated timeout period).

This fixes a case in priv_map_reply_to_relay_refresh() where the TURN
candidate refresh timer was being overwritten with a new one, without
the old one being destroyed. This lead to two timeouts existing, only
one of which would be destroyed when the CandidateRefresh struct was
freed, leaking the other one (in the main context) and allowing it to be
later dispatched with a dangling CandidateRefresh pointer.

The modification to agent_timeout_add_with_context() should prevent this
happening in new code in future.

Modify the agent_timeout_add_with_context() utility function to
automatically add names to the timer GSources it creates. This makes
them a little easier to identify when debugging.

Otherwise we risk running out of space in the space limited saved ids
list. So the easiest way to do that is to put one StunAgent in each
component. It may be advisable to just give up on not allocating
memory inside libstun and just use a regular hash table in there
instead.

This is to use keepalives to check if the connection is still ongoing. If
they don't get a reply, then we can assume that the connection has died.

This needs to not happen in the case of ICE-TCP.

This is a massive commit that can't be split. We add ice-tcp support
into the agent by creating local host tcp-active/tcp-passive candidates.
We also need to find the local and remote candidates whenever we discover
a peer-reflexive because their data is important to setup the peer-reflexive
so a few changes were added to look for the local or remote candidate.
For TCP-ACTIVE remote peer-reflexive candidates, we can't add conncheck
pairs normally because TCP-PASSIVE (local) do not generate candidate pairs,
and we also can't have a connection from any local host, so we can only create
a single candidatepair with the local/remote that are connected.
The pair->socket of a candidate check pair will hold the connected tcp socket
(through connect for ACT or accept for PASS) and we will either have a
remote or a local peer-reflexive which will create a new candidate pair,
we cannot trigger checks on the initial candidate pair, we must only do it
on the new check pairs. but in the case of a tcp-passive, we don't get a new
local peer-reflexive candidate, so there is no new candidate with a new NiceSocket, so
when we get a triggered check, we need to match it to the candidate check pair
or when we select a pair, it will still use the original TCP-PASS socket.
We must store the new connected tcp socket in the peer reflexive candidates
since they represent that unique peer-reflx candidate's connection

One issue with tcp-bsd is that it will queue messages when the tcp socket
is not writable, but it will also drop messages when the queue is full.
If we want to do proper reliable ice-tcp, we need to make sure that
messages don't get dropped, also, this would affect http/socks5/pseudossl
if their messages get dropped. For ice-tcp, when the socket is not writable
we want to return 0, not queue the message.
The change here is to allow connchecks and other important protocol messages
to be sent as 'reliable' on tcp transports by queuing them and in the various
socket layers and to never drop them, but all user messages will be dropped.

if the tcp socket is not writable.

This way, there can be no annoying re-entrancy in our code.

Use it instead of memcmp() to avoid comparing padding bytes.

It was used correctly only half the time anyway

Replace the send() API with a send_messages() API, which supports
sending multiple messages, each with multiple buffers rather than a
single monolithic buffer.

This doesn’t break API, as the socket API is not exposed outside
libnice. It does introduce a new struct: NiceOutputMessage, which is
analogous to struct mmsghdr and NiceInputMessage.

This includes updates to the test-bsd test to cover the changed API.

The existing nice_socket_send() API has been retained as a thin wrapper
around nice_socket_send_messages(), for convenience only. It’s hoped
that internal usage of this API will decline to the point where it can
be removed.

Add two new public functions:
 • nice_agent_recv_messages()
 • nice_agent_recv_messages_nonblocking()
which allow receiving multiple messages in a single call, and support
vectors of buffers to receive the messages into.

The existing nice_agent_recv[_nonblocking]() APIs have been left
untouched.

This tidies up a lot of the message handling code internally, and
eliminates a couple of memcpy()s. There are still a few more memcpy()s
on the critical path, which could be eliminated with further work.

In the reliable agent case, every message is memcpy()ed twice: once into
the pseudo-TCP receive buffer, and once out of it. The copy on input
could be eliminated (in the case of in-order delivery of packets) by
receiving directly into the receive buffer. The copy on output can’t be
eliminated except in the I/O callback case (when
nice_agent_attach_recv() has been used), in which case the callback
could be invoked with a pointer directly into the pseudo-TCP receive
buffer.

In the non-reliable agent case, zero memcpy()s are used.

A couple of the more complex socket implementations (TURN and HTTP) have
slow paths during setup, and partially also during normal use. These
could be optimised further, and FIXME comments have been added.

Replace the recv() API with a recv_messages() API, which supports
receiving multiple messages, each with multiple buffers rather than a
single monolithic buffer.

This doesn’t break API, as the socket API is not exposed outside
libnice. It does introduce a new struct: NiceInputMessage, which is
analogous to struct mmsghdr.

This includes updates to the test-bsd test to cover the changed API.

This is a blocking receive function, designed to be called from a worker
thread. It cannot be used in conjunction with the existing
nice_agent_attach_recv() API, as the blocking receive and the GSource
would compete over access to the single copy of the data in the kernel’s
receive buffer.

Rather than handle GSource creation, attachment and removal in
NiceAgent, handle it inside Component. This brings it closer to the
networking code, and improves encapsulation of the state of each
Component.

Use a global mutex for all nice agents and use g_source_is_destroyed to avoid the race condition of a source being destroyed while we wait for the mutex