- 30 May, 2016 6 commits
-
-
Olivier Crête authored
If a socket returned an error, remove it.
-
Olivier Crête authored
-
Olivier Crête authored
The TCP-based turns don't come pre-parsed unlike the UDP variants!
-
Olivier Crête authored
This allows implementing WebRTC privacy mode.
-
Olivier Crête authored
This only really applies in the force relay mode where there are no local candidates.
-
Olivier Crête authored
This should reduce the overhead a bit.
-
- 27 May, 2016 9 commits
-
-
Fabrice Bellet authored
This patch give details why some exceptions to the ICE spec are needed. Differential Revision: https://phabricator.freedesktop.org/D876
-
-
Olivier Crête authored
This patch fixes a bug in the way the list of incoming checks is handled. The code purges this list too early, before all ichecks for a given component are processed. It happens because the component is computed from each pair of the check list, instead of being passed as a fixed parameter of the function. Differential Revision: https://phabricator.freedesktop.org/D882
-
Fabrice Bellet authored
This patch fixes the role conflict handling in stun ICE usage, according to RFC 5245, by adding including missing cases in the test. The role switch not only depends of the comparison of the stun ice-controlling/controlled attrib with the agent tie breaker value, but it also depends on the current role of the agent. This patch also changes the value returned by stun_usage_ice_conncheck_create_reply() when a role conflict exists but doesn't change the role of the agent, causing an error stun response. Previously, this case could not be differenciated by the caller from a case with no role conflict. Now by examinating the return value, and whether the control param changed, the caller can check the four possibles situations. The stun test suite is updated to match this change. Differential Revision: https://phabricator.freedesktop.org/D873
-
-
Olivier Crête authored
This should fix compliance with RFC 5245 Section 4.1.2 https://phabricator.freedesktop.org/T3324
-
Olivier Crête authored
Only allow transitions to gathering from disconnected or failed states.
-
Olivier Crête authored
TCP active relay candidates use UDP TURN for their underlying socket. Since 0a6c779f, socket->fileno of UDP TURN sockets is always NULL, which caused a wrong code path to be chosen in conn_check_send(). We have to update the if-expression accordingly. Maniphest Tasks: T7442 Differential Revision: https://phabricator.freedesktop.org/D1017
-
Olivier Crête authored
Candidate gathering is stopped when discovery_add_local_host_candidate() returns HOST_CANDIDATE_CANT_CREATE_SOCKET. This may be too radical a measure when other local addresses can still be able to generate usable candidates. The issue was observed by a user who had an IPv6 address with tentative flag on one of the interfaces. That single failing address was causing the whole gathering process to end with no candidates found. Still, don't do this if nice_agent_add_local_address() has been called. In that case, the user really cares about the addresses and if there's any problem, the process should fail. https://phabricator.freedesktop.org/D1016
-
- 26 May, 2016 16 commits
-
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
If the keepalive is still being re-send, just let the retries do their job. If they don't get a reply, then declare the attempt failed.
-
Olivier Crête authored
RFC 5245 specifies that when a mapped-address differs from the address from the request was sent, the mapped-address is used to select the valid pair, but the source address of the check is used to select the pair that succeeded, so they are not the same.
-
Olivier Crête authored
UDP turn sockets should never be read frm directly. Because they may share the same socket with the non-relay, so the incoming data may not be relayed and then the NiceSocket API doesn't allow returning the base socket as the source.
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
If a remote candidate matches an already discovered peer-reflexive candidate, then the type can be updated to the real type and the foundation can be set correctly.
-
Olivier Crête authored
Using a IPv6 local address to connect to a IPv4 relay just creates an extra discovery attempt that will not provide something useful.
-
Olivier Crête authored
This is recommended by the STUN RFC 5389.
-
Olivier Crête authored
Instead of re-discovering the nonce and realm for every request, cache them in th socket.
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
-
- 20 May, 2016 1 commit
-
-
Olivier Crête authored
-
- 04 Apr, 2016 5 commits
-
-
Fabrice Bellet authored
This patch makes the debug log more explicit about the agent controlling role for each stun request sent. It helps to debug role conflict resolution. Reviewed-by:
Philip Withnall <philip.withnall@collabora.co.uk> Differential Revision: https://phabricator.freedesktop.org/D877
-
Fabrice Bellet authored
Just a cosmetic fix. Reviewed-by:
Philip Withnall <philip.withnall@collabora.co.uk> Differential Revision: https://phabricator.freedesktop.org/D872
-
Jakub Adam authored
• rename to nice_socket_is_based_on() and swap the order of arguments accordingly; the implementation doesn't have to use the confusing 'return other->is_base_of()' pattern anymore • fix potential NULL dereferences The argument order in agent_recv_message_unlocked() was already wrongly swapped in 1732c7d6 and thus this commit isn't changing it back because that order has become the correct one. Reviewed-by:
Philip Withnall <philip.withnall@collabora.co.uk> Differential Revision: https://phabricator.freedesktop.org/D866
-
Jakub Adam authored
We have to call is_base_of "virtual function pointer" of 'other' object, not 'sock', since 'other' is the structure whose base NiceSocket we need to get from its private data. For instance calling nice_socket_is_base_of() with 'sock' and 'other' being respectively pseudo-SSL and UDP-TURN-over-TCP invoked is_base_of variant for pseudo-SSL, casting other->priv into PseudoSSLPriv *, but other->priv is actually TurnTcpPriv *. It must be called the other way around. https://phabricator.freedesktop.org/T7335 https://phabricator.freedesktop.org/T7336Reviewed-by:
Philip Withnall <philip.withnall@collabora.co.uk> Reviewed-by:
José Antonio Santos Cadenas <santoscadenas@gmail.com> Reviewed-by:
Philip Withnall <philip@tecnocode.co.uk> Reviewed-by:
José Antonio Santos Cadenas <santoscadenas@gmail.com> Differential Revision: https://phabricator.freedesktop.org/D785
-
Fabrice Bellet authored
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
-
- 06 Mar, 2016 1 commit
-
-
Olivier Crête authored
Fixes crash reported on https://phabricator.freedesktop.org/D786
-
- 05 Mar, 2016 1 commit
-
-
Fabrice Bellet authored
Reviewed-by:
Olivier Crête <olivier.crete@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D807
-
- 02 Mar, 2016 1 commit
-
-
Jakub Adam authored
When a message is received from a TURN server and we manage to find a local relay candidate with matching stream and component IDs, we should also check whether the message came from the candidate's respective socket. We should do this because there might still be some pending TURN candidate discovery with the same server from a different local host IP and the message may be a response to our allocate request. If nice_udp_turn_socket_parse_recv_message() is passed such request, it can make some wrong assumptions and modify it like in the case of reliable UDP-TURN-OVER-TCP by removing (supposed) RFC4571 framing, which in turn causes the reply to be unrecognized and discarded. Because of this, any subsequent replies following the first successful allocate response from that server couldn't create any additional relay candidates. Maniphest Tasks: https://phabricator.freedesktop.org/T7336Reviewed-by:
Olivier Crête <olivier.crete@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D786
-