| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Uses a wrap file to download a prebuilt OpenSSL from our git as a
subproject.
Builds for both amd64 & x86
|
|
|
|
| |
It crashes on Windows
|
| |
|
| |
|
|
|
|
|
| |
This makes it work with Windows MSVC builds of OpenSSL which
don't include a pkg-config file.
|
|
|
|
|
|
|
|
|
| |
For now it uses the gstreamer docker image and shared runner, based
on windows server 1607. The runner will migrate to windows 1807
soonish hopefully.
This commit also adds a glib wrap file needed to build
libnice.
|
|
|
|
| |
Shell scripts don't work well on Windows and Python doesn't work with valgrind.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It's most likely caused by a retransmission received after the initial
request already had a reply.
|
|
|
|
| |
The child now calls into the parent..
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When evaluating the stopping criterion, failed pairs from other streams
having the "use_candidate_on_next_check" flag set should be
ignored.
This should normally not happen, because a pair selected for nomination
has no reason to fail when being rechecked, since it previously
worked... but it may happen with Skype for Business, when libnice
selects a tcp pair for component 1, the peer seems to have no interest
in the second component and lets it fail in the middle of the conncheck.
|
|
|
|
|
| |
This patch doesn't change the logic of the selection of the pair for
nomination, it makes the code a bit more simple to read.
|
|
|
|
|
|
|
|
| |
A previous commit c1fb6f2 introduced a regression in the way the
foundation of a selected pair is updated and signaled, when the
foundation of its remote candidate changes. The previous comparison was
made on *always* identical strings, so the update of the selected pair
was *never* signaled.
|
|
|
|
|
|
| |
We may not have received remote candidates yet, but we may have
discovered remote candidates from the early incoming checks. Only
having stream credentials is required to react to these checks.
|
|
|
|
|
| |
The IPv6 struct sockaddr variant is bigger than the IPv4 one,
so use the storage struct to ensure that the size is big enough.
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the initial attempt at sending discovery message returns a socket
error, don't start the retransmit timer and immediately mark such
discovery item as done. This is to quickly eliminate clearly
non-functioning items from the discovery process.
Particularly improves times to finish discovery on Windows, where
sending data from a link-local (169.254.0.0/16) IP to a destination not
on the same subnet leads to "A socket operation was attempted to an
unreachable network" error. Pointless retransmissions on those sockets
prolonged discovery in the order of seconds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The nomination of a pair having such a local candidate breaks SfB when
the libnice agent is behind a nat that does not do port mapping
randomization. In that case a server reflexive local candidate usually
lead to a nominated pair.
The guess made here from observing this behavior is that, it is valid to
discover and signal these local server reflexive candidates to our peer,
but they should be removed from our local candidates list thereafter, so
they do not contribute to build a valid and *even worse* a nominated
pair with the type server-reflexive. They do not appear in the conncheck
list per design anyway.
Instead, the same candidate is discovered again later during the
conncheck, with a peer-reflexive type this time, and with that type, it
just works.
Closes #90
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some rare cases, the same address and port number may match two
remotes candidates, a tcp and an udp one, and lead to buggy pair
construction with incompatible transport. This supplementary check
prevents this problem. The matching test is not aimed to be exhaustive
but just a way to discard obviously broken associations, and fallback to
accept everything else (because socket type has a great diversity, with
socket types based on other sockets types).
It should fix #81, where such bogus transport association has been
reported (tcp-pass:udp).
|
|
|
|
|
| |
Once an interface got ignored, ALL interfaces coming after it were
dropped too.
|
|
|
| |
Fixes MSVC build.
|
|
|
|
| |
Since g_parse_debug_string() was looking only at the first 4 items in
GDebugKey arrays, "libnice-verbose" couldn't get activated.
|
| |
|
|
|
|
|
| |
We support turn-tcp in oc2007 compatibility only and when the
host candidate transport is compatible, ie when reliable_tcp is true.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When receiving an stun packet on a socket, and looking for the matching
local candidate, normally it doesn't make a difference to test the
address or the base address. Because a pair cannot have a local candidate
of type srv-rflx, where there would be a difference, the local candidate
obtained will be part of a pair of the conncheck list.
Except for the case of a pairs with tcp-act local candidate, where the
addr has a port number of zero (tcp-act socket before connect), and the
socket of the stun packet has a non-null port number (tcp-act socket
after connect), corresponding to the base address of another
peer-reflexive tcp-act local candidate, previously discoverd.
The selection of the local candidate concerned by an inbound stun
request happens when early incoming checks are processed, and when
inbound stun packets are normally received during the conncheck.
This commit complete commit e6a1941 (for early incoming checks)
in the normal inbound stun packets code path, where is similar
modification is needed.
|
|
|
|
|
| |
This patch rewrites the comment surrounding this code snippet, to make it
clear, that this pair selection is not specific to the tcp transport.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current valid pair nomination makes no effort to select pairs that
could have some similarities across different components and different
streams. This is normally not required by the RFC8445, but some well
known applications will misbehave when the libnice agent is in this
position to choose the nominated pairs (regular nomination mode, and
controlling mode) and if it makes an unexpected choice from the peer
point-of-view.
This patch improves the stopping criterion and the selection of the
preferred pair to nominate in that case.
When no other pair has been nominated yet (across all streams), the
previous stopping criterion still applies, and the best ranked pair of
the checklist is selected.
When a nominated pair exists from another component, we try to nominate
a pair of the same kind (same local and remote addresses and same
transport) if we have one, and possibly the best pair we have in the
checklist, and else we look for a nominated pair from another stream.
|
| |
|
| |
|
| |
|
|
|
|
| |
The source is also detached in socket_source_free()
|
|
|
|
|
|
|
|
|
|
| |
This final idle timeout is renamed from the
NICE_AGENT_MAX_TIMER_GRACE_PERIOD macro, and keeps its semantic.
We also increase the default value of this timeout from 1 second to 5
seconds. This is useful for the sipe pidgin plugin that has to deal
with SfB agents, that may take some time in controlling mode before
choosing and testing the nominated pair
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the priority assigned to a peer reflexive discovered
local candidate, when the agent has the stun client role and receives an
stun reply. This priority must be the value put in the stun request, ie
the pair->rflx_priority from the parent pair. This ensures two similar
ordered pairs, will generate discovered pairs ordered in the same way
for the stun client, and also for the stun server on the other side.
Without this identical ordered on both sides of the connections, the two
agents may nominate a different pair with the aggresive nomination
scenario, since both are valid.
The other fix concerns the function that ensures local candidates
priority uniqueness, that breaks the assumption that "two local
candidates having the same priority should generate the same
prflx_priority in the pairs they contribute". Respecting this assumption
is important to stay coherent with the behavior of the other agent, that
considers that two stun requests coming from the same peer-reflexive
remote candidate will have the same remote priority (once a remote
candidate is added to the component remote_candidates list, its priority
is not supposed to change).
|
|
|
|
|
|
| |
When replaying the incoming checks, we have to create the succeeded
valid pair matching this tcp connection the same way we do it
in conn_check_handle_inbound_stun().
|
|
|
|
|
|
|
|
| |
These candidates type is updated from peer-reflexive, discovered during
early incoming checks, to the type of the matching regularly transmitted
candidate, so the previous sockptr value is no longer of interest here.
The same socket is already associated to the initial local candidate
anyway, source of the early discovery.
|
|
|
|
|
|
|
|
|
|
|
| |
A socket to be removed may also come from a peer-reflexive remote
candidate, and some cleanup also needs to be done in this case. This
reference in a remote peer-reflexive tcp-active candidate caused a
heap-use-after-free asan error in some custom debugging dump of the list
of sockets of a component, after a read error in component_io_cb():
agent_recv_message_unlocked returned -1, errno (25) :
Inappropriate ioctl for device
|