It's a good write-up but I wish this blog post went just a little bit deeper with the investigation to confirm whether this is the issue (ollama.tymscar.com having an AAAA record); it's missing the answer to "Why is the JVM trying (or initializing toward) an IPv6 path first and not gracefully falling back?"
java.net.preferIPv4Stack (default: false)
If IPv6 is available on the operating system the underlying native socket will be, by default, an IPv6 socket which lets applications connect to, and accept connections from, both IPv4 and IPv6 hosts. However, in the case an application would rather use IPv4 only sockets, then this property can be set to true. The implication is that it will not be possible for the application to communicate with IPv6 only hosts.
It's strange that things didn't work with this flag to false. It should be able to connect to both IPv4 and IPv6. Now that the author has set it to true, the drawback is that his IntelliJ won't be able to connect to IPv6-only hosts anymore.
Fun read, but you probably could have installed mitmproxy with brew, pointed your IntelliJ instance through this proxy (you can either set it in your settings or run it with environment variable HTTP_PORT or HTTPS_PORT). This allows you intercept the request like wireshark and diagnose. You honestly can just intercept the interface request using wireshark but the learning curve is stepper.
You have to work around TLS, though. Although it is possible with Wireshark, extracting the shared keys through from the browser, I never could get it to work. With mitmproxy I was more successful and could even get iOS Safari to accept my self-issued certificate and read HTTP traffic from a third-party app that I re-routed through my own proxy.
It’s not that hard to use your own CA cert on macOS, you just add it in Keychain. Mitmproxy takes like 5 minute to setup on macOS, they provide a CA self signed cert for you out of the box
Not too dissimilar to what I and some colleagues went through with our local dev tooling yesterday. Not related to DNS, but the frustration was on par.
Went around in circles deleting the repo, deleting packages from homebrew, reimporting the tool chain from our private repo, constantly got HTTP 400 errors from the Rails Console when we were attempting to use our local dev instance to talk to third party APIs.
Eventually found out it was because of a recent release of OpenSSL:
macOS doesn’t give you a built-in toggle — but you can use a resolver config tweak.
sudo nano /etc/gai.conf
Add this..
precedence ::ffff:0:0/96 100
it will boosts IPv4 preference when resolving hostnames that return both A (IPv4) and AAAA (IPv6) records.
(The file may not exist; if so, you’re creating it. It’s honored by getaddrinfo, which Java ultimately uses through the OS.)
I don't see the point in applying such a hack when the problem is a DNS server that they themselves control. Fix/remove the AAAA record and the problem goes away without leaving a footgun on your system to hurt you years down the line by altering the network priority order.
I had a similar issue with Python long ago. We had a server running in AWS that was configured for IPv4 and IPv6 addresses, but we accidentally forgot to set up the firewall rules to allow inbound routing for IPv6.
Everything worked fine in Go, because the built-in client uses the Happy Eyeballs protocol. But Python clients silently failed for _some_ people when working from home. Why? Because they had IPv6 enabled, and Python tried to use it exclusively.
I'm now convinced that the lack of Happy Eyeballs early in the IPv6 deployment was the main culprit for its sad state.
In the situation you're describing, Happy Eyeballs would've kept spamming unnecessary packets across the internet from any framework/language. Python's (technically correct) usage of IPv6 forced someone to actually fix the problem (the misconfigured firewall or DNS).
The more of these half-solutions you make default, the more fragile and confusing networks become. Things like these are what I find so infuriating about "opinionated" frameworks like Go's standard library, because they'll happily apply patch jobs that'll probably mostly work most of the time as a default and leave you to reverse engineer the problem when the workaround eventually collapses.
This sounds similar to an infuriating issue I've been dealing with AWS Client VPN for at least a year - it does not support ipv6, but depending on your setup, requests may try to resolve a ipv6 address first, not find one, and then stall/fail. Only solution seems to be trying to guarantee ipv6 resolution is disabled.
This error can happen if there's an AAAA record, but it contains the ipv4 address packed inside a ipv6 mask.
If the AAAA record says ::ffff:10.0.0.105, then you can either fix DNS or do what's in the blog, which should stop checking for quad A records.
He might have setup IPv4 internal DNS server and java might have used the public IPv6 DNS to resolve the domain.
java.net.preferIPv4Stack (default: false) If IPv6 is available on the operating system the underlying native socket will be, by default, an IPv6 socket which lets applications connect to, and accept connections from, both IPv4 and IPv6 hosts. However, in the case an application would rather use IPv4 only sockets, then this property can be set to true. The implication is that it will not be possible for the application to communicate with IPv6 only hosts.
It's strange that things didn't work with this flag to false. It should be able to connect to both IPv4 and IPv6. Now that the author has set it to true, the drawback is that his IntelliJ won't be able to connect to IPv6-only hosts anymore.
I'm very sure the author has no such need.
I use it for reverse engineering IoT apps on android emulators regularly.
Went around in circles deleting the repo, deleting packages from homebrew, reimporting the tool chain from our private repo, constantly got HTTP 400 errors from the Rails Console when we were attempting to use our local dev instance to talk to third party APIs.
Eventually found out it was because of a recent release of OpenSSL:
1. https://github.com/ruby/openssl/issues/949#issuecomment-3367... 2. https://github.com/openssl/openssl/issues/28758#issuecomment...
Had to rollback OpenSSL to a prior version, we were dangerously close to "time to wipe the Mac".
precedence ::ffff:0:0/96 100
it will boosts IPv4 preference when resolving hostnames that return both A (IPv4) and AAAA (IPv6) records. (The file may not exist; if so, you’re creating it. It’s honored by getaddrinfo, which Java ultimately uses through the OS.)
Keeps IPv6 alive but prefers IPv4
Everything worked fine in Go, because the built-in client uses the Happy Eyeballs protocol. But Python clients silently failed for _some_ people when working from home. Why? Because they had IPv6 enabled, and Python tried to use it exclusively.
I'm now convinced that the lack of Happy Eyeballs early in the IPv6 deployment was the main culprit for its sad state.
The more of these half-solutions you make default, the more fragile and confusing networks become. Things like these are what I find so infuriating about "opinionated" frameworks like Go's standard library, because they'll happily apply patch jobs that'll probably mostly work most of the time as a default and leave you to reverse engineer the problem when the workaround eventually collapses.
Then they have 2 problems.