-
Notifications
You must be signed in to change notification settings - Fork 135
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
S32-io/IO-Socket-Async.t incorrectly fails when IPv6 is disabled on a host #684
Comments
Roast currently assumes that both IPv4 and IPv6 loopback interfaces exist, which is not ideal. If we had a way of working with networking interfaces, then we could determine whether or not any With the solution for Raku/problem-solving#111 I'm working on, there would exist resolver interfaces. Whether or not IPv6 addresses can be resolved when it isn't supported by a system is backend-dependent behaviour though. |
I hope that backend-specific issues we'd be able to resolve using conditionals. Otherwise you confirm the conclusions I made after investigating the matter. Looking forward for your success on the problems-solving issue! |
I wonder how much of an issue this is? Systems without v6 should become rarer and rarer. How many of those will want to run roast?
OTOH this has been reported, so it is at least one...
--
Stefan
|
Actually pretty common. There were at least two different occasions in the last few years I had to disable ipv6 on my machines because things were misbehaving. I have little reason to change it back given that the connection I have doesn't support ipv6 anyway. Although, the test is passing for me so I guess I reinstalled the system during that time, so locally it is enabled again. |
This will be fixable with my solution for https://github.com/Raku/problem-solving/111. PR will be up soon-ish. |
When IPv6 is system-wide off on a Linux host then the test fails with:
Unfortunately, a quick look into the issue did not reveal a concise and accurate way to resolve it:
X::AdHoc
::1
and test for outcomeThe latter is especially surprising to me. I'd expect some basic resolving functionality be provided by the core.
The text was updated successfully, but these errors were encountered: