Can't log in with SoD client
 

So, I've set up a server on a arch linux machine (quad core) and compiled the server using -march=core2, sourced in my DB and updates from the SVN branch and am able to log in with Titanium clients, no problems. However, when I use my SoD client, it gets to Char Select (Can create a char) and then locks up. I see in my log file that the zone request is sent and acknowledged, and the zone boots up, but I'm never put into the zone. I see a couple of unknown opcode errors in the world debug log but I'm assuming these are "normal". I've modified the "expansion" variable to be 32767 but this didn't solve my issue. I did a make clean && make and the new compiles didn't help. I've fudged with just about everything I can think of, searched all over the forum, and can't get logged in with a SoD client (That I can log in to other servers with). I'm using the public login server (eqhost set to 5999, eqemu_config xml file set to 5998 (Won't connect on 5999)).

Any suggestions / pointers? I can post the output of any logs etc as needed.

Thanks in advance,
tbf

The clients supported by EQEmu will have one of the following build dates:

Code:
6.2 (Build Aug 4 2005 15:40:59)
Titanium (Build Oct 31 2005 10:33:37)
SoF (Build Sep 7 2007 09:11:49)
SoD (Build Dec 19 2008 15:22:49)
Underfoot* (Build Jun 8 2010 16:44:32)

check build version make sure you have applied all updates needed
for client.

The build date is fine, thanks for the tip. This is the standard "Steam" version of SoD, unpatched, and it's able to connect to other servers (Akka's Funhouse, Stormhaven) without incident. The world server correctly IDs the client as SoD. The specific opcodes that cause the hex dumps are 0x5bad and 0x5d24.

The server is running as "a_test_server00" in the EqEmu Public Login - if you have a known good SoD client could you try to duplicate the inability to launch a zone with it? I'm pretty sure the client is not at fault as I've used this exact client install with other servers but limiting issues can be a good thing.

Underfoot req client Build Mar 11 2010, Apr 14 2010

able to connect to other servers (Akka's Funhouse, Stormhaven)
check your opcode patch_SoD.conf

# Login opcodes
OP_SessionReady=0x0001
OP_Login=0x0002
OP_ServerListRequest=0x0004
OP_PlayEverquestRequest=0x000d
OP_PlayEverquestResponse=0x0022
OP_ChatMessage=0x0017
OP_LoginAccepted=0x0018
OP_ServerListResponse=0x0019
OP_Poll=0x0029
OP_EnterChat=0x000f
OP_PollResponse=0x0011

make sure your using port 5999

eqemulogin.ini

OPCodePathAndFileName=login_opcodes_Sod.conf

I don't know what the problem is, but I can confirm it is not your client. I logged in fine to your server using Titanium, but with SoD (Dec 19 2008 build), a trace shows the client sending OP_AckPacket and OP_ZoneEntry, but the server (zone) never responds (it should respond with OP_PlayerProfile).

I don't know if it is your -march setting bugging it, my Linux server (Gentoo, 32bit) is built with the default -march=i686

Derision, thank you for trying to log in with your client, independant verification of my "results" helps eliminate the client as a source of woe.

As far as core2 v. i686, one would think that it shouldn't matter (since at least to my rudimentary understanding of compiling it's just translating the C into the proper CPU operations, and the core2 instruction set being larger would just mean the code can run faster using the built in instructions instead of combinging instructions, yet I digress (and show my lack of C to binary knowledge ;p) - but I can't get this mamma jamma to compile with i686 - "CPU you selected does not support x86-64 instruction set". So I swapped the march to native, recompiled, same issue.

This all may stem from trying to compile in a x64 environment - but with everything compiling properly (only "standard" warnings) I'm hesitant to call it as such.

Now, opcodes. The patch_SoD.conf from SVN contained this:
So I put in what you reccomended, Noport, and full of hope that this was in fact my issue, logged in to my server, hit "Enter World" and was disappointed that it didn't work and I'm back to the beginning, except I know my client isn't at fault.

When you say set the port to 5999, you mean in the eqhost.txt file, and not the XML config (Couldn't connect to LoginServer on port 5999 in the XML), right? I have it set to 5999 in the eqhost.txt since I'm able to log into other servers with this client.

Maybe this is all a result of running this in a x64 environment. Are there other configuration values that would affect SoD clients only? Since the SVN-based patch_SoD.conf contained incorrect opcodes in the #login block, would there be other opcodes in there that would need to be changed? Does anyone have some insight into running this natively on x64 archictecture? Should I try to recompile using 32bit libraries?

As you might be able to tell from my rambling and circular logic, I'm frustrated all to hell with this issue, and I greatly appreciate all of your help in trying to get this sucker fully armed and operational.


Edit:
Is there a log directive that I can set to see the packets sent by the zone /world server? I'd like to know if I'm sending the OP_PlayerProfile packet or not (Would I need wireshark for this?)

I also went through the diffs on patch_SoD.conf and can't see why the opcodes listed in #login should need to be changed - any insight into why those four/five opcodes need to be changed from what's in the repo?

login.ini file should read :

listen_port = 5999

if you leave it set to port 5998 you'll never
get in with sod client.

by changing them opcodes as you listed was a good idea
if you didn't change them your client would be just
sitting there all day waiting.

you're only problem is server setup make a few changes
be up and running soon.

eqemu_config.xml
<port>5999</port>

make sure you restart eqemu server after changes.

By the way, I tried out a private Debian 64bit machine here at home and
I set the -march=native which compiled and had little problems with my
Underfoot client, but this was only tested on my lan.(client on windows box).

I was under the impression that the EQEmuLoginServer was for a private server, not for running through the public login server - is this not the case?


Edit: Huppy, in regards to -march=native, it compiled fine (After removing the ::pair issue), I mean by "same issue" the issue causing my SoD client to not connect.


As I look into it, there's an unknown opcode being registered before the tutorialb zone is loaded:

I see that the zone start and move procedures are still running, so I'm not sure this is relevant, just trying to wade through this a bit more. I also see that the world is trying to send the client to the external_ip of the server instead of local or loopback, is this the desired behaviour? Is the opcode at 0x0924 really the OP_PlayerProfile packet?

I always get those errors when my client connects, but still no problems.
I'm not exactly sure of your problem, but I've never had to change anything
except thesettings in the xml config and the login config.

I was under the impression that the EQEmuLoginServer was for a private server, not for running through the public login server

I can run a minlogin client for my own testing nobody can see except me
I can run a private server without using this server and change the port numbers.
I can run a public server so everyone here can login.

I have sat for hours reading and take notes and keep them in text documents.

Yes, EQEmuLoginServer is for private. Even if you want to allow outside
connections from friends. But in your variables table in the database, you
need to either have it set to minilogin (f thats what you are using) or for
anything else,(EQEmuLoginServer or emulator.net) it has to be set public.
But I think you have that knowledge already.
This is my login.ini file :

[database]
host = 127.0.0.1
port = 3306
db = peqlogindb
user = root
password = xxxxxx
subsystem = MySQL

[options]
unregistered_allowed = TRUE
reject_duplicate_servers = TRUE
trace = FALSE
world_trace = FALSE
dump_packets_in = FALSE
dump_packets_out = FALSE
listen_port = 5999
local_network = 192.168.1

[security]
plugin = EQEmuAuthCrypto
mode = 5

[Titanium]
port = 5998
opcodes = login_opcodes.conf

[SoD]
port = 5999
opcodes = login_opcodes_sod.conf

[schema]
account_table = tblLoginServerAccounts
world_registration_table = tblWorldServerRegistration
world_admin_registration_table = tblServerAdminRegistration
world_server_type_table = tblServerListType

Thanks Huppy - I'm trying to use the eqemulator login server - I don't even have the EQEmuLoginServer compiled (I shouldn't need it nor the associated login.ini files if I'm using the eqemulator login server, correct?)

I've tried compiling with different flags, modified opcodes, and sacrificed an old Celeron to the von Neumann Gods to no avail. Titanium - no problem. SoD/Underfoot, no dice (Can create a character in SoD, just no actual logging in to a zone).

The LoginType variable is set to 'public' in eqemu.variables

Does the Expansions variable in eqemu.variables actually mean anything these days?

Some Pastebins of Logs:

eqemu_debug_world: http://pastebin.com/fUcfqJbF
eqemu_debug_zone: http://pastebin.com/Yi97LLYj
eqemu_debug_XXXXX: http://pastebin.com/xhFYnDz5
eqemu_zone: http://pastebin.com/WZ0tAaAB
world: http://pastebin.com/bQ6fFYMU

Configs:
patch_SoD.conf: http://pastebin.com/WXF2wqne
eqemu_config.xml: http://pastebin.com/Biin9MwD

make sure patch_SoD.conf and patch_Underfoot.conf
and patch_HoT.conf edit and change:

Don't use # in front of opcodes that means your remarking from it reading
that part of the file. only where # Login opcodes is
# Login opcodes
OP_SessionReady=0x0001
OP_Login=0x0002
OP_ServerListRequest=0x0004
OP_PlayEverquestRequest=0x000d
OP_PlayEverquestResponse=0x0022
OP_ChatMessage=0x0017
OP_LoginAccepted=0x0018
OP_ServerListResponse=0x0019
OP_Poll=0x0029
OP_EnterChat=0x000f
OP_PollResponse=0x0011

Note: make sure opcodes.conf 17kb in size
don't use opcodes.conf with just login opcodes.

login_opcodes.conf file should read :

#EQEmu Public Login Server OPCodes
OP_SessionReady=0x0001
OP_Login=0x0002
OP_ServerListRequest=0x0004
OP_PlayEverquestRequest=0x000d
OP_PlayEverquestResponse=0x0021
OP_ChatMessage=0x0016
OP_LoginAccepted=0x0017
OP_ServerListResponse=0x0018
OP_Poll=0x0029
OP_EnterChat=0x000f
OP_PollResponse=0x0011


login_opcodes_sod.conf file should read :

# Login opcodes
OP_SessionReady=0x0001
OP_Login=0x0002
OP_ServerListRequest=0x0004
OP_PlayEverquestRequest=0x000d
OP_PlayEverquestResponse=0x0022
OP_ChatMessage=0x0017
OP_LoginAccepted=0x0018
OP_ServerListResponse=0x0019
OP_Poll=0x0029
OP_EnterChat=0x000f
OP_PollResponse=0x0011

eqemulogin.ini file should read :
Port=5999
DumpPacketsIn=true
DumpPacketsOut=true
Trace=false
DatabaseServerName=localhost
DatabaseCatalogName=peqlogindb
DatabaseUserName=xxxxxxxxxx
DatabaseUserPassword=xxxxxxxx
OPCodePathAndFileName=login_opcodes_Sod.conf

Does the Expansions variable in eqemu.variables actually mean anything these days?

Accessible expansions for all players.

0 - Classic
1 - Ruins of Kunark
2 - Scars of Velious
4 - Shadows of Luclin
8 - Planes of Power
16 - Legacy of Ykesha
32 - Lost Dungeons of Norrath
64 - Gates of Discord
128 - Omens of War
256 - Dragons of Norrath
512 - Depths of Darkhallow
1024 - Prophecy of Ro
2048 - Serpent's Spine
4096 - The Burried Sea
8192 - Secrets of Faydwer
=====
16383 upto Sof

All Expansions combined = 16383 so does 32767 = Sod or Underfoot
i'm working with exp Hot with client.

make sure you restart eqemu server after changes.

I had the same issue on a 64-bit Ubuntu build. I set -march=native and removed -O from the makefiles and that resolved it. From what I can remember, someone said it's an issue with std::stringstream and optimization in gcc.

As an aside, I only had to jack with opcode files when I was using minilogin with SoD. I'm using the files as they are included in the most recent source.