Newer Fedora versions (Fedora 18 and onwards) use Firewalld to manage iptables rules. The iptables service that loads rules out of /etc/sysconfig/iptables
is not present by default. A bunch of my answer involves manually bashing about in iptables rules. This is a bit of new ground for me, as my main experience with firewalld up to this point has been making a beeline back to traditional reading of iptables rules out of the save file. Most of the firewalld information was collected on the fly based on the iptables
rules that it implemented.
I double-checked this on a Fedora 20 VM that I've been fiddling with. When a rule is set in firewall-config
, the packet for a new connection must go through the following steps to be accepted.
- New packet hits INPUT chain. Packets in existing connections are automatically accepted.
- All prospective connections from the outside are sent to the either the INPUT_ZONES_SOURCE chain or INPUT_ZONES chain, based on whether they were picked out based on source IP or the interface the packet came in on. The logic within each is pretty much the same, other than the IP/interface note. I'll be focusing on INPUT_ZONES_SOURCE for my example.
- I added my Minecraft rule to the 'home' zone, so I had added an entry in home->sources stating that packets coming from the network address of 10.20.30.0/24 were coming from home. In INPUT_ZONES_SOURCE, there was a rule that would send all packets coming from that IP range to the IN_home chain.
- In the IN_home chain I had three chains dedicated to specific tasks: IN_home_log, IN_home_deny (this was empty, as I hadn't set anything), and IN_home_allow.
- IN_home_allow held all of the allowed services for the 'home' zone, including the 25565 rule that I had just put in. Though I didn't start up a Minecraft server or bind anything else to TCP/25565, I could see that some other default rules did record that packets were being accepted, so traffic was being evaluated against this rule.
- Any rule that does not get accepted will eventually splatter against the last rule of the INPUT chain. The final rule will reject any packet that is still on the chain.
To get to the point of my explanation, could I confirm that you've set an input interface or a IP address/range for the zone that you're allowing the port in? You've placed a rule to allow the port in a given zone, but it sounds as though the packet doesn't have a way to reach that rule and be accepted.
You can list a table using iptables -nvL
. Firewalld sets up a lot of chains, so if you want to take a look at one in particular, add the chain name as an argument: iptables -nvL <chain-name>
. If you can see numbers greater than zero in the lefthand columns, this means that packets have reached and triggered the rule. (The action the rule takes is in the third column).
To force your firewall to accept everything, and to see if something along the line is causing you grief, you could stop the firewalld service altogether temporarily.
systemctl stop firewalld
You can alternately flush the tables with iptables -F
, though I'm not sure when/if firewalld will repopulate the chains on their own without a rule change to prompt it to do so.
Hopefully this will solve your issue. But if you want/need to go to a custom iptables
layout by having the firewall load its rules out of /etc/sysconfig/iptables, you will need to install and enable the service, as well as disable firewalld.
- Install iptables service:
yum install iptables-services
- Stop Firewalld:
systemctl stop firewalld
- Disable Firewalld:
systemctl disable firewalld
- Start the iptables service (If you don't have an /etc/sysconfig/iptables at this point, this won't do anything):
systemctl start iptables
- Enable the iptables service:
systemctl enable iptables
General Notes
(I'm sorry for any spelling-, grammar- and wording-errors and over-complicated expressions and explanations, English is not my native language...)
I managed to get Minecraft running on my ARM-Chromebook; however, it may not work for future releases (perhaps you will have to modify the scripts, perhaps it won't work at all).
The Launcher I last tried this method with was 1.6.61
and the Minecraft version was 1.9.2
.
Knowing a bit of how to write bash scripts is recommendable; do NOT use my script for learning bash, I'm not good at it and you shouldn't learn bad coding practices. (This code is probably acceptable but don't use it for learning just to be sure.)
Do this at your own risk. (I don't think that anything can go wrong really; anyway, backups are always a good idea.)
My actual Answer
Working Principle
The MC-Launcher does the authentication stuff with the Mojang-Server, the updates (including library updates), profile management and then passes the required arguments to the MC-Client. The MC-Launcher also passes the library paths to the Client. By writing a java-wrapper-script we can modify the library paths passed to the client.
Choosing a newer proprietary edition of Java (optional)
As of what I heard Java 8 brings some notable performance improvements to the ARM platform. By using the version directly from Oracle you won't get automatic updates though.
You can download the proprietary Java 8 here. Go to the downloads page (the link might change from time to time which is why I didn't link directly there), choose to accept the licence and download the version you need (in my case "Linux ARM 32 Soft Float ABI"). Extract the tar file whereever you want to store it on your computer (e.g. in ~/proprietary_java/).
Starting the Launcher
If you downloaded Java 8 and didn't install it in any way (only unpacked the archive somewhere) you can launch the launcher by running e.g.
~/proprietary_java/jdk1.8.0_77/bin/java -jar ~/<path-to-the-minecraft-launcher>
.
(You may need to change the path accordingly when a newer version of Java is released at some point. You may also want to write a custom .desktop file or launch script for this.)
The Java Wrapper
This is where my solution gets a bit hacky (not in a good way). You can use this script but you may need to modify the paths:
#!/bin/bash
ARGS=$@
#echo $ARGS > /tmp/args_original #uncomment for debugging
JAVA=$HOME/proprietary_java/jdk1.8.0_77/bin/java
JAVA_LIB_SETTING="-Djava.library.path="
JAVA_LIB_PATH="$HOME/MC_libs"
MC_ORIG_LWJGL="$HOME/.minecraft/libraries/org/lwjgl/lwjgl/lwjgl/2.9.4-nightly-20150209/lwjgl-2.9.4-nightly-20150209.jar"
MC_ORIG_LWJGL_UTIL="$HOME/.minecraft/libraries/org/lwjgl/lwjgl/lwjgl_util/2.9.4-nightly-20150209/lwjgl_util-2.9.4-nightly-20150209.jar"
MC_ARM_LWJGL="$HOME/proprietary_java/MC_libs/lwjgl.jar"
MC_ARM_LWJGL_UTIL="$HOME/proprietary_java/MC_libs/lwjgl_util.jar"
ARGS=$(echo $ARGS | sed "s|$MC_ORIG_LWJGL|$MC_ARM_LWJGL|g" | sed "s|$MC_ORIG_LWJGL_UTIL|$MC_ARM_LWJGL_UTIL|g" )
ARGS=$(echo $ARGS | sed "s|-Djava.library.path=[a-zA-Z0-9_\/\\\.-]\+|$JAVA_LIB_SETTING$JAVA_LIB_PATH |g") #magic ;-)
# the magic seems to eat the space-character though; this is why it's added after JAVA_LIB_PATH (I'm not good at regex)
#"[a-zA-Z0-9_\/\\\.-]\+" explained:
# match a-z and A-Z and 0-9 and '_' and '/' and '\' and '.' and '-' (this must be at the end it seems).
# "\+": escape the '+'; match this pattern multiple times.
# (this means: start at "-Djava.library.path=" and stop replacing at the first space that occurs)
#echo $ARGS > /tmp/args_modified #uncomment for debugging
$JAVA $ARGS
Save this script e.g. as java_wrapper and make the file executable (e.g. chmod +x java_wrapper
)
Explanation:
ARGS=$@
: get the arguments passed to the wrapper (more or less the arguments passed to the MC-Client). We do this since we want to modify those and "ARGS" is a little more self-explanatory than "$@"
echo $ARGS > /tmp/args_original
: this puts all the arguments to the file /tmp/args_original. This is useful when the game doesn't launch anymore - some paths may have changed and you may need to replace a few paths. Using this you can see which paths you need to replace - more on this soon.
JAVA=$HOME/proprietary_java/jdk1.8.0_77/bin/java
: The path to the Java-executable.
JAVA_LIB_SETTING="-Djava.library.path="
: This is how java wants to get the library paths. The MC-Launcher passes them like this. Maybe this will change at some point (probably not) and then you'll need to find out how Minecraft tells Java where to look for these libraries. (Uncomment echo $ARGS > /tmp/args_original
and have a look at /tmp/args_original and search for something that looks like passing libraries; I'm sorry, I can't provide anything more clear (I did it like this) but maybe someone can provide a proper how-to in the comments?)
JAVA_LIB_PATH="$HOME/MC_libs"
: Compile libopenal and liblwjgl as mentioned here and put the files lwjgl/libs/linux/liblwjgl.so
, lwjgl/libs/lwjgl.jar
, lwjgl/libs/lwjgl_util.jar
and openal-soft-1.15.1/build/libopenal.so.1.15.1
(remove the ".1.15.1" from libopenal.so) in a directory you want to use (e.g. ~/MC_libs in my example)
MC_ORIG_LWJGL=
: This is the original path to lwjgl.jar as it is passed by the launcher. This will probably change at some point (uncomment the lines for debugging then and search for something like "lwjgl.jar" in /tmp/args_original)
MC_ORIG_LWJGL_UTIL
: This is the original path to lwjgl_util.jar as it is passed by the launcher. This will probably change at some point (uncomment the lines for debugging then and search for something like "lwjgl_util.jar" in /tmp/args_original)
MC_ARM_LWJGL
: This is the path to the lwjgl.jar that you compiled (as described in my "JAVA_LIB_PATH=" description)
MC_ARM_LWJGL_UTIL
: This is the path to the lwjgl_util.jar that you compiled (as described in my "JAVA_LIB_PATH=" description)
ARGS=$(echo $ARGS | sed "s|$MC_ORIG_LWJGL|$MC_ARM_LWJGL|g" | sed "s|$MC_ORIG_LWJGL_UTIL|$MC_ARM_LWJGL_UTIL|g" )
: Here we change the first few things in the arguments: We replace the path $MC_ORIG_LWJGL with $MC_ARM_LWJGL and $MC_ORIG_LWJGL_UTIL with $MC_ARM_LWJGL_UTIL.
ARGS=$(echo $ARGS | sed "s|-Djava.library.path=[a-zA-Z0-9_\/\\\.-]\+|$JAVA_LIB_SETTING$JAVA_LIB_PATH |g") #magic ;-)
: Here we replace the library path (which is something that actually may change at some point) with our library path; we replace the specified path after "-Djava.library.path=". I hope you don't have any spaces in there, I'm not good with regular expressions (that's what the "[a-zA-Z0-9_/\.-]+"-thingy is called).
echo $ARGS > /tmp/args_modified
: Uncomment this line if you want to see what we get after our modifications to ARGS. This can be useful for finding out what you got wrong in the paths. (I needed this very often for the regex ^^)
$JAVA $ARGS
: Call the version of Java we specified at the top and pass the modified arguments of the MC-Launcher to it.
Making the Launcher run our wrapper
Launch the MC-Launcher, log in (if needed) and edit the current profile: In the section "Java Settings (Advanced)" check the option "Executable" and change the path to our Java-wrapper-script.
Now it's finally time to test our wrapper! Launch the MC-Launcher and start minecraft as usual. That's it! If it doesn't work you'll get a few error messages which will hopefully explain what's wrong... You then may need to change a few paths. (Let's hope it's not more than that.) And if it works: Have Fun!
Feel free to ask anything, in some cases I may be able to provide an answer - if not I hope that someone else can.
Best Answer
According to this: https://hypixel.net/threads/solved-connecting-to-hypixel-from-1-8-9-is-not-working.1977642/, you need to change the java executable to make sure that the correct java version is being used.
This is how you do this in the latest Minecraft Launcher:
/usr/lib/jvm/java-8-openjdk-amd64/bin/java
If that doesn't work and he is using UFW firewall try seeing if it works after running:
sudo ufw disable
(this command might not exist)