B
Story
When Curl Works but IntelliJ Doesn't: The Ollama Connection Mystery
It is a meme, but it's always DNS

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.

  • re
  • ·
  • 8 hours ago
  • ·
  • [ - ]
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?"
  • ·
  • 8 hours ago
  • ·
  • [ - ]
From the Oracle/Java documentation:

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.

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

Yeah, I am aware of this and its totally fine for me for now!
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.
In this case it's possible that it would have worked if he had used mitmproxy.
Yep, pretty much any proxy would have resolved the issue, unless of course it was java based and used the same connection methods.
There's nothing more frustrating than having your debugging tools change the behaviour enough to hide the bug...
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.
Good point! Wireshark was the next step actually if this didnt work!
Even if you know how to use Wireshark already, a lot of times it’s faster and easier to use mitmproxy for something simple.

I use it for reverse engineering IoT apps on android emulators regularly.

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

Keeps IPv6 alive but prefers IPv4

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.
TIL, thanks!
So I understand why preferring ipv4 would fix an issue while using DNS, but why would Java fail to connect when directly using the ip address?
i wasted days on a similar issue… thanks for the write up, hopefully this saves someone else in the future
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.

And we didn't fix it. We just disabled the IPv6.
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.
The problem here is that Java is being used.
Sometimes, when people have a problem, they think, "I know! I'll use Java."

Then they have 2 problems.