test failure: net::tcp::tests::connect_timeout_unroutable

[RalfJung]

When I run ./x.py test -i src/libstd, I reliably get a test failure

---- net::tcp::tests::connect_timeout_unroutable stdout ----
        thread 'net::tcp::tests::connect_timeout_unroutable' panicked at 'called `Result::unwrap_err()` on an `Ok` value: TcpStream { addr: V4(139.19.184.5:41902), fd: 13 }', src/libcore/result.rs:906:4


failures:
    net::tcp::tests::connect_timeout_unroutable

test result: FAILED. 803 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--lib'


command did not execute successfully: "/home/r/src/rust/rustc/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-j" "8" "--release" "--features" "panic-unwind debug-jemalloc jemalloc backtrace" "--manifest-path" "/home/r/src/rust/rustc/src/libstd/Cargo.toml" "-p" "std" "--"
expected success, got: exit code: 101

It seems my box (Linux, Debian testing amd64) considers 10.255.255.1 a fine address to route to.

This is the only test that fails.

[sfackler]

Uh oh. We may have to give up on the test unless someone knows of a "truly" unrouteable IP.

[achanda]

An IP in the documentation range should work fine. Example: https://play.rust-lang.org/?gist=5e00e5f8e9b46a4b5969f2eb72601a76&version=nightly

[RalfJung]

It turns out that I can only reproduce this problem when I am connected to my institute's network; at home, the test passes.

Changing the test to use 192.0.2.2 makes no difference, it still fails.

[sapphire-arches]

I'm also a +1 on this issue, my apartment's ISP is shady and will route things in 10.255.255.0/8. The documentation range works as expected, so it may be worth at least changing the test to use e.g. 192.0.2.2. The test has some utility so I would feel bad recommending it just be removed, but perhaps disabling it on non-CI builds by default could be worthwhile?

[RalfJung]

I talked to our network admins and now have an explanation for the behavior described above: It seems that the firewall I am behind actively blocks traffic to/from reserved ranges, including the RFC 5737 documentation range. For TCP connections, "blocking" involves sending an RST, so my client gets ECONNREFUSED instead of a timeout.