| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This should make it possible to use OpenSSL or GnuTLS also on Windows if
required.
|
|
|
|
|
|
|
|
|
| |
As we only need a few primitives there isn't much OS-specific code
needed, and for applications that don't already depend on OpenSSL or
GnuTLS it simplifies the build process quite a lot.
Note that we use the vintage WinCrypt APIs as the Cryptography Next
Generation APIs are only available on Vista and newer.
|
|
|
|
| |
Add the relevant ifdef extern C bits
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specified in https://tools.ietf.org/html/rfc7675
RFC 7675 is a slight modification of the existing keepalive connection
checks that could be enabled manually or were used with the GOOGLE
compatibility mode.
Slight differences from the existing keepalive connection checks
include:
- an additional consent expiry timer instead of relying on all binding
requests to succeed.
- 403: 'Forbidden' stun error-code which revokes consent with immediate
effect.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch updates the stun timing constants and provides the rationale
with the choice of these new values, in the context of the ice
connection check algorithm.
One important value during the discovery state is the combination of the
initial timeout and the number of retransmissions, because this state
may complete after the last stun discovery binding request has timed
out. With the combination of 500ms and 3 retransmissions, the discovery
state is bound to 2000ms to discover server reflexive and relay
candidates.
The retransmission delay doubles at each retransmission except for the
last one. Generally, this state will complete sooner, when all
discovery requests get a reply before the timeout.
Another mechanism is used during the connection check, where an stun
request is sent with an initial timeout defined by :
RTO = MAX(500ms, Ta * (number of in-progress + waiting pairs))
with Ta = 20ms
The initial timeout is bounded by a minimum value, 500ms, and scales
linearly depending of the number of pairs on the way to be emited. The
same number of retransmissions than in the discovery state in used
during the connection check. The total time to wait for a pair to fail
is then RTO + 2*RTO + RTO = 4*RTO with 3 retransmissions.
On a typical laptop setup, with a wired and a wifi interface with
IPv4/IPv6 dual stack, a link-local and a link-global IPv6 address, a
couple a virtual addresses, a server-reflexive address, a turn relay
one, we end up with a total of 90 local candidates for 2 streams and 2
components each. The connection checks list includes up to 200 pairs
when tcp pairs are discarded, with :
<33 in-progress and waiting pairs in 50% cases (RTO = 660ms),
<55 in-progress and waiting pairs in 90% cases (RTO = 1100ms),
and up to 86 in-progres and waiting pairs (RTO = 1720ms)
The number of retransmission of 3 seems to be quite robust to handle
sporadic packets loss, if we consider for example a typical packet loss
frequency of 1% of the overall packets transmitted.
And a relatevely large initial timeout is interesting because it reduces
the overall network overhead caused by the stun requests and replies,
mesured around 3KB/s during a connection check with 4 components.
Finally, the total time to wait until all retransmissions have completed
and have timed out (2000ms with an initial timeout of 500ms and 3
retransmissions) gives a bound to the worst network latency we can
accept, when no packet is lost on the wire.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We may have situation when stun_timer_refresh is called with a
significant delay after the current deadline. In the actual situation,
this delay is just included to the computation of the new deadline of the
next stun retransmission. We think this may lead to unfair situations,
where the next deadline may be too short, just to compensate the first
deadline that was too long.
For example, if a stun request is scheduled with a delay of
200ms for the 2nd transmission, and 400ms for the 3rd transmission,
if stun_timer_remainder() is called 300ms after the start of the
timer, the second delay will last only 300ms, instead of 400ms.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Attribute is proposed here: https://tools.ietf.org/html/draft-thatcher-ice-renomination-00
WebRTC supports this attribute: controlling side provides attribute value increased by one each time selected pair is changed:
https://chromium.googlesource.com/external/webrtc/+/3c7d599750405bc734e1d5adbf1b54265b725a9d/p2p/base/p2ptransportchannel.cc#1821
|
| |
|
| |
|
|
|
|
| |
Closes #71
|
| |
|
|
|
|
| |
coturn doesn't authenticate us before sending us to an alternate server.
|
| |
|
|
|
|
| |
Errors reported by lintian -EvIL -pedantic.
|
|
|
|
|
|
|
| |
Meson needs to see all libraries a target depends on so that it can add
each to PATH when running "meson test".
Avoids "*.dll was not found" errors.
|
| |
|
| |
|
|
|
|
|
| |
stdint.h is available since vs2010 and stdbool.h since vs2013,
so we should be able to just use that these days.
|
|
|
|
| |
Tested inside Cerbero with VS 2017
|
|
|
|
|
|
|
|
| |
Just implement argument parsing ourselves here.
It's not really more lines of code than the getopt.h variant
and makes things build on Windows with MSVC without having to
ship a separate getopt implementation.
|
| |
|
|
|
|
|
|
|
| |
By default, 'candidate_identifier == NULL' only happens for 'compatibility
== NICE_COMPATIBILITY_GOOGLE'. However, keepalive=true will also trigger
the same code path so candidate_identifier must be checked to avoid a
segfault.
|
| |
|
|
|
|
|
|
| |
MacOS X and Windows don't have MSG_NOSIGNAL.
Signed-off-by: Justin Kim <justin.kim@collabora.com>
|
|
|
|
|
|
|
| |
Like all other instances of nice_RAND_bytes that were renamed
to nice_RAND_nonce.
Fixes the windows build
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The MS Office TURN servers will always return the MS_ALTERNATE_SERVER in
allocation responses, and if they are not handled, we end up using the
main turn server to send allocation requests that then get sent to the
alternate server which will return the XOR_MAPPED_ADDRESS containing
the IP address of the turn server that proxied the message instead of
our own actual external IP.
|
|
|
|
|
|
|
|
| |
https://phabricator.freedesktop.org/T7798
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: Olivier Crête <olivier.crete@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D1819
|
|
|
|
| |
Differential Revision: https://phabricator.freedesktop.org/D1754
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Three STUN binding request properties should be customisable. RFC 5245
describes the retransmission timer of the STUN transaction 'RTO', and
RFC 5389 describes the number of retransmissions to send until a
response is received 'Rc'. The third property is the 'RTO' when
a reliable connection is used.
RFC 5389 introduces a supplementary property 'Rm' as a multiplier used
to compute the final timeout RTO * Rm. However, this property is not
added in libnice, because this would require breaking the public API for
STUN. Currently, our STUN implementation hardcodes a division by two for
this final timeout.
Differential Revision: https://phabricator.freedesktop.org/D1109
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to RFC 5389, section 7.2.1, a special timeout is applied to
the last retransmission (Rm * RTO), with Rm default value of 16, instead
of (64 * RTO), 2^6 when the number of transmissions Rc is set to 7.
As spotted by Olivier Crete, stun_timer_* is a public API, that cannot
be changed, and the initial delay (RTO) is not preserved in the
stun_timer_s struct. So we use a hack that implicitely guess Rm from the
number of transmissions Rc, by generalizing the default value of the
spec for Rm and Rc to other values of Rc passed in stun_timer_start(
According to the spec, with the default value of Rc=7, the last delay
should be (64 * RTO), and it is instead (16 * RTO). So the last delay
can be computed by dividing the penultimate delay by two, instead of
multiplying it by two.
Differential Revision: https://phabricator.freedesktop.org/D1108
|
|
|
|
| |
Various little things, none of which should make a functional difference.
|
| |
|
| |
|
|
|
|
| |
This makes clang happy.
|
|
|
|
|
|
| |
It's only nonce level randomness, not long term key level.
Differential Revision: https://phabricator.freedesktop.org/D1711
|
|
|
|
|
|
|
| |
GLib already uses it, instead of adding another dep.
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Differential Revision: https://phabricator.freedesktop.org/D1705
|
|
|
|
|
|
|
| |
Now that libstun depends on libgcrypt, we might as well use its SHA1 hash
support, rather than carrying around our own.
Differential Revision: https://phabricator.freedesktop.org/D1612
|
|
|
|
|
|
|
| |
Now that libstun depends on libgcrypt, we might as well use its MD5 hash
support, rather than carrying around our own.
Differential Revision: https://phabricator.freedesktop.org/D1611
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, a custom Mersenne Twister PRNG was used, which is not
securely random. In addition, its seeding fell back to wall-clock time,
which is typically predictable.
This uses libgcrypt on Linux but retains the Windows code which uses the
Windows crypt API.
Differential Revision: https://phabricator.freedesktop.org/D1610
|
|
|
|
|
|
| |
This will shortly be used to implement secure random number generation.
Differential Revision: https://phabricator.freedesktop.org/D1609
|