- 27 May, 2016 6 commits
-
-
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
-
- 01 Mar, 2016 9 commits
-
-
Olivier Crête authored
If nicesocket is not added to a component it will be leaked. This is the case of active tcp sockets Change-Id: I57fefffef71d35ce9871139ee1064181f6fe125b Reviewed-by:
José Antonio Santos Cadenas <santoscadenas@gmail.com> Differential Revision: https://phabricator.freedesktop.org/D822
-
Philip Withnall authored
In priv_update_selected_pair(), commit 57393333 changed the code to re-find a CandidatePair matching the given lfoundation and rfoundation. However, the foundation does not uniquely identify candidate pairs, and if we’re aiming to set a specific candidate pair as the selected pair, this could result in the wrong pair being selected. This can happen when handling multiple similar candidate pairs, such as when generating peer reflexive candidates from multiple sources. See https://tools.ietf.org/html/rfc5245#section-2.4. Originally spotted by Fabrice Bellet in https://phabricator.freedesktop.org/T3557. Reviewed-by:
José Antonio Santos Cadenas <santoscadenas@gmail.com> Differential Revision: https://phabricator.freedesktop.org/D742
-
Philip Withnall authored
Reviewed-by:
Olivier Crête <olivier.crete@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D819
-
Philip Withnall authored
The test didn't let enough time for ragent to reach the completed state after obtaining its remote candidates and switching to connecting state. Reviewed-by:
Olivier Crête <olivier.crete@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D817
-
Philip Withnall authored
The update of pairs priorities due to agent role change requires the conncheck list to be reordered to reflect this modification. Reviewed-by:
Olivier Crête <olivier.crete@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D806
-
Philip Withnall authored
With this patch, we send keepalive binding requests using agent compatibility flags, instead of RFC 3489 classic stun. The peer stun agent will known how to handle it, and won't be confused by the uncompatible RFC 3489 message, causing "no cookie" errors in the debug log. Reviewed-by:
Olivier Crête <olivier.crete@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D804
-
Philip Withnall authored
This patch fixes a bug where the foundation definition shouldn't take into account the stream the pair belongs to. This is important, because the ordinary checks algorithm will change pair state from Frozen to Waiting, by selecting pairs from other streams sharing the same foundation than already succeeded pairs. Reviewed-by:
Olivier Crête <olivier.crete@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D815
-
Philip Withnall authored
The local preference depends on the rank of the IP address in the list of all IP addresses available of the box running the test. As this value is not fixed we ignore it in the test. Reviewed-by:
Olivier Crête <olivier.crete@collabora.com> Differential Revision: https://phabricator.freedesktop.org/D818