- 22 Jul, 2020 2 commits
-
-
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 16 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
-
Olivier Crête authored
The stream and component pointers are always valid there.
-
Olivier Crête authored
-
Olivier Crête authored
They're always meson now.
-
Tim-Philipp Müller authored
Remove dist check on the CI, since it doesn't really add anything in the Meson case (tarball is based on files checked into git and srcdir != builddir).
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
meson already sets it on warning_level >= 2
-
Olivier Crête authored
The previous patch didn't get triggered
-
Olivier Crête authored
-
Olivier Crête authored
Older gtkdoc versions expect to find a Makefile, so generate a fake one with the information it wants.
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
-
Olivier Crête authored
-
- 19 May, 2020 1 commit
-
-
Fabrice Bellet authored
This patch reenables an interesting side effect that existed before commit 263c0903, when the state of a pair state in the triggered check list was changed to in-progress. Such "triggered" pairs with this state were selectively pruned from the conncheck list according to their priority in priv_prune_pending_checks(), meaning that pairs with a high priority were conserved, and quickly rechecked. Retrospectively, I suspect that this side effect was the initial motivation for changing the state of a "triggered" pair. Commit 263c0903 disabled that behaviour, for the sake of clarity, but it seems important to restore it, because these "triggered" pairs are often retriggered for a good reason, and frequently lead to a nominated pair. And loosing the opportunity to nominate a pair may be critical in controlled role when the peer agent is in aggressive nomination mode.
-
- 18 May, 2020 7 commits
-
-
Olivier Crête authored
The timeout has a weak ref that should be enough.
-
Olivier Crête authored
-
Fabrice Bellet authored
This patch ensures that the retransmit flag is more tightly in sync with the stun transaction list, by now clearing it when the list becomes empty. It makes the code a bit more readable by dropping some cases. In a couple of places, the retransmit flag was also used as a way to compare the priority of a pair and the priority of the selected pair.
-
Fabrice Bellet authored
When reactivating a high priority pair, we have to change back the component state from ready to connected, since there is a new pair to be tested. The case of the succeeded pair is also a bit simplified, the invocation of the function conn_check_update_check_list_state_for_ready() to complete the ready - connected - ready flip-flop transition is not required for the trickle test any longer.
-
Fabrice Bellet authored
This test is redundant with the previous one.
-
Fabrice Bellet authored
We prefer to not change the state of the pair, when it is added to the triggered check queue. Previously its state was changed to in-progress, which was a bit misleading, as it somewhat anticipated a future state.
-
Fabrice Bellet authored
Since commit fcd6bc86 a pair is not always created, when its priority is lower than the selected pair priority. We have to deal with this possibility when calling the function priv_add_new_check_pair(). More precisely, the component state update really requires the addition of a new pair.
-
- 14 May, 2020 3 commits
-
-
Fabrice Bellet authored
With this patch, we merge the two variables stun_sent and keep_timer_going. The three functions that are a possible source of a new stun request returns a boolean value stating if a request has been sent. The semantic of keep_timer_going can now be deduced from stun_sent and from the result of priv_conn_check_stream_nominate(). The trick that makes this merge possible is to repurpose the return value of priv_conn_check_tick_stream(), because keep_timer_going set when the conncheck list contains in-progress pairs in this function is redundant with the same check later in function priv_conn_check_tick_stream_nominate().
-
Fabrice Bellet authored
With this patch, we try to make more explicit the process order between the different types of stun requets, according that only one request is sent per callback timer tick, ie every 20ms, to respect the stun pacing of the spec. We implement the follow priority: * triggered checks * stun retransmissions * ordinary checks In a concrete case, while a stream has stun requests related to triggered checks to be sent, all other stun transactions are delayed to the next timer ticks. The goal of this patch is to make this priority explicit, and more easily swappable if needed. Triggered checks have more probability to succeed than stun retransmissions, this is the reason why they are handled before. Ordinary checks on the contrary can be performed on a lower priority basis, after all other stun requests. The problem that can be sometime observed with a large number of stun transactions is that stun retransmissions may suffer from a delay after they have reached their deadline. This delay should remain small thanks to the design of the initial retransmission timer (RTO), that takes into account the overall number of scheduled stun requests. It allows all stun requests to be sent and resent at a predefined "pacing" frequency without much extra delay. This ordering not perfect, because stun requests of a given type are examinated per-stream, by looking at the first stream before the others, so it introduces a natural priority for the first stream.
-
Olivier Crête authored
-
- 13 May, 2020 1 commit
-
-
Olivier Crête authored
-
- 12 May, 2020 1 commit
-
-
Olivier Crête authored
-