Conversation
|
Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3986/docs/iroh/ Last updated: 2026-04-02T08:16:34Z |
83bcb4e to
c8f6e3e
Compare
|
✅ patchbay: success | results |
| Ok(()) | ||
| } | ||
|
|
||
| // --- |
There was a problem hiding this comment.
this is becoming a long file, maybe split it up into multiple test files?
There was a problem hiding this comment.
Removed several tests and moved them to #4065 (still a draft) so let's do this once we add those back.
Why the need to install a tool, can you not write a self-contained html file into the testdir? |
iroh/tests/patchbay.rs
Outdated
| .run( | ||
| async move |_dev, _ep, conn| { | ||
| let mut paths = conn.paths(); | ||
| assert!(paths.is_relay(), "connection started relayed"); |
There was a problem hiding this comment.
Why is this not flaky? This checks to see whether the selected path is a relay path, but this test does not itself control when holepunching starts so I would expect this to be flaky. If the runtime manages to delay this task enough then iroh could already have holepunched.
There was a problem hiding this comment.
Right, this could be flaky if the runtime stalls this longer than at least one RTT. I've never seen it flake though. Should we leave it in until it flakes? So far it served me as a useful assert that the connection didn't start on IP, because if it did, a check for holepunching would be worthless.
|
The command in the PR description needs to be updated: The tests are now called |
This command from the PR description needs updating: It's called |
|
I removed the "Publish to patchbay server" part for now. We don't want to hold this up on deploying the service, and the utility is debatable because we can just rerun locally if it fails. So from my side this is ready for merge now. We can always iterate and add more tests later. |
iroh/tests/patchbay.rs
Outdated
| /// Both peers behind FullCone NAT (EIM+EIF with hairpin). The most permissive | ||
| /// NAT type — any external host can send to the mapped port. Holepunching | ||
| /// always succeeds on the first try. |
There was a problem hiding this comment.
And then this repeats the claim, but this time about FullCone NAT?
There was a problem hiding this comment.
This test is among the ones I removed for the inital merge. I will review the tests and docs more and mark #4065 as ready for review once one.
iroh/tests/patchbay.rs
Outdated
| info!("holepunched, now killing link for 2s"); | ||
|
|
||
| // Take the link down. | ||
| dev.link_down("eth0").await?; | ||
| tokio::time::sleep(Duration::from_secs(2)).await; | ||
| dev.link_up("eth0").await?; | ||
| info!("link restored, waiting for recovery"); |
There was a problem hiding this comment.
Might be interesting to increase the time the link is down here - perhaps on the order of 15s or so - so that it's above the path idle timeout.
But I'm just musing. This is great already - we can add tests later.
There was a problem hiding this comment.
Changed to 5s. Can adapt further if needed, or we add more tests with that.
iroh/tests/patchbay.rs
Outdated
| /// Hotel WiFi: captive-portal firewall allows all outbound TCP but only UDP | ||
| /// port 53 (DNS). Similar to corporate firewall but less restrictive on TCP. | ||
| /// Relay via HTTPS should work, holepunching should not. |
There was a problem hiding this comment.
Looking at the differences between RouterPreset::Hotel and RouterPreset::Corporate, the main difference seems to be that the hotel one is IPv4-only, whereas corporate is IPv4 + IPv6, and corporate only allows port 80/443, whereas the hotel one allows any port.
Tbqh, I don't think any of these things make much of a difference in terms of testing for iroh. In most cases I'd expect these tests to either both fail or none of them to fail, except maybe for some edge cases regarding IPv6.
Regardless, perhaps it's worth either adding more information to the test description, or linking the docs via something like "See also [RouterPreset::Hotel] and [RouterPreset::Corporate] for differences".
There was a problem hiding this comment.
👍 This test is among the ones I removed for the inital merge. I will review the tests and docs more and mark #4065 as ready for review once one.
flub
left a comment
There was a problem hiding this comment.
there are too many tests to review, i'm not sure how to tackle that. e.g. i can't say whether the way they are written makes sense, whether any failure would be because of the test, patchpay or iroh.
So I've only looked at the first few so far.
iroh/tests/patchbay.rs
Outdated
| #[tokio::test] | ||
| #[traced_test] | ||
| #[ignore = "stays relayed, holepunch times out (deadline elapsed)"] | ||
| async fn holepunch_home_nat_one_side() -> Result { |
There was a problem hiding this comment.
it is strange this doens't work. what mechanism did we figure to address these ignored tests?
There was a problem hiding this comment.
No clear mechanism yet. First step: Let's run them locally with --ignored and if someone has an ignored one passing, then do a PR to remove the ignore line and we see what CI says.
|
Oh, another thing I found was that investigating any failure requires me to set RUST_LOG=trace. Why not enable that by default for the logfiles created? It uses some more disk space, but I don't think that's a big deal. Any other downside? |
I could just remove some, and do another PR then to add more. Let me do that tomorrow. |
- make it more obvious who is client and who is server - drop endpoint dead on the floor after both run functions completed
|
I moved a number of tests to #4065 to make it easier to review this PR. |
flub
left a comment
There was a problem hiding this comment.
Thanks, some nice improvements still.
I still didn't review the actual tests, but I think that's fine. They'll probably evolve anyway.
Description
Adds a first round of tests using our new network simulation framework, patchbay. Patchbay uses Linux network namespaces to create isolated network topologies with routers, NATs, and link impairment. This lets us test actual holepunching and NAT traversal in realistic conditions, without needing any external infrastructure.
The test suite covers establishing a direct path in different scenarios:
Some tests that iroh doesn't pass yet are included but marked
#[ignore]. They should be un-ignored as we improve things.Running the tests
On Linux, things just work with user namespace support:
Test output is saved in
./target/testdir-current/patchbay/<test-name>. Patchbay currently collects tracing logs for each device, qlog files (if the feature is enabled), and endpoint metrics.There's also a browser UI for viewing timelines, topologies, and logs. The UI can also be used to compare different test runs.
On macOS you'll need to run the patchbay tests in a VM or container. The
patchbayCLI includes a tool to set up a container or QEMU VM for this.See the patchbay docs and README for more details.
Notes and open questions
There's a draft PR with some more tests: #4065, but they need more thought and work to really cover what we want to test.
Breaking Changes
None.
Change checklist