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
Code:
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.