- 03 Jun, 2016 12 commits
-
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
Accept packets much beyond the default MTU, but set a reasonable default MTU for sending of 1400
-
Olivier Crête authored
This is required as no retransmissions will happen
-
Olivier Crête authored
-
Olivier Crête authored
-
Philip Withnall authored
Correct the behaviour of pseudo_tcp_socket_get_available_bytes() and pseudo_tcp_get_available_send_space() when the socket is not in TCP_ESTABLISHED state. It’s still permissible to send and receive up until the local side calls pseudo_tcp_socket_close(), which means we may be in state TCP_ESTABLISHED *or TCP_CLOSE_WAIT*.
-
Philip Withnall authored
The state tracking previously assumed that if a FIN packet was sent, the other side received it and the preceding packets, and hence it was correct to sent an RST if an unexpected packet (such as a delayed SYN-ACK) was received. In cases where there is high packet loss, this won’t work. For example, peer A sends a SYN, it is received and peer B replies with a SYN-ACK which is also received; then peer A sends its data and a FIN, which are both dropped. Since it hasn’t received anything since the original SYN, peer B resends its SYN-ACK. If that is received, peer A was incorrectly treating it as an erroneous packet, and would then send a RST. In actual fact, it should take this as a signal that the data and FIN packets were dropped, and should resend them. TODO: Add unit tests
-
Philip Withnall authored
Otherwise we can’t easily differentiate between different transmission failures; for example: underlying socket failures, versus retransmission timeouts.
-
Philip Withnall authored
-
Philip Withnall authored
Previously, pseudo_tcp_socket_recv() would start returning 0 (EOS) as soon as a FIN segment was received from the peer, even if there was unread data already in the receive buffer. Instead, the unread data should all be accessible before pseudo_tcp_socket_recv() starts returning 0.
-
Philip Withnall authored
Previously, if peer A transmitted one or more data segments (1), followed by a FIN segment (2) to peer B, and segments 1 were dropped, peer B would not request retransmission of them and would instead continue with the FIN handshake. This effectively meant segments 1 were lost without peer B realising. Fix this by only handling the FIN segment once its sequence number is acknowledged in the receive window.
-
- 02 Jun, 2016 4 commits
-
-
Olivier Crête authored
Cleanly returnign makes no sense and may hide worse problems.
-
-
-
Olivier Crête authored
This test depends on rfc5766-turn-server which must be installed for this test to run.
-
- 01 Jun, 2016 2 commits
-
-
Jakub Adam authored
Doing so similarly to priv_process_response_check_for_reflexive(), which also sets valid flag on discovered peer reflexive pairs. Fixes a regression in previously working scenario. Differential Revision: https://phabricator.freedesktop.org/D1035
-
Jakub Adam authored
"new-selected-pair" may be emitted after "component-state-changed" to READY, by which time the main loop might have gotten quit in cb_component_state_changed(). Consequently, cb_new_selected_pair() could miss to register the selected pair, ultimately leading to an assertion failure in main(). We should wait for both selected pair and state change events to occur before stopping the main loop. Differential Revision: https://phabricator.freedesktop.org/D1044
-
- 31 May, 2016 3 commits
-
-
Olivier Crête authored
This reverts commit 01519677.
-
Olivier Crête authored
-
Jakub Adam authored
TCP active socket makes a NiceSocket for each peer in conn_check_send() and this new socket is then stored as CandidateCheckPair's 'sockptr'. We thus have to look also at the 'sockptr' value when eliminating sockets which have received HUP from connection checks. Differential Revision: https://phabricator.freedesktop.org/D1034
-
- 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 4 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.
-