Skip to content
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

Closed
SUNKIST-EDEN opened this issue Feb 1, 2015 · 16 comments
Closed

Unable to get packages from source #1258

SUNKIST-EDEN opened this issue Feb 1, 2015 · 16 comments

Comments

@SUNKIST-EDEN
Copy link

Cargo version.

cargo 0.0.1-pre-nightly (2b9a3d6 2015-01-30 02:47:30 +0000)

Error output from cargo build --verbose.

 Downloading bitflags v0.1.0
Unable to get packages from source

Caused by:
  Failed to download package `bitflags v0.1.0` from https://crates.io/api/v1/crates/bitflags/0.1.0/download

Caused by:
  SSL connect error

Output of command ipconfig /displaydns after flushing it and run the above command.

Windows IP Configuration

    crates.io
    ----------------------------------------
    Record Name . . . . . : crates.io
    Record Type . . . . . : 1
    Time To Live  . . . . : 216
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 23.23.121.177


    Record Name . . . . . : crates.io
    Record Type . . . . . : 1
    Time To Live  . . . . : 216
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 54.243.209.93


    Record Name . . . . . : crates.io
    Record Type . . . . . : 1
    Time To Live  . . . . : 216
    Data Length . . . . . : 4
    Section . . . . . . . : Answer
    A (Host) Record . . . : 54.225.123.15

Excerpt at Cargo.toml file.

[[package]]
name = "bitflags"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"

I'm not behind a proxy.
Other packages like clock_ticks downloaded fine. That (bitflags) and rustc-serialize don't.

@alexcrichton
Copy link
Member

Can you run curl -OL https://crates.io/api/v1/crates/bitflags/0.1.0/download and paste what it outputs?

@SUNKIST-EDEN
Copy link
Author

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
100  8667  100  8667    0     0   3779      0  0:00:02  0:00:02 --:--:-- 18519

@SUNKIST-EDEN
Copy link
Author

Uhh, when the build fails there's a blocked connection

INBOUND ip_here_from_crates_io port 443 to local_ip registered_ports(1024 through 49151)

Why crates.io connecting via inbound but when git it's okay with just outbound?

@alexcrichton
Copy link
Member

That is... quite surprising! I would not expect libcurl to start accepting connections at all.

@alexcrichton
Copy link
Member

Are you using a firewall locally? (something I could try to reproduce with).

@SUNKIST-EDEN
Copy link
Author

Tinywall, http://tinywall.pados.hu/

@alexcrichton
Copy link
Member

Are you sure the firewall wasn't accidentally blocking cargo itself?

@SUNKIST-EDEN
Copy link
Author

It was fine on github links (only outbound). It's not on crates.io because it was requesting an inbound access (why?).

@alexcrichton
Copy link
Member

How did you determine that was an inbound access? I couldn't find the relevant logs in tinywall

@SUNKIST-EDEN
Copy link
Author

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).

@alexcrichton
Copy link
Member

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 System(0)...).

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...

@SUNKIST-EDEN
Copy link
Author

Is the piston crate the one you tested?

@SUNKIST-EDEN
Copy link
Author

>cargo build --verbose
    Updating git repository `https://github.com/PistonDevelopers/piston.git`
    Updating git repository `https://github.com/pistondevelopers/input`
    Updating git repository `https://github.com/pistondevelopers/event`
    Updating git repository `https://github.com/pistondevelopers/quack`
    Updating git repository `https://github.com/pistondevelopers/window`
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `https://github.com/PistonDevelopers/event_loop`
    Updating git repository `https://github.com/tomaka/clock_ticks`
 Downloading bitflags v0.1.0
Unable to get packages from source

Caused by:
  Failed to download package `bitflags v0.1.0` from https://crates.io/api/v1/cra
tes/bitflags/0.1.0/download

Caused by:
  SSL connect error

@alexcrichton
Copy link
Member

Which piston crate are you building?

@retep998
Copy link
Member

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.

bombless added a commit to bombless/cargo that referenced this issue Feb 15, 2015
@alexcrichton
Copy link
Member

I think that this was probably just intermittent, so I'm going to close this in favor of #1602

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants