1226838 - Improve CandPairingFilter ice unit tests

Status: NEW

(Core :: WebRTC: Networking, defect, P4)

Description

[Nils Ohlmeier [:drno]]

The two *CandPairingFilter tests in ice_unittest from bug 1219557 don't support:
- running on hosts with multiple private IPv4 addresses
- running on hosts with only public IPv4 addresses
- running on hosts with IPv6 addresses only

Comment 1

[simplyblue24]

Hi, would like to work on this bug, please assign it to me, can you also provide more info.Thank you :)

Comment 2

[Nils Ohlmeier [:drno]]

So the problem is this: in bug 1219557 I landed code which prevents IP addresses from different private IP address ranges to get paired, because it is highly unlikely that a pair with e.g. 10.0.0.1 and 192.168.0.1 will ever succeed.

The new tests in ice_unittest basically gather the host candidates and then try to find out the private IP address range in use on that machine, e.g. 192.168.x.x. Then the test adds a remote ICE candidate from a different IP address range.

Now these new tests are suppose to work if these tests get executed on a machine with exactly one private IPv4 address available.

So if a developer executes the ice_unittest on a machine with:
A) multiple interfaces with IP from different IP address ranges
B) the network interface(s) only have public IPv4 addresses
C) the network interface(s) have only IPv6 addresses
these tests will fail with an error message.

For A) we would need to check if at least one private IP subnet is NOT in use on the current machine and add a fake ICE candidate from that unused private subnet. For that you would need to first determine the list of IP nets in use. Then determine the list of unused IP nets. And then let the tests add an IP from the list of unused IP nets.
If the list of unused IP nets is empty/zero I'm fine with still letting the test fail.

For B) and C) I guess we would need to find a way to inject locally host candidates from an private IP subnet. Not sure if that is actually feasible. Byron, any idea if that is somehow possible?

Now :mjf just pointed out to me that the TestSrflxCandPairingFilter test is actually broken. On machine with a single IPv4 private IP address and with access to the public Internet and DNS this test should pass. But because the test first filters the local candidates to Server Reflexive like this:
  SetCandidateFilter(IsSrflxCandidate);
but then the function GetCandidatesPrivateIpv4Range() later searches only for host candidates like this:
  if (c.find("typ host") != std::string::npos) {
the TestSrflxCandPairingFilter always fails, because it believes there is no single private IPv4 host address. This should be fixed as well.

Let me know if you have further questions :-)

Comment 3

[Byron Campen [:bwc]]

Nils pretty much covered it. Let us know if you have any more questions.

Comment 4

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.

Comment 5

[Ho Cheung]

Attachment: WIP: Bug 1226838 - Fix TestSrflxCandPairingFilter and improve network scenario handling

• Fixed TestSrflxCandPairingFilter bug where it filtered to srflx
  candidates but searched for private IP ranges in host candidates
  instead of raddr.

• Added GetCandidatesPrivateIpv4RangeFromRaddr() to extract private
  ranges from srflx/relay candidates' related addresses.

• Implemented comprehensive multiple private interface support:

GetAllCandidatesPrivateIpv4Ranges() for detecting all private ranges.

GetAllPrivateInterfaceInfo() for detailed interface information.

HasMultiplePrivateInterfaces() and GetPrimaryPrivateIpv4Range() helpers.

• Enhanced tests to handle multiple network scenarios:

Multiple private IPv4 addresses from different RFC1918 ranges.

Public IPv4 addresses only.

IPv6 addresses only.

Mixed network configurations.

• Added TestMultiplePrivateInterfaces for comprehensive test coverage.