Hugo Osvaldo Barrera
Comments
> 22% of Internet users in the USA is on IPv6. This is a large group of people that you would be affecting by disabling the IPv6 Stack.
It would seem Mojang simply does not care. For two years, many of us have been completely incapable of playing online, at all, even though we paid the full price for the game.
Note that this bug is not accidental, but deliberate, as a workaround for people with broken network configurations (while breaking for other people, with no workaround possible). It would seem that not logical reasoning will make this go away soon, or ever.
Just get used to not-playing minecraft: it seems to be the only choice.
> I added it go the /etc/hosts and I believed I passed an argument for it to prefer IPv6.
What argument did you pass to the game for it to do this? AFAIK, it completely disables IPv6 on startup. Or are you just talking about the bootstrap?
> @Daniel L: Because the problem is more complicated than it appears (read the comments on this issue, and MC-15525), and fixing it (at least the way suggested) might very well break it for an even larger chunk of users. That isn't a non-issue for Mojang, no matter whether it's right or wrong. IPv6 support in Java was not great, though perhaps it has improved in Java 8.
No, not problem is not complicated as it appear. Is main issue here, is that you did a workaround to fix this for people who had broken network settings, while breaking the game for people with their network properly set-up (in other words: I can't use a product I paid for because you prefer to satisfy people who have broken configurations!). The solution is simple, fix IPv6 and:
It works for people with their network properly set up, either inet4 or inet6.
People with broken network settings should fix that. Either do it themselves, ring their ISP, or hire a technitian. Configuring their own network is their own responsability.
> Interesting, however, that you report IPv6 as working on Linux. Has anyone tested this with the new, native launcher / bootstrap? One of the barriers to getting this fixed was Mojang's hesitation to push out a new bootstrap, because they couldn't update it automatically, and it must be downloaded manually. However, they released a native installer for Windows in December/January, and are planning on doing the same for Macs in the future.
Where can I find this? The one at https://minecraft.net/download has the same sha512 as eight months ago, so there's been no change there.
> I've tested on Linux, I can connect to IPv6, but it requires me to add the address to my hosts file and than use the name rather than the address. Not ideal.
Can you elaborate further? Did you add the IPv6 of the remote game server to /etc/hosts? Minecraft completely ignores IPv6 AFAIK, what else did you do to get it to connect?
> I run a private cloud that only uses native IPv6. This seems like a large oversight to disable a fundamental networking protocol in this day and age.
Indeed, this issue meant the end of minecraft (forever) for those of us where our desktops and laptops only have native IPv6.
Is there any update on this?
It's been over half a year since I, like many other users can't play multiplayer (after having paid, btw!) - and the situation only gets worse as more and more ISPs transition to IPv6. This is getting completely ridiculous, I wanted to play during the holidays with my friends, the holidays started and ended, and we could not because of code that explicitly breaks support for non-broken networks!
Unlike the above commentor, I have no IPv4 addresses or routes. I've been completely unable to play a game (which I payed for, btw), for several months now.
Any idea on when this critical and fatal issue will be fixed? I kinda passes on all my holidays being completely unable to play at all.
Again, if the source for bootstrap were made available, I'm sure I could submit a proper patch for this. I see no reason for you not to release it, since it doesn't actually contain game code or any other secrets (AFAIK).
If that were all true, then Mojang never would have set preferIPv4Stack=true, this ticket would have never been filed, and we wouldn't be having this conversation. So something's amiss.
preferIPv4Stack alters preferIPv6Address, which causes this issue. Setting preferIPv6Address is enough to achieve the behaviour you want, and setting preferIPv4Stack cannot be undone programatically. preferIPv4Stack, by transitivity also achieves the behaviour you want, but cannot be alterned, even through reflection.
And if these are both true, then passing "-Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Address=true" when starting Minecraft.jar should solve your problem, at least for the launcher and downloading the game. Setting those properties in the JVM arguments field in the launcher profile should also solve it for the game, though as discussed, the network code may assume / be forcing IPv4 somewhere else in the client.
It does not. As we discussed before, the game seems to alter this setting programatically. There's still the Protocol family unavailable error.
I've also just realized that we've been conflating preferIPv6Address and preferIPv6Address*es*. I'm only aware of the latter, and that would some of the confusion. preferIPv6Address may indeed have the behavior you ascribe to it, though it doesn't appear to be documented anywhere. Does it default to true or false?
preferIPv6Addresses is the name of the java property, preferIPv6Address is the name of the variable where the setting is stored internally. We're still talking about the same thing here. From java.net.InetAddress:
static {
preferIPv6Address = java.security.AccessController.doPrivileged(
new GetBooleanAction("java.net.preferIPv6Addresses")).booleanValue();
AccessController.doPrivileged(new LoadLibraryAction("net"));
init();
}Sorry about the confusion on this one.
> Unless this documentation is wrong, your sample code isn't going to accomplish anything. java.net.preferIPv4Stack is only read at VM startup time, so setting it using System.setProperty() is pointless, because the VM is already running..
Using preferIPv6Address is enough to determine if java uses IPv4 or IPv6:
Having preferIPv4Stack=false and preferIPv6Address=false will make java prefer IPv4 anyway.
Having preferIPv4Stack=false and preferIPv6Address=true will make java prefer IPv6.
My sample code uses reflection to overwrite the the value of preferIPv6Address after is has been read, hence overcoming the limitation of it being read only once. Here's how it works:
Attempt to establish an IPv6 connection. (at this point preferIPv4Stack and preferIPv6Address have their default values).
If it failed, set preferIPv6Address to false, via reflection. This will affect all future connections (they will not use IPv6).
If it succeeded, set preferIPv6Address to true, via reflection. This will affect all future connections.
Hence, IPv6 will only be used if it has been proven to work.
I would advise against using he preferIPv4Stack flag since:
It cannot be altered by reflection. I've failed to find where it's read by grepping through java's src.zip, so I assume that it must by read by the JVM itself via some native code. (I'm just guessing though).
preferIPv6Address is enough to control which protocol is used.
> Or maybe the documentation is flat-out wrong.
This would not surprise me coming from Oracle.
—
While I understand that there are some other issues pending, I would appreciate if this issue is given a higher priority. As the game is right now, it cannot be played in any form of multiplayer (eg: Open-to-LAN, Online, Realms, or with a dedicated VPS running a server) by users with no native-IPv4.
In other words, it's a critical issue, which prevents users with a properly working PC and network from playing the game, with absolutely no workaround. Considering that it's a product we pay for, I think I have a right to complain if there is absolutely no way for me to use it.
@Torabi: Any updates on this?
As far as I can tell, "java.net.SocketException: Protocol family unavailable" means that it's trying to bind an IPv4 socket to an IPv6 address (and obviously failing).
Not exactly. It means that it tried to bind an IPv4 socket, and IPv4 is unavailable on that interface.
The underlying problem may be Java. An IPv6 socket is supposed to be able to communicate with both IPv4 and IPv6 peers, but it may be OS- and implementation-dependent.
Indeed the issue is java. On an IPv6-only system, it tried to use IPv4 by default until I set the preferIPv6Addresses property to true. Regrettably, java is well know for it's poor network IPv6 compatibility. 😞
(I don't blame you for that though!)
All the bootstrap does is download and run launcher.jar, which is how they are able to automatically update the launcher.
That's why it's so very important to fix launcher.jar first. Without fixing it, the game can't even be downloaded. Once launcher.jar works, further issues can be addressed. Have you considered integrating the sample code I provided above? (I just updated it a bit). It will only alter the value of preferIPv6Addresses and preferIPv4Stack after having succesfully tested and made sure IPv6 works correctly and not affect any other scenario, which is what you care about. It shouldn't take more than five minutes to review and integrate it. There'll be no regressions, even for broken network setups.
You'll get an error like "MCO Availability Checker #1/ERROR: Couldn't connect to Realms" when using any version that's not realms compatible, such as snapshots.
Nope, running 1.7.9 on a clean install performed yesterday (I could not install minecraft on my desktop before I wrope the crappy wrapper mentioned above).
I'll try the same client on a network with IPv4 tomorrow (my university has IPv4 so I'll use that oportunity to test it) and confirm if the realms issue is or isn't a client issue.
It is interesting, however, that it's coming from the client, and yet you later receive a "Protocol family unavailable" error. It looks like you're trying to connect to a local IPv6 address (::1). [...]
Yes, I am. Any other IPv6 literal gives the same issue.
I would have hoped that all of this would have been cleaned up when the networking code was switched to netty, rather than IPv6 support being broken in the process. I'll have to see if I can get one of the devs to take a look at it.
Indeed, it is interesting (and confusing) that realms connects and Multiplayer does not. They're inconsistent, but, AFAIK, the same VM. However, now that you've mentioned netty, I can't avoid thinking that it may have a different setting for disabling IPv6, and that's the issue.
Also, notice how it uses sun.nio.ch.Net, instead of java.net, which again, makes me think it uses a different setting, which has also been hardcoded. (I've failed to find further details on this though).
[quoted out of order just to make replying tidier]
What happens if you try to connect to a remote IPv4 address?
It fails, as expected, with the expected error message:
java.net.SocketException: Network is unreachable.Or course, this will happen for any address != 127.0.0.1, since there are no IPv4 addreses or routes.
@Torabi:
Ok, using my wrapper, nope, there's something else going on, and I'm not sure what it is: "java.net.SocketException: Protocol family unavailable".
My wrapper basically runs minecraft.jar, which I belive downloads and runs launcher.jar (correct me if I'm wrong).
launcher.jar logs me in fine, so it's using IPv6. I guess all these are on the same VM, right?
The game itself does not seem to have any IPv6 connectivity.
This is curious:
[22:44:43 INFO]: Client> [22:44:43] [MCO Availability Checker #1/ERROR]: Couldn't connect to Realms: Realms (500) Server not available!It's not a network or routing error, it's a 500 error that came from the server, so the game used IPv6 up to when it reaches the menu...
22:45:43 INFO]: Client> [22:45:43] [Client thread/WARN]: Unable to start LAN server detection: No such deviceThat's understandable, the game is probably using an IPv4 literal for that, and it's not working.
However, when connecting to a server:
[22:46:55 INFO]: Client> [22:46:55] [Client thread/INFO]: Connecting to ::1, 25565
[22:46:55 INFO]: Client> [22:46:55] [Server Connector #1/ERROR]: Couldn't connect to server
[22:46:55 INFO]: Client> java.net.SocketException: Protocol family unavailable
[22:46:55 INFO]: Client> at sun.nio.ch.Net.connect0(Native Method) ~[?:1.7.0_60]
[22:46:55 INFO]: Client> at sun.nio.ch.Net.connect(Net.java:465) ~[?:1.7.0_60]
[22:46:55 INFO]: Client> at sun.nio.ch.Net.connect(Net.java:457) ~[?:1.7.0_60]
[22:46:55 INFO]: Client> at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:670) ~[?:1.7.0_60]
[22:46:55 INFO]: Client> at io.netty.channel.socket.nio.NioSocketChannel.doConnect(NioSocketChannel.java:176) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.connect(AbstractNioChannel.java:169) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.DefaultChannelPipeline$HeadHandler.connect(DefaultChannelPipeline.java:1008) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:494) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:479) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.ChannelOutboundHandlerAdapter.connect(ChannelOutboundHandlerAdapter.java:47) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:494) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:479) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.ChannelOutboundHandlerAdapter.connect(ChannelOutboundHandlerAdapter.java:47) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:494) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:479) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:464) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.DefaultChannelPipeline.connect(DefaultChannelPipeline.java:847) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.AbstractChannel.connect(AbstractChannel.java:198) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.bootstrap.Bootstrap$2.run(Bootstrap.java:165) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:354) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:348) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) ~[netty-all-4.0.10.Final.jar:?]
[22:46:55 INFO]: Client> at java.lang.Thread.run(Thread.java:745) ~[?:1.7.0_60]Looks like the game itself isn't using IPv6. Maybe a new VM is started? I'm really confused. 😞
In any case, can you forward the sample code I linked above to the devs? It fixes the issue (at least for minecraft.jar and the launcher) while not affecting any current user negatively (or, if you're one of the dev, can you give me some feedback for that?). Thanks!
The fact that it's not obfuscated doesn't make it legal to alter it or provide modified versions to third parties. Also, source is easier to edit than decompiled classes.
This comment describes a bit why IPv6 is completely disabled:
It's unfortunate that "preferring" IPv4 in actuality means "disabling IPv6", but that's on Java. The preferIPv4Stack setting is only checked when the VM starts, which is why it must be set by the bootstrap. Given that, it's not clear to me why someone starting the jar file directly, without the bootstrap, would have a problem, or why the launcher jar would need to set this property.
I belive he meant the preferIPv6Addresses, but the rest still applies.
So I installed eclipse and got to hacking some code:
A wrapper
This tiny piece of code wraps around the launcher and enables IPv6 before the launcher can disable it. I'm leaving this here as a solution for users who are interested in downloading the game and this is not mean to be mainstream.
For some reason though, the game itself still won't have any network capabilities. I'm not sure if the laucher spawns a new VM, of the game has something else hardcoded to disabled IPv4.
A solution
This sample code re-enables IPv6 only AFTER having tested that it works properly. If it fails, it will bail and to nothing.
If you can review this and integrate this into minecraft, we can finally fix (and not simply "resolve") this issue.
If (or rather, hopefully, when) you include this into minecraft, the result would be:
IPv4-only users with proper network configurations would see no change (maybe < 50ms extra to startup time, heh!)
IPv4-only users with broken network configuraions would have to wait for a very small timeout upon launch and only upon launch (this is a few seconds and might be noticable. But hey, their network is broken, remember?).
Dual-stack users would be able to use both stacks, hence, being able to connect to IPv6 servers (though I belive those aren't common).
IPv6-only users can finally play the game. Other specific IPv6 scenarios may require further work, but those issues will arise later (see below for an example).
In short, nothing breaks, not even for people with broken configurations, which I think is what's most important here.
—
As for future issues (though not quite related), here's an example:
I'm pretty sure the "Open to LAN" only has an IPv4 multicast literal for announcing/listening, so that would require further changes on behalf of the devs to work. However, that would be a completely new issue once these changes get integrated into the game.
I'd appreciate some feedback for this. 🙂
Having a broken IPv6 stack means that attempting to connect through IPv6 doesn't work, either because a driver on the stack is poorly written or misconfigured. Fixing it isn't always as simple as just changing a few settings. Most software will simply use the IPv4 stack instead, if both are available.
Yes, sorry, I sort of mixed up two issues; not preferring IPv6 by default is not unacceptable. Completely disabling IPv6 is an issue, because you assume that all users have IPv4 connectivity. But that's what MC-3776 is about, and this issue is just about preference, so I'll just shut up here and limit that discussion to the proper issue. Sorry for the noise.
Regarding the launcher
At the very least it wouldn't hurt to add an IPv6 option (with an appropriate warning) to the launcher. In the meantime, to use IPv6 we're forced to use a 3rd party launcher or a modified version of the official one.
I agree that adding an option (even if it's just a CLI one) would be an acceptable solution (not the best, IMHO, but it'd be enough to keep me happy).
MagicLauncher does not work: http://sprunge.us/XgFB
MultiMC works half way: The launcher work, but the game still has IPv6 disabled (both LAN and online). So the game can be run, but single player only.
Since the launcher itself is rather simple and small, and does not actually contain game code or anything secret, would you consider open sourcing it so we can at least fix the issues for ourselves? I'd much rather mantain a patched version for myself than use a third party launcher.
Otherwise, why not provide an IPv6 minecraft.jar on your website? It's basically the same code with two lines commented out, I don't think it's much of a hastle.
Regarding the game
Are there any know workaround? I've managed to install it, but I'm still limited to single player only.
Also, have you actually considered the implications of this issue? Many, MANY paying customers cannot play the game, and will not be able to for an undefined future, just because some people out there have broken networks. You guy basically took my money and are unwilling to give me a working game in return.
If there's no workaround, can I get a refund? I mean, I either want a game that runs, or my money, you can't expect me to settle for none of both choices.
Please update the summary; the problem is not minecraft.exe, as this issue is present on GNU/Linux with minecraft.jar. The first sentance of this issue indicates the contray.
Also, "Local Network" isn't the only thing affected. Playing online does not work either. Maybe the summary should be updated to include this issue as well?
Pointing to a FAQ on how to fix these configurations (simply OS's manuals) would have been way easier and less controversial to fix.
But there's one thing that makes me uneasy: how do others solve the issue with these broken network configurations?
If the user's configuration is broken, other software should have the same issues (eg: browsers, im clients, email clients, package managers). How do these applications deal with these issues and, most importantly, can't their solution be used by minecraft?
—
That aside,
MCL-2627 covers the launcher
MC-3776 covers LAN play
Are there any issues still open that address the issue of not being able to play online either? Or should MC-3776 be updated to include this?
> How would you go about reproducing it, unless you have an IPv6-only internet connection?
It's quite simple to reproduce: with a dual-stack connection, disable IPv4.
You can optionally enable something like NAT64, or another transition mechanism if your server is running on IPv4-only, but since these are really transparent, they're not necessary for the purpose of analysing this ticket.
> Disabling the IPv6 stack has no effect on people who also have IPv4 access, and resolved an issue for a substantial number of customers.
From what has been described, the root cause of these issues, were misconfigured networks. Properly configuring those networks is the proper solution, and could have satisfied everyone.
Personally, I've IPv6-only, with NAT64. I don't have issues reaching hosts (except less than a dozen misconfigured servers - during a period of >2 years).
> Mojang made the decision to disable IPv6 based on a substantial volume of complaints and support requests that Minecraft no longer worked.
"volume of complaints" should not be the only factor involved. Relevancy of the complaint should be a factor too. If the root cause of a complaint is a misconfigued network (as mentioned several times around IPv6-related issues), then those issues should not be relevant to Mojang or the developers. Tell the users how to configure their network, don't break the game for others.
I paid for the game. And I can't play. Reason: Mojang prioritizes people with broken setups. This isn't an aggressive complaint, I'm trying to get a message across: I paid, and now you're saying you don't care about the fact that I cannot play the game.