Reqwest: Requests always time out on Windows 10

[CoolOppo]

I tried running the following code with both Rust Stable and Nightly:

#![deny(warnings)]

//! `cargo run --example simple`

extern crate reqwest;

fn main() -> Result<(), Box<std::error::Error>> {

    println!("GET https://www.rust-lang.org");

    let mut res = reqwest::get("https://www.rust-lang.org/en-US/")?;

    println!("Status: {}", res.status());
    println!("Headers:\n{:?}", res.headers());

    // copy the response body directly to stdout
    std::io::copy(&mut res, &mut std::io::stdout())?;

    println!("\n\nDone.");
    Ok(())
}

With either toolchain, I get the following output:

GET https://www.rust-lang.org
Error: Error { kind: Io(Custom { kind: TimedOut, error: StringError("timed out") }), url: Some("https://www.rust-lang.org/en-US/") }
error: process didn't exit successfully: `target\debug\tersttt.exe` (exit code: 1)

[seanmonstar]

What version of reqwest was used?

[Bobo1239]

I seem to have the same problem. I'm using version 0.9.7 and getting timeouts on both nightly-x86_64-pc-windows-msvc and nightly-x86_64-pc-windows-gnu. The same code works on my other Linux machine.

[seanmonstar]

Would you be able to try an http address as well? Just curious if its the DNS or TLS refactor that is bugged.

[Bobo1239]

Seems to be a regression from 0.9.5 to 0.9.6. Setting reqwest = "=0.9.5" in the Cargo.toml fixes the problem. The problem also occurs with a http address.

[CoolOppo]

Also occurs with http addresses for me as well. Using 0.9.7 as well.

[CoolOppo]

Just tested if 0.9.5 works for me and it does (after a cargo clean)!

[seanmonstar]

Would either of you be able to tell me if 0.9.5 works even if its hyper dependency is at 0.12.20?

[Arnavion]

The problem is trust-dns.

INFO C:\Users\Arnavion\.cargo\registry\src\github.com-1ecc6299db9ec823\trust-dns-proto-0.6.1\src\xfer\dns_exchange.rs:122 sending message via: UDP([fec0:0:0:ffff::3]:53)
INFO C:\Users\Arnavion\.cargo\registry\src\github.com-1ecc6299db9ec823\trust-dns-proto-0.6.1\src\xfer\dns_exchange.rs:122 sending message via: UDP([fec0:0:0:ffff::2]:53)
INFO C:\Users\Arnavion\.cargo\registry\src\github.com-1ecc6299db9ec823\trust-dns-proto-0.6.1\src\xfer\dns_exchange.rs:122 sending message via: UDP([fec0:0:0:ffff::1]:53)
INFO C:\Users\Arnavion\.cargo\registry\src\github.com-1ecc6299db9ec823\trust-dns-proto-0.6.1\src\xfer\dns_exchange.rs:122 sending message via: UDP([fec0:0:0:ffff::3]:53)
INFO C:\Users\Arnavion\.cargo\registry\src\github.com-1ecc6299db9ec823\trust-dns-proto-0.6.1\src\xfer\dns_exchange.rs:122 sending message via: UDP([fec0:0:0:ffff::2]:53)
INFO C:\Users\Arnavion\.cargo\registry\src\github.com-1ecc6299db9ec823\trust-dns-proto-0.6.1\src\xfer\dns_exchange.rs:122 sending message via: UDP([fec0:0:0:ffff::1]:53)
Error: https://www.google.com: timed out

This is on Windows 7. I don't have IPv6 on my network.

Relevant crate versions:

• reqwest 0.9.7
• trust-dns-proto 0.6.1
• trust-dns-resolver 0.10.2

[Arnavion]

In https://github.com/bluejekyll/trust-dns/blob/master/crates/resolver/src/system_conf/windows.rs#L22 it enumerates every adapter, even ones that don't make sense. I have VirtualBox which has an adapter for its VMs ("VirtualBox Host-Only Network"), which does have IPv6 enabled, so it ends up picking the resolver for that and trying to use it. Disabling IPv6 on that adapter fixed the problem.

@CoolOppo @Bobo1239 Is it the same for you?

[seanmonstar]

I just put in config to disable trust-dns on Android, we can also add in Windows, and file an issue upstream.

[Bobo1239]

Can confirm that the problem doesn't occur when disabling the other adapters.

[seanmonstar]

So it seems the problem may not happen to everyone, just systems that have a lot of adapters, or adapters that don't work?

Still, it's not difficult to add Windows to the Android conditional configs.

[Arnavion]

Yes, I think disabling it on Windows is a good idea until trust-dns gets a fix. Either it needs to ignore the nameservers from these adapters, or it needs to query them in parallel, or it needs to have a shorter timeout that doesn't elapse before it's tried every nameserver, or whatever.

It's not really about "a lot of adapters" or "adapters that don't work". Having adapters that don't have an internet connection is quite normal. VM software like Hyper-V and VirtualBox, VPN software, etc all add virtual adapters. These adapters work, and getaddrinfo already knows about which adapter's nameservers it's supposed to use. But trust-dns goes behind the OS's back to make its own list of nameservers and gets confused by it.

Especially in the VPN case, I imagine it'll also end up leaking internal domain names over the public internet where gai would've resolved them by the VPN network's DNS server.

[bluejekyll]

There's currently one primary contributor to trust-dns for Windows. If you would care to move this discussion to bluejekyll/trust-dns#605 and help us come up with some potential fixes, that would be greatly appreciated.

[seanmonstar]

If you would care to move this discussion to bluejekyll/trust-dns#605 and help us come up with some potential fixes, that would be greatly appreciated.

:+1:

@bluejekyll I'm not trying to complain, just trying to identify when reqwest might be failing some people, and the fastest way for me bandage it :) Thanks for your hard work on trust-dns!

[Arnavion]

(I should also note that gai has an async version on Windows 8+, GetAddrInfoEx, though of course it should probably be wrapped in a lower-level crate rather than called by reqwest directly.)