zone not loading - host name error / file not found

[cduckman]

I'm running Redhat Linux 7.1. Installed all the mysql stuff fine, checked that login worked on the proper user and ensured that all tables and permissions were OK.

I compiled world and zone, and then followed all the instructions.

World ran fine. Put out what it should, no errors.

However, when I ran zone, I got:
Using database 'eq' at localhost
Loading items & NPCs....done.
Loading guild ranks...done.
Loading faction data...done.
Unable to get host name. Error: No such file or directoryInitWorldServer failed
Entering sleep mode.

(No typos above, including newlines)


I've been playing around with my configs, and now the world server seems to be giving incorrect output:
LoginServer.ini read.
Using database 'eq' at localhost
Loading items...done.
Loading guild ranks...done.
World server listening on: port 9000
Connected to LoginServer: eqlogin.eqemu.org:5999

Notice the missing IP before "port 9000". World used to return this output but with the IP. Now it won't. I don't know if that is because I changed my configs or what. I can't figure any of this out.


My configs:
[Database]
host=localhost
user=eq
password=mypass
database=eq

[LoginServer]
loginserver=eqlogin.eqemu.org
worldname=Tower of Dalbane
locked=false
account=
password=
worldaddress=my external ip
loginport=5999


Regarding what follows: I have a dir named world, so my freshly built world server uses .exe. zone is the same way. Again, these ARE linux binaries.

I start the server by:
./world.exe
./bootzones.sh


bootzones.sh file:
./zone.exe . 24.28.75.192 7995 24.28.75.192
./zone.exe . 24.28.75.192 7996 24.28.75.192
./zone.exe . 24.28.75.192 7997 24.28.75.192
./zone.exe . 24.28.75.192 7998 24.28.75.192
./zone.exe . 24.28.75.192 7999 24.28.75.192

24.28.75.192 is my external ip.

Network setup:
EQEmu is hosted on a linux box with a static ip on my home network. A linksys router serves as a gateway to the outside world. I have port 9000 forwarded to my linux box from my router. I also have a dyndns.org address linked to my ip.

I've tried using all three (my internal ip, my current external ip, and my dyndns address) for worldaddress to no avail.

I've used multiple combinations of things in my bootzones file.

I have, however, never used any localhost or 127.etc. addresses except in the db.ini config since I'm not using a minilogin server (I'm on linux... not win32).


I'm pretty clueless on this one, I've searched the website, been over the readme a few times, and went over quite a bit of the forums.

Another thing - how are all you linux folks doing this? I'd like a way to launch this with one command, preferably a command launched from the /etc/rc.d/init.d/ dir at bootup. Any help here?

Thanks folks! =D

[Trumpcard]

You're going to have to port forward more than just 9000, you'll need to UDP forward all your zoneserver ports too..


Also, make sure you dont have any whitespace on the end of your .ini lines..

As far as starting, Ive thought about setting the server up so its started when the server bounces, but I havent gotten around to it yet. What I'd like to see 1st is logfile output to something other than stdout specified in the code (variable via an ini file perhaps) before I try to make a service out of it. I've toyed around with doing it myself, but the dev team isn't very open with their task/assignment list (not really their fault, just a result of using starteam rather than cvs, though I wish starteam had a public web interface so certain parts could be made available, ie the tasklist), so I dont want to work on something thats either being worked on by someone else, or won't get merged into the code anyways.. I'll just wait to the emulator gets to a later phase, then think about wrappers for it then.. It would be very easy to create an init.d script to do it though.. Just start them, get the pid numbers, write them out to /var/tmp, then background all the processes. For stopping, just do a Sig Hangup on the process pids, wait 10 seconds, check them, then kill -9 them if theyre still alive... Nothing much that really needs to be done. Since you can send a broadcast via the world binary, you could even tell it to broadcast to players on the server before it shuts down.

[cduckman]

Trump, thank you so much for the quick reply, but it's still a no-go on this.

I opened up my ports 7995-7999 on udp, but I'm still getting the same things.

Any other ideas? =\

Thanks again.

[Trumpcard]

Hmm..

I dont use a router, my linux box has 2 ethernet cars, so it acts as the router for my subnet, not sure what kind of special things need to be done. I know several people here have the linksys routers, I remember seeing several threads on this exact topic.

The error is odd though,
Unable to get host name. Error: No such file or directoryInitWorldServer failed

Almost like 2 unrelated messages are being tied together..

Unable to get host name sounds like its trying to do a dns lookup on something, no such file or directory sounds like it cant open the ini files.

Do you have your ini files located in the same directory as the zone server?

[cduckman]

Yep.

[Trumpcard]

Change the last ip in your zone lines to 127.0.0.1

zone.exe . <external ip> <port> 127.0.0.1

[cduckman]

already tried that =(

Odd, hmm?

Any more ideas? =\ Thanks so much for the help Trumpcard. =)

[theCoder]

A couple of questions:
1) What is the IP address of your Linux server? I assume it's 192.168.x.x and not your external IP. If that's true, I think this may cause some major problems when you go to try to play on your server (assuming your EQ client is on another 192.168.x.x IP).

2) Have you tried using minilogin (on a windows box :() and using all internal IP addresses? This is a good first step to make sure that everything is working before you mess with the outside world.

I think one of your problems is that the world server INI parsing code is broken. It doesn't like the lines in LoginServer.ini that have keys but no values (account= and password=). That's why you're not getting the worldserver address in your world output. Either delete those two lines, or move them to the bottom of the file. Or if you're feeling ambitious, fix the code and submit a patch :)

The zone server problem is probably related. The error is coming from line 845 of zone/worldserver.cpp (the lack of a line break is a bug -- that line isn't printing out a newline character). That line is doing a gethostbyname() on the worldserver address that was passed on the commandline (the fourth argument). For some reason, this is failing, but it's not the error given. According to the man page for gethostbyname, when an error occurs, h_errno is set, not errno (I have no idea why). So when it says "No such file or directory", that's just the last error that was but in errno, not the error gethostbyname had. So you need to change line 845 to be

cout << "Unable to get the host name. Error: " << strerror(h_errno) << endl;


That should at least tell you why the error is occuring. If the error you get makes absolutely no sense, try changing strerror to hstrerror. I can't tell from the docs if strerror supports h_errno or not. (As a side note, this (at least the endl) should probably be incorporated into the main release as well)

This should solve your immediate problems, or at least put you on the right track to solving them. However, I think you're going to run into some more problems once you get these fixed (sorry). Here's the reason: when your world server connects to the eqemu.org login server, the login server gets your external IP address. That's great for other people (assuming you have the correct UDP ports forwarded, which it looks like you do), but isn't great for you. When you want to connect to your server, your EQ client will try to connect to port 9000 on your external IP. If you're lucky, that will get bounced back to your Linux world server. But even if that happens, when the world server responds back to the client, it will probably send it directly (not go through the router). The packet will get there, but the client will drop it because it came from the wrong IP (the internal IP instead of the external IP).

This is what the NAT patch that I wrote fixes, but it will only work (I think) if your NAT box is your Linux server. I'm not entierly sure about that (haven't tested it), but I don't think it would work in your situation (if it does, that would be great).

If you're really lucky, however, this may not be a problem. The Linksys NAT router _could_ do everything right to make this not a problem (basically, it would have to masquerade both ends ot the connection). However, this is so weird, I don't think it would do this on purpose (maybe on accident it would just happen to work).

If none of that works, I'm not sure what you can do. Probably the only thing left would be to add code to the server to fake the from field in the UDP packet (this is not pretty -- I already looked at it a little bit). I think it would do the trick, but it's ugly.

Do let me know how this turns out.

[cduckman]

I'm typing this as I read it and make modifications to my setup and the EQEmu code....

"A couple of questions:
1) What is the IP address of your Linux server? I assume it's 192.168.x.x and not your external IP. If that's true, I think this may cause some major problems when you go to try to play on your server (assuming your EQ client is on another 192.168.x.x IP)."

Server is 10.0.x.x, but I haven't even tried connecting yet since the server won't load. I'll keep your NAT post in mind. =) As far as the server loading and communication with the login server goes, I see how this might be a problem given it's using UDP.


"2) Have you tried using minilogin (on a windows box ) and using all internal IP addresses? This is a good first step to make sure that everything is working before you mess with the outside world."

Nope. I'm putting this server up and managing it remotely, and the only windows box where I'm doing this isn't mine. I never thought that would turn out to be a bad thing... :-P


"It doesn't like the lines in LoginServer.ini that have keys but no values (account= and password=) .... move them to the bottom of the file."

Done. I'm a comp sci major in college and I've had a few years (1+ on the job) programming experience, I should have taken a look at the code in more detail but I was in a hurry this morning (class, hehe). I didn't think of parsing problems when I ran across this first problem. I'm actually tempted to fix that one. =\ Maybe once I get all my classwork done for this semester. :-P

BTW, that fixed the problem of it not printing out the IP, and I'm assuming that means it read it in this time. :-P



"The error is coming from line 845 of zone/worldserver.cpp (the lack of a line break is a bug -- that line isn't printing out a newline character). That line is doing a gethostbyname() on the worldserver address that was passed on the commandline (the fourth argument)."

Thanks for looking that one up -- I did a grep and found the line, but didn't have the time to decipher where everything was coming from, I only gave it a glance.


"According to the man page for gethostbyname..."

Thanks for doing all this research for me.... I feel bad now :-(


Folks have been having problems with the fourth field when using 127.0.0.1, but they've been getting it to work by using localhost instead. Maybe this is related?

I just compiled and ran it (using hstrerror, strerror returned "operation not permitted). I still get an error, but it returns:
Unable to find host name. Error: Unknown host

I also added a line of code. Here's what I have.

cout << "Unable to get the host name. Error: " << hstrerror(h_errno) << endl;
cout << "Hostname: " << net.GetWorldAddress() << endl;

Note, for whatever reason, net.GetWorldAddress does odd things with the output to console if embedded in the first cout. *shrug*

It's printing out the normal error, and the address it's looking up, which I've tried as both 127.0.0.1 and localhost. Both return "Unknown host."


I've got a class schedule to take care of for next semester and then I'm going to play with this some more. For now, I'm clueless as to where to go with this. Unknown host looking up localhost/127.0.0.1? /boggle

Thanks in advance to anyone who plays with this. =)

[Trumpcard]

See if you have 127.0.0.1 localhost defined in your /etc/hosts file.

[cduckman]

Of course =)

[theCoder]

gethostbyname failing for 127.0.0.1 or localhost? I'm speechless. Something is wrong. Could you write a quick program that calls gethostbyname("localhost"), gethostbyname("127.0.0.1") and maybe some other hosts that should be found to make sure that gethostbyname does in fact work? I'm thinking that maybe the string containing the host name isn't being passed correctly (pointer problem of some sort?), but that doesn't seem very likely. The only reason I'm even thinking this is because you mentioned you had trouble printing out the worldaddress string.

Another thing you could try is running strace on it (I think strace zone should work). Maybe even cause the program to exit when that error occurs so you can clearly see the strace leading up to it. That might give some more insight into why it's failing.

[cduckman]

I got a sec to write this up.


#include <iostream.h>
#include <netdb.h>

void main()
{
if (gethostbyname("localhost") == NULL)
cout << "Localhost failed.\n";
else
cout << "Localhost worked.\n";
if (gethostbyname("127.0.0.1") == NULL)
cout << "127.0.0.1 failed.\n";
else
cout << "127.0.0.1 worked.\n";
}



Returns "worked" on both.
/boggle
/think
/boggle
/sigh
/cry
/camp


Edit:Er... Well.... I had indentations when I copied it in here... *laugh* too tired to fix it.

[cduckman]

When I get a chance today, I'm going to take a look at the source for this thing again and see what might be going on.

If anyone has any additional ideas or suggestions on anything I might look at outside of the worldserver.cpp file, please let me know, I'm pretty stumped. =\


Thanks again everyone! =)

[cduckman]

No luck! Yarg! This is ticking me off. =(


I'm out of options and clueless. I guess I'll wait for another full version to come out and try then, I've put too much time into this as it is. =(

If anyone can think of anything else, let me know, I'll see what I can do.

Thanks.

[theCoder]

It's too bad you weren't able to get this working. I really don't know what could be the problem (insert "it works on my machine" unhelpful statement here). The only thing I can think of is that the memory is being corrupted somehow, but I don't know how. It doesn't make a lot of sense, but it probably has a simple answer (like "what do you mean gets() can cause buffer overflows" or something like that).

But there are more important things in life besides Everquest (which is partly why I quit so long ago), so I completely understand you wanting to wait for a later version.

btw, if you ever do get it working, see my latest post in the NAT patch thread where I talk about using DNS instead of the NAT patch to work around the NAT problem. I think it would be helpful in your situation (if you ever get the emu working)

[cduckman]

Thanks Coder =) I haven't played with it much since I last posted that message. When I get the desire to go solo the sleeper with a level 60 wizard who has C3, heal, tashan and FS effect items, I'll take another look into it.

You folks take it easy, I'll let you know if anything else comes up.

[cduckman]

Well, I'm sitting here in Erudin playing on my brand new Erudite Wizard on my server, the Tower of Dalbane.

How? I should have done this the moment we figured out the exact problem. I just hardcoded getnamebyhost("localhost") and away it went, no problems.

Oh, and BTW everyone, I'm running a Linksys 4 port router with the latest (as of 2 months ago anyway) firmware. The server is running on a linux box under the linksys router, and all the IP settings for the EQEmu server are set to my external IP (the IP of my router on the outside world). The router has all the right ports forwarded, and it's handling things from the outside like a charm.

I have yet to test a connection within the LAN, but I'm betting that will work too, from what I've seen before with my counter-strike server and other things (apache logs, etc.).

Thanks to everyone for the help. I'm guessing that there was something out of place with my ini file? Does EQEmu not like linux endlines?

I might play around with it some more if anyone's interested to know. Hell, I might play around with it for fun.

Thanks again for all the help!!! =D