After too long, I finally decided to make the move from Subversion to git for version control. Since I use Eclipse for just about all my development, the first order of business was to install the standard Eclipse git plugin, EGit. To my delight it turns out that EGit is installed by default with Kepler (the latest version of Eclipse). I was less delighted to find it didn’t work with IPv6. Or did it?
The problem came when I wanted to check out (sorry – clone) my first project. Eclipse/EGit reported “no route to host”! What?!? I moved to a terminal window and cloned the project using the command line – no problem at all. But in Eclipse/EGit – “no route to host” every time. It looked like this (with the sensitive bits brushed out):
Immediately after the above, this appeared as well:
After the mandatory ten minutes of flailing around it occurred to me that the remote repository host was dual stacked – addressable via IPv4 and IPv6. Maybe there was a problem with IPv6? I disabled IPv6 on my computer and tried again; this forces everything to use IPv4. Connections to the remote repository then failed – on the command line and within Eclipse. My earlier command line test must have been using IPv6. Re-enabling IPv6 and checking with Wireshark confirmed that it was.
My investigations had thus turned up a possible configuration problem on the remote repository host. It was allowing some things in via IPv6 that it did not allow in via IPv4. That’s not necessarily wrong, but it does often indicate that the IPv6 security has not been given the same attention as IPv4 security.
Since the IPv4 address of the remote repositiry host was not working, but the IPv6 address was, I needed to tell EGit to use the IPv6 address rather than the IPv4 address. For some reason it was not resolving domains to IPv6 addresses. Or perhaps it was just not using the IPv6 addresses it retrieved from the DNS. A check with Wireshark showed that it (or the underlying resolver libraries, anyway) were indeed querying for both IPv4 and IPv6 addresses, so I had to conclude that EGit just doesn’t use the IPv6 addresses it gets back from the DNS.
A quick check of the man pages for git did not reveal any way to force it to use one or the other protocol, but I didn’t really want to do that anyway – git was doing exactly what it should do, namely preferring the IPv6 address of the remote repository over the IPv4 address, and IPv6 was working. The problem was EGit – how to make it use IPv6?
A check of all the various options inside Eclipse and the configuration options for the EGit plugin failed to turn up anything useful. I tried telling Eclipse itself to prefer IPv6 to IPv4 by adding an entries to eclipse.ini:
-Djava.net.preferIPv4Stack=false
-Djava.net.preferIPv6Addresses=true
That didn’t help either – EGit stubbornly continued to use only IPv4. Further testing withn Eclipse strongly suggests that Java (I’m using OpenHDK) doesn’t actually honour those settings at all.
To force the issue, I tried specifying the literal IPv6 address of the remote repository instead of its name. Rather to my surprise, that worked. The original remote repository URI looked like this, with names changed to protect the innocent:
ssh://fred@git.nurk.com:22/path/to/repo/repo.git
With a literal IPv6 address, it looked like this:
ssh://fred@[2001:db8:0:100::1]:22/path/to/repo.git
So: EGit (at least the version distributed with Eclipse Kepler) is able to use IPv6 addresses, but it won’t use those supplied in DNS answers, instead prefering the IPv4 answer(s). It seems not to be EGit’s fault however – Java itself doesn’t seem to return the answers from the DNS in the correct order.
The workaround is to use IPv4 (if that’s even possible – for me it was not) or to specify the appropriate literal IPv6 addresses instead of remote repository host names.