I recently had an issue where my IPv6 connection was not working (ping google.com resolved to an IPv6 address and failed to get a response), but IPv4 was working (ping -4 google.com got responses). I was able to use Firefox without noticing any issues, but my racket programs had failed with timeout errors. Is there perhaps a way to either force racket to use IPv4 or try to set a fallback mechanism to use IPv4 in case of IPv6 connection failures? So far, this situation seems very rare for my internet connectivity.
I recently ran into this issue again. I am currently in an IPv6 outage and my solution has been to disable IPv6 on my Ethernet device.
Is there perhaps some way to configure Racket to fall back to IPv4?
Well... that's just weird. I thought for sure there was good relevant documentation here, but I can't find it.
Specifically, it looks like functions like http-open-conn! call functions like tcp-connect to establish connections, but I don't see any documentation for tcp-connect that indicates how hostname resolution is done. I also don't see anything in the net/dns documentation that would indicate the presence of a parameter controlling hostname resolution.
I do see that there's a function called dns-get-address that can be instructed to do IPv6 lookup, so one obvious workaround (maybe this isn't a workaround, maybe it's ....
Okay, actually, no, I'm giving up for now. At a minimum, I think we need at least an update to the http-open-conn! documentation that specifies how host resolution is performed.
I think the only relevant documentation is tcp-connect: "(If hostname is associated with multiple addresses, they are tried one at a time until a connection succeeds....)".
Racket uses the getaddrinfo library from the OS, and it tries the resulting addresses in order, which might mean trying an IPv6 address before IPv4. Depending on the failure mode, that sequence it might get stuck trying IPv6 so that it never gets around to trying an IPv4 address.
Racket's use of getaddrinfo includes a non-NULL hints, but its hints flags do not include AI_ADDRCONFIG | AI_V4MAPPED, which is apparently the default these days (as opposed to 0). It seems possible that adding those flags would improve things and maybe address the problem, but I welcome advice from anyone who knows more about this.
Oh, I see; I had assumed that the hostname->ip step was done in a way that's visible to the language, when in fact this happens at the OS level. It looks like @evdubs understood this already.
In the absence of other comments or advice about this, I would like for a way to set these hints flags if they won't be supplied as defaults. There is this note in the getaddrinfo(3) man page, which I take is what you mean above about "the default these days":
According to POSIX.1, specifying hints as NULL should cause ai_flags to be assumed as 0. The GNU C library instead assumes a value of (AI_V4MAPPED | AI_ADDRCONFIG) for this case, since this value is considered an improvement on the specification.
I've merged a change to include these flags — but to be on the safer side, not included it for the upcoming 8.14 release, so we have more time to try it out for v8.15.
1 Like