Reflexive connectivity test times out

[KaptenJansson]

I've not had a chance to debug this yet but if you @jessetane have an idea please take a look.

[jessetane]

So, on my home network (cheap netgear wifi router with a public ip doing stock nat) it works fine, however when I tether my laptop through my phone (AT&T LTE, at least 2 levels of nat) reflexive times out for me as well. That particular scenario has never worked for me without a relay though so it does not come as a surprise. What does your network setup look like?

[KaptenJansson]

Ow, my comment never made it (I did not hit enter before I left the office it seems:().

I wrote exactly what you wrote, our corp network is behind several NAT's hence it times out, @andresusanopinto kindly pointed this out.

We do suggest however that instead of reportFatal we should do reportWarning as this is expected lots of networks (corp, mobile etc). I think that applies to the Host candidate test as well, that will not always succeed either. Basically they are informative tests, not "something is wrong with your system" kind of test.

Then we could also change the warning text to "Failed to gather HOST/Server Reflexive Candidates" rather than just displaying "Timed out".

WDYT?

[jessetane]

Got it. First, is there a common scenario when host connectivity would fail? That's the exact issue that led me here in the first place, and it seems important to me that that scenario would always work. Very interested to know if I'm missing anything with that assumption!

I agree it might be nice to lower the severity level of the failure, but reportWarning still shows the green check next to the failed test for me. I see the suite turns yellowish, but the only way to see which test failed is to open each of them up and read the log, which is sort of annoying.

Also, the connectivity tests are sort of an awkward case - as long as one of the scenarios works, things might be ok, but if all of them time out, something is definitely wrong and the whole suite should fail.

[jessetane]

One other thing: I'm fairly sure host and reflexive candidates are almost always gathered, even when their respective connectivity tests fail. The failure is most frequently due to unknown configuration or topology problems on the network, so in those situations I'm not sure what else we could log other than basically "it didn't work".

[KaptenJansson]

I increased the timeout in #130, lets see if that reduces some of throughput and connectivity test "Timed out" failures.

[KaptenJansson]

Also, I'm not sure but I suspect that when creating a peerconnection with a turn server address ( turn:turn:xx.x.x.x.x) the turn server does not provide server reflexive candidates or even the browser filters them out? Will have to do some testing.

WRT to reportWarning() should in my opinion fail but suite turn yellow. And yes it is tricky as it's environment dependent, which we cannot detect hence we got nothing to compare with to determine if the test result is valid for the particular environment. Tricky ;)

[KaptenJansson]

Ow I missed the fact that the reflexive test ofc uses STUN, nvm my comment about TURN + reflexive candidates ;)

[KaptenJansson]

So maybe we should add a warning that reflexive candidates have been gathered successfully (verifies that the browser has been able to contact the stun server and it has provided candidates) but failed to establish a connection, most likely due to some exotic network config.

Maybe better to consolidate the tests and evaluate the results from all three collectively?

[jessetane]

Also worth bringing up here is the IPv6 test which is a similar situation (fails for most people, but does not necessarily break anything).

[KaptenJansson]

Yes indeed, this is due to having only two conditions, error and success (and warning but marked as success still). I'm working on adding a proper warning method/state.

[KaptenJansson]

Fixed in #130