OpenEQ Loginserver

[daeken_bb]

I've been working on the loginserver for OpenEQ recently, most specifically the login-world communication, and I'm a bit confused.
From what I understand, the loginserver sends a user to world request to the worldserver, and the worldserver sends a response back to the LS. After that, I can't quite follow what's done. Can anyone clue me in on what to do next?

The current source is at http://home.archshadow.com/~daeken/ls.py.

Happy Hacking,
Lord Daeken M. BlackBlade
(Cody Brocious)

PS. This loginserver _will not_ work with the official EQ client. It's going to use a custom login protocol over TCP (with SSL for security reasons) rather than the hackish UDP-based protocol EQLive uses. I would rather it stay purely an OpenEQ LS rather than it be used as the base for an EQLive-compatible LS, but since it's under the GPL, you can do what you wish.

[smogo]

afaik, after LS send usertoword to the worldserver, nothing more happens between LS and world.

It only is a premliminary to client contacting the world, with the id and key that were sent in LS -> world usertoworld request

Basically :

1. client contacts LS, to auth
2. LS replies and tells client it's accountid 1234 and private key AbCdE
3. client tells the LS it wants to connect to world N
4. LS tells world N that it will be entered by client, id 1234, key AbCdE
5. client contacts world presenting id 1234 and key AbCdE

[daeken_bb]

Ah, ok, so my original thought was right. Problem though... I don't see a field for this key in the usertoworld request...

Mind pointing me in the right direction on that part? That should be all I need to finish up the rest of this LS

[smogo]

this is what LS sends to world (ServerOP_LSClientAuth opode) :

struct ServerLSClientAuth {
	int32	lsaccount_id;	// ID# in login server's db
	char	name[30];		// username in login server's db
	char	key[30];		// the Key the client will present
	int8	lsadmin;		// login server admin level
	sint16	worldadmin;		// login's suggested worldadmin level setting for this user, up to the world if they want to obey it
	uint32	ip;
};

As for what the server expects from client ... you should find it in the code, somewhere between common/servertalk.h and world/client.cpp, but, oh well it does not matter on LS design, so i didn't really care :(

alos, PCing is a must, unfortunatly :(

[daeken_bb]

Cool, thank you, I should be able to figure it out now

Hopefully I can get OpenEQ connecting to a world and zone server by next release

I'm currently reverse-engineering the Omens Of War file formats and having a decent degree of success... hoping to render basic geometry today >

[Elkay]

If it's not compatible with "EQ Live", I'm just wondering how it actually does function. Is it a custom EXE that we run to log in then? Just a bit confused, and a bit anxious too, because I'm looking to be able to host an EQEmu server (5.8 or greater) totally locally without depending on the official EQEmu Login Server.

[killspree]

OpenEQ is a whole new client to run the game on.

[Doodman]

Originally Posted by smogo

1. client contacts LS, to auth
2. LS replies and tells client it's accountid 1234 and private key AbCdE
3. client tells the LS it wants to connect to world N
4. LS tells world N that it will be entered by client, id 1234, key AbCdE
5. client contacts world presenting id 1234 and key AbCdE

Actually, you missed one step:
3-1. LS sends UserToWorldRequest to world for the user
3-2. World sends UserToWorldResponse indicating a response code (-3 world full, -2 user banned, -1 user suspended, 0 denied, 1 allowed)
3-3. LS responds to the "PlayEverquest" request to the client telling success/failure.

Then if the response back from world is 1 (or it's 0 and the user is an LS admin) then the LS sends UserToWorld to world like you state in 4.

Now, what world will do is check the users status and respond. If the server is locked and the users status is <100 then they get a denied (0) otherwise if their status >=0 they get an allowed.

[Doodman]

Here's a breakdown of what world will respond with:

-3 if world is at max capacity. Not sure were you can set max users, but I assume you can.
-2 if the status on the users account is -2 (banned)
-1 if the status on the users account is -1 (suspended)
0 if the server is locked and the status on the users account is < 100
1 otherwise

[Doodman]

Oh, and with official client once the LS->world handoff completes the client disconnects (sends the disconnect op code) from the login server.

When the client leaves world to return to LS, it logs in again.

[smogo]

hmm, that's a bit too high quality as for the service i've been trying to setup.

Actually i don't handle step 3.3, rather just paste a 1 response packet (always tell world accepts, the client eventually gets kicked or not depending on server allowance)

As for step 3.1, i was putting it in step 4 (so 3.1 and 3.2 would be 4.1 and 4.2)

.. this, unless i'm missing something, and got it working by chance. oops again

Thanks for heads up anyway. This will be added ito the next to next release

[Doodman]

Well, UserToWorldRequest is just asking if this user is allowed to join that world it is not the hand off using the key and such.

The final send from LS to world is actually the ServerOP_LSClientAuth, which is the actual hand off to world.

Step 3.1 is LS sending ServerOP_UsertoWorldReq and waiting for a ServerOP_UsertoWorldResp (step 3.2) from world.

But, the UserToWorldRequest/Respose pair is not required, if you skip it and just send ServerOP_LSClientAuth (like you are) it still works but you are relying on world to kick people that would normally not be allowed.

[Doodman]

Also, world does not check "locked" status of the server on LSClientAuth so users would be able to join locked servers.

I'd have to see if suspended/banned is checked on LSClientAuth or not, it might not be as world might assume it was checked on UserTotWorldRequest and would have already rejected banned/suspended accounts.

[Elkay]

Originally Posted by Doodman

Also, world does not check "locked" status of the server on LSClientAuth so users would be able to join locked servers.

I'd have to see if suspended/banned is checked on LSClientAuth or not, it might not be as world might assume it was checked on UserTotWorldRequest and would have already rejected banned/suspended accounts.

Curious on this myself. I have a locked server that I've watched a couple people log into from the console. =P

[smogo]

Prolly means their status is high enough to login through console.

LS does not interfere with console login.