You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
WSL2 seems to have issues with ipv6. Restricting namespace resolution to ipv4 seems like a bad but easy solution for people.
Solution you'd like
Use only ipv4 for sh.rustup.rs
Notes
I understand that this is not a solution to anything, but considering that I only found out that wsl2 doesn't support ipv6 via this installation script might mean that it is better for sh.rustup.rs to resolve only ipv4 addresses
The actual solution for me was this stack overflow post https://askubuntu.com/a/239276 (I couldn't get the wsl2 solutions posted on the wsl repository to work)
I think there are probably a lot of people using rustup in WSL 2 and we haven't seen a lot of reports like yours. I don't think restricting rustup to IPv4 only based on a small minority of users (that might have other environmental issues) is the right direction. rustup is maintained by volunteers, please be constructive in your feedback.
Yes it could be a simple "fix". However just as there are IPv4-only situations, there could also users which only have IPv6. Should site became IPv4 only, it would be those users here to complaint. You are probably wrong here and I won't call it a fix since it breaks for others.
You could suggest adding a IPv4/IPv6 switch, or even PR one. You could also limit IP resolving on your WSL instance or elsewhere, using dnsproxy or other kinds of proxies. Staring your own reverse proxy is also a choice, since rustup endpoints can be customised via environment variables.
And a few issue reports is not sufficient as the evidence that WSL fails on dual-stack sites. You're not providing your side of situation either. At least in another issue reporting 10054 errors on Win 11 Enterprise they tested both IPv4 and IPv6 of rust-lang.org's CDN on both faslty and AWS, and limiting the issue to IPv6 with Cloudfront.
And even it is, like I said, rustup.rs or any other sites shouldn't drop IPv6 since it would break else where and it really is a Microsoft issue.
Activity
[-]`sh.rustup.rs` should only serve ipv4[/-][+]`sh.rustup.rs` should only resolve to ipv4[/+]rami3l commentedon Apr 29, 2024
@nopeless Thanks a lot for filing this issue! It looks like a duplicate of #3791.
It would be very unreasonable to make our website IPv4-only just for your use case, but for the moment being:
#3791 (comment)
cc @rust-lang/infra
nopeless commentedon Apr 29, 2024
The installer internally uses curl as well. There is no way I can put a flag on that
@rami3l
kLiHz commentedon May 6, 2024
@nopeless What's your issue exactly like?
curling:https://sh.rustup.rshttps://static.rust-lang.org/https://cloudfront-static.rust-lang.org/https://faslty-static.rust-lang.org/all succeeded on my WSL 2.
WSL 2 may had broken IPv6 support, but OS and curl won't be silly enough to stick on IPv6.
And after all it's a Microsoft issue so it's not reasonable for others to clean up the mess for it.
By the way Microsoft rolled out IPv6 support in their Insider Program, try it out if you'd like.
nopeless commentedon May 6, 2024
can you curl -6?
nopeless commentedon May 6, 2024
im ngl idk what im even doing wrong here
all i said is that wsl has these issues and its a rather simple fix from whoever manages rustup to use ipv4 only
and the response is "works on my machine" and *its a microsoft issue so we won't deal with it"
sorry
djc commentedon May 6, 2024
I think there are probably a lot of people using rustup in WSL 2 and we haven't seen a lot of reports like yours. I don't think restricting rustup to IPv4 only based on a small minority of users (that might have other environmental issues) is the right direction. rustup is maintained by volunteers, please be constructive in your feedback.
kLiHz commentedon May 7, 2024
Yes it could be a simple "fix". However just as there are IPv4-only situations, there could also users which only have IPv6. Should site became IPv4 only, it would be those users here to complaint. You are probably wrong here and I won't call it a fix since it breaks for others.
You could suggest adding a IPv4/IPv6 switch, or even PR one. You could also limit IP resolving on your WSL instance or elsewhere, using
dnsproxyor other kinds of proxies. Staring your own reverse proxy is also a choice, since rustup endpoints can be customised via environment variables.And a few issue reports is not sufficient as the evidence that WSL fails on dual-stack sites. You're not providing your side of situation either. At least in another issue reporting 10054 errors on Win 11 Enterprise they tested both IPv4 and IPv6 of rust-lang.org's CDN on both faslty and AWS, and limiting the issue to IPv6 with Cloudfront.
And even it is, like I said, rustup.rs or any other sites shouldn't drop IPv6 since it would break else where and it really is a Microsoft issue.