1. Login failure
The login is failing because you haven't bought Minecraft for those accounts. When you buy Minecraft it will be listed as one of your games in your account when you log in on Mojang.com, but until then you don't have a Minecraft login, you just have a login to a website that doesn't do anything except tell you that you haven't bought any games to use it with yet. You can still play in offline mode, since Mojang is not so obtuse as to require you be always-online in order to play Minecraft, unlike some other game publishers. However...
2. Server connection failure
When you connect to a server it will check if your account has a Minecraft registration too, and will drop the connection if not. So there are two times your login is checked for Minecraft access: once when you start the game, and once when you start multiplayer.
Fixing the server connection
The server's behaviour can be modified by editing server.properties and setting the line:
online-mode=true
to false instead. The players wanting to connect then pick a name to use consistently (since the server won't enforce identities to match what it has saved in its world files) and "try" to log into the game with that, let it fail, then play offline. Since the server is set to offline mode too, it will allow them to connect under that name.
The problem with this is that anyone can connect – make sure that the server isn't exposed to the internet, and the worst of the complications will be avoided.
The more likely problem though is that you'll have a bit of a headache migrating the kids' work once they have full accounts, since it's likely that the names they pick won't be available to choose once Minecraft is added to the Mojang account (which is when you can pick an official profile name for use in Minecraft). If there are name changes, then you'll have to either walk the child through the idea of losing their inventory and location on the server (blocks they placed will still be there), or you'll have to fiddle with NBT editors to transfer the inventory and location from the old name to the new one in the server's save files. Not hard, either one, but a stumbling block to be aware of.
The real solution here is to register a Mojang account for each child and purchase Minecraft for each account. I understand the desire to test it all out first, but if they already like Minecraft in single player, there aren't really any surprises that come with multiplayer that should change their or your mind. The advantage here is:
You'll immediately get the names that they'll be sticking with (consult and choose wisely, for children are fickle!) and can avoid identity issues in the server's save files.
You'll be able to set custom skins for their avatars, which children inordinately enjoy, in my experience. These are kinda nice in single player, but since they're readily visible in multiplayer they become more relevant when playing with others.
Fewer steps in logging in and connecting to multiplayer where mistakes could happen (a registered account can be remembered with it's password, making logins one-click), which for younger kids can be a bit of a headache-saver for you.
My kid has had an account for a year or so now and loves playing with other people, even if it's only to make random block stacks and randomly-enchanted gear in Creative mode. But then, that's 5-year-olds for you.
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
Best Answer
there are 3 things that cause this, the client, server or you.
Server: try restarting the server, synch problem!
Client: same, restart!
You: you're in such an high XP level, it looks like youre not gaining anything, but you do