- 07 Dec, 2020 1 commit
-
-
Fabrice Bellet authored
With this patch, we handle tcp disconnections in a more robust way. Such disconnections cause the underlying socket to be detached, and various related pairs have to be discarded from the conncheck list. This may cause unexpected behaviour, like a previously connected component to come back in state connecting, if the selected pair is concerned by a tcp disconnection for example.
-
- 26 Oct, 2020 1 commit
-
-
Olivier Crête authored
This was introduced recently and flagged by Coverity.
-
- 21 Oct, 2020 12 commits
-
-
Olivier Crête authored
-
Olivier Crête authored
The keyring in our base image is outdated.
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
Also don't fail the first iteration of upgrade Solution found by Jordan Petritis
-
Olivier Crête authored
-
Chi Liu authored
-
Olivier Crête authored
-
Olivier Crête authored
This should make it work even if no remote candidates at all are set in the case where we can establish a connection based only on peer reflexive candidates.
-
Olivier Crête authored
Also rewrite the logic a little, and try to make the code a little clearer.
-
Olivier Crête authored
-
Olivier Crête authored
-
- 20 Oct, 2020 1 commit
-
-
Johan Sternerup authored
Previously, a STUN response for which there was no associated request would be considered valid media input and as such could keep a dead connection alive. If peer A was communicating with peer B and peer B got disconnected, the keepalive mechanism in peer A should detect this. However, a misbehaving STUN server could keep sending STUN responses to peer A which would then be considered a valid communication between A and B and thereby prevent the keepalive mechanism from shutting down the connection. Situation above refers to a stun message validated as STUN_VALIDATION_UNMATCHED_RESPONSE. With this change only messages validated as STUN_VALIDATION_SUCCESS may keep the connection alive.
-
- 17 Sep, 2020 1 commit
-
-
Johan Sternerup authored
Previously if we enabled both UDP and TCP to the same TURN server, the TCP connection would not work. What happened was that when traffic was targeted at the TCP connection we would fail to route the traffic to the right socket due to a too early jump out of the loop searching for the socket. The search would stop when finding a TURN server matching the address of the incoming message source. Thus, a UDP TURN server with the same address as the TCP TURN server would effectively mean that traffic got routed to a different stun agent that would complain about receiving responses without matching requests.
-
- 20 Aug, 2020 1 commit
-
-
Olivier Crête authored
This is slightly an API break, but it should never have been public.
-
- 18 Aug, 2020 2 commits
-
-
Olivier Crête authored
This will make it fail if either our test of UDP port clash fails or if the kernel rejects the new socket because there is a port clash. Also include a unit test for this.
-
Olivier Crête authored
-
- 13 Aug, 2020 1 commit
-
-
Ami Perlmutter authored
-
- 10 Aug, 2020 2 commits
-
-
Olivier Crête authored
-
Olivier Crête authored
This makes coverity happier.
-
- 04 Aug, 2020 4 commits
-
-
Lorenzo Miniero authored
-
Lorenzo Miniero authored
-
Lorenzo Miniero authored
-
Lorenzo Miniero authored
-
- 22 Jul, 2020 3 commits
-
-
Olivier Crête authored
-
Olivier Crête authored
Commit a04fa4d4 introduced a new feature to try to have a different port for every local candidate, even if they are on different interfaces. This breaks setups where the application really wants a specific port and sets a range of exactly 1 port or a very small range. In that case, if we can't find non-duplicated ports, then we just go around again and skip that check, but only if both ports are in the same stream and component. Otherwise, we fail the whole component!
-
Olivier Crête authored
Adds new public APIs, nice_candidate_type_to_string() and nice_candidate_transport_to_string().
-
- 09 Jul, 2020 5 commits
-
-
Nirbheek Chauhan authored
-
Nirbheek Chauhan authored
nice_interfaces_get_local_interfaces() was returning the hardware device names of interfaces that have been seen in the past or could be connected. It had no relation to the actual interfaces present on the device. Perhaps this worked back in the XP days, but it is returning garbage today. Use GetAdapterAddresses(), and return the adapter friendly names as the interface names. At the same time, update nice_interfaces_get_ip_for_interface() to match. Coincidentally, this also fixes UWP compatibility since GetIfTable and GetIpAddrTable are not available when targeting UWP. They are only available for desktop apps: https://docs.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getiftable https://docs.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getipaddrtable
-
Nirbheek Chauhan authored
-
Nirbheek Chauhan authored
Still prefer ipv4 addresses for backwards-compat. GetBestInterface is not allowed when targeting UWP, so use GetBestInterfaceEx. Also add some debug logging to ensure that the function is actually running correctly.
-
Nirbheek Chauhan authored
Helps when you forgot to call WSAStartup, for instance.
-
- 26 Jun, 2020 1 commit
-
-
Olivier Crête authored
Instead, collect all the pieces until it's complete.
-
- 25 Jun, 2020 1 commit
-
-
Nirbheek Chauhan authored
Windows ships with `WinSock2.h` but mingw ships with `winsock2.h`. This is fine on Windows because files are case-insensitive, but on Linux it causes the compiler to not find the header. All other #includes are lowercase, so just use that.
-
- 15 Jun, 2020 2 commits
-
-
Nirbheek Chauhan authored
-
Nirbheek Chauhan authored
We will always have either openssl or gnutls, which are better sources for random nonces. Also, CryptGenRandom is deprecated API that's not available on WinRT/UWP.
-
- 22 May, 2020 2 commits
-
-
Fabrice Bellet authored
This patch tries to move the component state from connected to ready in places where a pair may fail. Consequently, the final check done after the expiration of the idle timeout can be removed, assuming that transitions are done as soon as they occur. The only place where such a situation has been observed in a real world stress test is a 401 unauthorized stun error received in priv_map_reply_to_conn_check_request(), when the conncheck contains a local and a remote candidate, both of type host, with an identical IP address and port number (two boxes with a private network using the same subnet). In such a case, a stun request to the remote candidate will reach the local candidate instead, and will logically fail.
-
Olivier Crête authored
Meson always does out of tree builds
-