-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(iroh-net): Ensure netcheck finishes once it has results #2027
Conversation
Once netcheck has managed to establish an external IP address there is no need to further wait on the portmapper. The results are already useful. If later the portmapper manages to get something done the magicsock will react to that and make use of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
code looks good, what impact have you seen in testing?
/// This is set to true in tests to avoid probing the local LAN's router etc. | ||
/// | ||
/// TODO: currently this only skips the portmapper, but still does STUN, HTTP and ICMP | ||
/// probes. Furthermore none of our tests actually use this feature. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
honestly, just delete it, we can bring it back if we ever need to
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, fair enough. i'll do that in a separate PR though.
Pinging @divagant-martian to check my understanding of the portmapper is correct. I think what happens is that on the very first netcheck the portmapper has not yet run to completion and that slows down the first netcheck, often only to not get a portmapper result anyway. Later on there are cached reports that are returned. As all this is reporting is a bunch of bools in an option I think it's fine to not wait for this the first time. |
Testing it is pretty hard, things still seem to work though. And I'm pretty sure this is the path that failed when looking at the logs where the problem was reported. |
@divagant-martian I'm going to interpret the thumbs-up as approval. Can always revert if that was wrong. |
## Description We were incorrectly identifying globally routable IPv6 addresses as not routable. This make netcheck skip IPv6 addresses. ## Notes & open questions Closes #2022 The fix in the netcheck, test is curious, it fails on this PR fairly consistently yet it is really a flaky test introduced in combination with #2027. Now that we have IPv6 resolving properly we might get an IPv6 result. Since this test only has a single DerpUrl it only needs one result to complete. This could be an IPv4 OR an IPv6 result, we don't know which one will be faster. And if the other is slow enough then it won't be received. I think this behaviour is fine, we simply can't guarantee that both must have a result and the point of netcheck is to return something working quickly. ## Change checklist - [x] Self-review. - [x] Documentation updates if relevant. - [x] Tests if relevant.
…ter#2027) ## Description Once netcheck has managed to establish an external IP address there is no need to further wait on the portmapper. The results are already useful. If later the portmapper manages to get something done the magicsock will react to that and make use of it. ## Notes & open questions Fixes n0-computer#2021 ## Change checklist - [x] Self-review. - [x] Documentation updates if relevant. - [x] Tests if relevant.
…computer#2030) ## Description We were incorrectly identifying globally routable IPv6 addresses as not routable. This make netcheck skip IPv6 addresses. ## Notes & open questions Closes n0-computer#2022 The fix in the netcheck, test is curious, it fails on this PR fairly consistently yet it is really a flaky test introduced in combination with n0-computer#2027. Now that we have IPv6 resolving properly we might get an IPv6 result. Since this test only has a single DerpUrl it only needs one result to complete. This could be an IPv4 OR an IPv6 result, we don't know which one will be faster. And if the other is slow enough then it won't be received. I think this behaviour is fine, we simply can't guarantee that both must have a result and the point of netcheck is to return something working quickly. ## Change checklist - [x] Self-review. - [x] Documentation updates if relevant. - [x] Tests if relevant.
Description
Once netcheck has managed to establish an external IP address there is
no need to further wait on the portmapper. The results are already
useful. If later the portmapper manages to get something done the
magicsock will react to that and make use of it.
Notes & open questions
Fixes #2021
Change checklist