-
Jakub Adam authored
In priv_process_response_check_for_peer_reflexive(), mere presence of a candidate in local_candidates doesn't mean there's also some candidate pair in conncheck_list using it - for instance that candidate may be server reflexive, for which no check pairs are initially created (see conn_check_add_for_candidate_pair()). If we fail to find corresponding pair upon receiving such candidate's IP in a conncheck response's XOR-MAPPED-ADDRESS attribute, we shall add a new one in a similar way we would add a new pair for a just discovered peer reflexive candidate. Previous priv_process_response_check_for_peer_reflexive() implementation would return NULL, causing a CandidateCheckPair with local candidate of type HOST to be wrongly selected even though the local host IP might not be directly accessible by the remote counterpart (e.g. it's an address on a private network segment). In practice this was coming through as a duplex connection that libnice was reporting as properly established, but only one direction of the communication was actually working. Maniphest Tasks: https://phabricator.freedesktop.org/T115 Differential Revision: https://phabricator.freedesktop.org/D242Reviewed-by:
Philip Withnall <philip.withnall@collabora.co.uk>
02852728