-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Unable to get packages from source #1258
Comments
Can you run |
|
Uhh, when the build fails there's a blocked connection
Why crates.io connecting via inbound but when git it's okay with just outbound? |
That is... quite surprising! I would not expect libcurl to start accepting connections at all. |
Are you using a firewall locally? (something I could try to reproduce with). |
Tinywall, http://tinywall.pados.hu/ |
Are you sure the firewall wasn't accidentally blocking cargo itself? |
It was fine on github links (only outbound). It's not on crates.io because it was requesting an inbound access (why?). |
How did you determine that was an inbound access? I couldn't find the relevant logs in tinywall |
Right click TinyWall at taskbar, Change mode to Normal protection (you'll lose internet access so revert it later). Add cargo.exe to application exceptions with radio button set to allow only specified ports and put 443 at Out TCP (for github and should be for crates.io too but no) click OK then right click again TinyWall at taskbar pick Show connections then untick Show active connections and tick Show blocked apps. Do cargo build --version then click Refresh to see crates.io wants to do an inbound (it's 443 at Source port and a crates.io ip at Local/Source address column, destination columns is self explanatory). |
Thanks for the details! I believe I was able to configure everything correctly. My local build, however, completed just fine (after downloading a bunch of packages). I did, however, see some blocked incoming connections (they say they're from I'm really not quite sure why this is happening, maybe it's some new fancy HTTP/2 thing implemented in libcurl? I'm surprised that it's outright failing for you when it succeeds for me... |
Is the piston crate the one you tested? |
|
Which piston crate are you building? |
I sometimes run into this issue when Cargo downloads packages from crates.io. It is always a fleeting occurrence and I can never get it to reliably occur. Usually just trying again gets things to pass. It would be really nice if Cargo could at least retry the download a couple times if it failed. That way for people who just have intermittent issues, this problem would be mitigated. |
I think that this was probably just intermittent, so I'm going to close this in favor of #1602 |
Cargo version.
Error output from cargo build --verbose.
Output of command ipconfig /displaydns after flushing it and run the above command.
Excerpt at Cargo.toml file.
I'm not behind a proxy.
Other packages like clock_ticks downloaded fine. That (bitflags) and rustc-serialize don't.
The text was updated successfully, but these errors were encountered: