Friends Disconnect When Zoning

whiteknight33 · #1 07-04-2019, 04:59 AM

I had made a post in the Linux section last week when I received an error message when connecting from an outside connection. I had thought it was an isolated incident, but tonight I was attempting to play with a friend. He could connect to my server with ease, but every time he went to zone somewhere, the server would crash him out with the following code:

Code:

[Error] GetAuth() returned false kicking clientLoginserver:  		
Client disconnected (cs=d): No name

I was hoping that someone could tell me what this means and if there is a way to fix it? It's pretty annoying that he can't zone anywhere without crashing.

whiteknight33 · #2 07-04-2019, 09:39 PM

Just to elaborate on what's happening here...

My friend and I logged into this server to play. Me, connected on my local LAN, I can play with no issues at all.

He made a level 1 Iksar Beastlord. Everything was fine for him until he tried to zone from Cabilis into Field of Bone. At that point, he was disconnected and sent back to the server selection screen. The Linux terminal gave the error above. My friend attempted to reconnect, but the terminal kept producing that error and I had to reboot the server in order for him to reconnect.

Once he reconnected, he was in the Field of Bone and the game was working great for him. We played for a while, then when the time came to go to Plane of Knowledge for Spells and Kurn's Tower for more XP, he was disconnect every time he had to zone (with the above error in the terminal) and I had to reboot the server each time in order for him to reconnect and play.

Every time he reconnected, he would be in the zone he had been trying to get into when he crashed to server select.

Does anyone know what might be causing this? The only place I could find the error message was inside of the client_process.cpp in the zone folder... But I'm not sure if that's telling the client to crash because of the no name thing or if it's just the script to produce the warning in the terminal.

Obviously I've searched these forums thoroughly... And I can't find a fix for this. Any help would be greatly appreciated... We'd love to keep playing, but the constant reboots really suck.

**Uleat** · #3 07-04-2019, 09:54 PM

That's definitely a 'kick' action from the server.

Did you add the

Code:

'Loginserver:  		
Client disconnected (cs=d): No name'

portion manually?

Or did the console print it like that?

(Not sure why authentication would fail on zone change if it didn't while logging in initially.)

whiteknight33 · #4 07-04-2019, 10:02 PM

Quote:

Originally Posted by Uleat

That's definitely a 'kick' action from the server.

Did you add the

Code:

'Loginserver:  		
Client disconnected (cs=d): No name'

portion manually?

Or did the console print it like that?

(Not sure why authentication would fail on zone change if it didn't while logging in initially.)

That's exactly how the console showed it. I copy and pasted it from the Linux machine to here.

Is there a way to disable authentication on zone changing?

Also, just in case this helps at all... here is the dbg log from the disconnecting client.

Code:

[Thu Jul 04 23:41:04 2019]00392:Zone Connect -- 2 -- Sending MSG_EQ_ADDPLAYER
[Thu Jul 04 23:41:05 2019]00393:Networking: connection terminated [client:DisconnectReasonOtherSideTerminated,server:DisconnectReasonNone]
[Thu Jul 04 23:41:05 2019]00394:disconnected at C:\p4\EverQuest\live\EverQuest\EverQuest.cpp:17949 (char. select) DisconnectReasonOtherSideTerminated,DisconnectReasonNone

Just because I had a little extra time, I backed up everything and did a clean install of Akkadius' Linux Installer on a clean install of Ubuntu 18.04 LTS. Then I restored my database and my eqemu_config file and login.ini.

I then tested everything by mobile hotspotting onto my server from the outside connection... I'm still having this issue. I even tested both the RoF2 and Titanium clients. It's happening with both on zoning. So I'm assuming it must be something in my configuration is borked for some reason.

whiteknight33 · #5 07-08-2019, 02:59 AM

I've been trying non-stop to fix this issue. My latest effort was to reinstall Ubuntu 18.04 LTS and download the server install from scratch. This time, I didn't restore my database or anything, I tried with the vanilla version of Akkadius' Linux installer. Even with a fresh install, this error persists.

Code:

[Zone Server] Time Broadcast Packet: EQTime [03:00 pm]
[Error] GetAuth() returned false kicking client
Client disconnected (cs=d): No name
[Login Server] New SoD client connection from 672705190:27430		
[Login Server] Application packet received from client (size 14)
[Login Server] Session ready received from client.
[Login Server] Application packet received from client (size 12)	
[Login Server] Client disconnected from the server, removing client.

Either I'm missing something here, or maybe this is an issue with the Linux version of part of the installer? I'm assuming the "zone" part, since this 'kick' occurs when zoning.

whiteknight33 · #6 07-08-2019, 04:22 AM

As another test, I switched from Ubuntu 18.04 LTS to Fedora 30, thinking maybe a .RPM based Linux system might have a different result (for some reason) and... Nope. In my experience, I've been able to reproduce this error 100% of the time when connecting from an outside connection.

Code:

[Status] Starting File Log 'logs/nexus_version_0_inst_id_0_port_7001_3776.log'
[Zone Server] Time Broadcast Packet: EQTime [06:42 pm]
[World Server] (Testchar) Zoning to nexus (Zone ID 152: Instance ID: 0) 
[Error] GetAuth() returned false kicking clientLoginserver:	
Client disconnected (cs=d): No name
[Login Server] New SoD client connection from 1327016614:27435		
[Login Server] Application packet received from client (size 14)
[Login Server] Session ready received from client.

I've tried changing every setting I can find, reinstalling my machine, and even changed OS versions, but I can't seem to fix this error.

Can anyone confirm that they're running a Linux version of EQEmu that does not have this error when someone from an outside connection tries to zone? (And maybe share which version of Linux you're running.)

phantomghost · #7 07-08-2019, 05:42 AM

Is your friends client in program files?

Maybe similar to p99 where you DC Everytime you zone if client is in program files or program files (x86).

Couldn't find the issue on p99 but I remember looking it up years ago.. here it is on Reddit

https://www.reddit.com/r/project1999..._load_game_up/

whiteknight33 · #8 07-08-2019, 08:59 AM

Quote:

Originally Posted by phantomghost

Is your friends client in program files?

Maybe similar to p99 where you DC Everytime you zone if client is in program files or program files (x86).

Couldn't find the issue on p99 but I remember looking it up years ago.. here it is on Reddit

https://www.reddit.com/r/project1999..._load_game_up/

Good suggestion to try, but in this case the files are in a folder on the desktop, and the client itself isn't crashing. In fact, the dbg log (client side) says there is no reason provided for the kick. lol.

Code:

[Thu Jul 04 23:41:04 2019]00392:Zone Connect -- 2 -- Sending MSG_EQ_ADDPLAYER
[Thu Jul 04 23:41:05 2019]00393:Networking: connection terminated [client:DisconnectReasonOtherSideTerminated,server:DisconnectReasonNone]
[Thu Jul 04 23:41:05 2019]00394:disconnected at C:\p4\EverQuest\live\EverQuest\EverQuest.cpp:17949 (char. select) DisconnectReasonOtherSideTerminated,DisconnectReasonNone

I have a very limited knowledge of programming and Linux, but from what the terminal is saying (and what Uleat posted above) it looks like players are authenticated when they first log in, then the server removes their authentication every time they try to zone and gives them the boot.

I tried tinkering around in the server files myself and the only place I found "Auth" mentioned was inside of the zone folder client_process.cpp I was able to find the exact error message I was being given. From what I read there, it looked like it was triggered by client.cpp... So I opened client.cpp and I was able to find something like (zone)->RemoveAuth... So I tried tinkering around with it myself and removing that line and substituting it. The results were if I tried to zone after that, it would warp me under the PoK stone/book I tried to use and it wouldn't actually zone me anywhere. So, for whatever reason, I think that line needs to be there or I didn't replace it with the "right" code.

**Akkadius** · #9 07-08-2019, 03:57 PM

This is when you're using your own Loginserver, correct?

whiteknight33 · #10 07-08-2019, 04:32 PM

Quote:

Originally Posted by Akkadius

This is when you're using your own Loginserver, correct?

Yes. I ran the script you posted to make sure that Linux installed the loginserver properly.

**Akkadius** · #11 07-08-2019, 04:37 PM

Quote:

Originally Posted by whiteknight33

Yes. I ran the script you posted to make sure that Linux installed the loginserver properly.

Yeah, the reason why loginserver is not bundled by default is because the code is a mess and setting it up / using it is not intuitive

Ironically I've spent 3 solid days rewriting it top to bottom and probably cleared up any authorization issues you may be seeing. I'll be providing a conversion script to migrate to the new schema and you can try it out then. Keep a look out for the changelog

whiteknight33 · #12 07-08-2019, 05:02 PM

Quote:

Originally Posted by Akkadius

Yeah, the reason why loginserver is not bundled by default is because the code is a mess and setting it up / using it is not intuitive

Ironically I've spent 3 solid days rewriting it top to bottom and probably cleared up any authorization issues you may be seeing. I'll be providing a conversion script to migrate to the new schema and you can try it out then. Keep a look out for the changelog

Okay. Whew. You're my hero man. I've used your Windows Server in the past and never had these issues... I'm newer to Linux and I was just figuring that I had to be doing something horribly wrong on my end. I thought for sure that switching to Fedora 30 was going to fix it though. I thought maybe it was an Ubuntu-exclusive problem.

Do you have any ETA as to when the new schema will be available?

Not trying to rush you or anything, I just want to let my friend know when we can play again and hopefully he can stay connected this time. Lol

**Akkadius** · #13 07-08-2019, 05:18 PM

Today, I'm working on finishing it all up now. Doing a few conversions and additional testing

Also, PEQ and EZ run on Debian FWIW

whiteknight33 · #14 07-08-2019, 05:23 PM

Quote:

Originally Posted by Akkadius

Today, I'm working on finishing it all up now. Doing a few conversions and additional testing

Also, PEQ and EZ run on Debian FWIW

Awesome. From first hand experience, EQEmu Linux runs equally as well on Ubuntu 18.04 LTS and Fedora 30. Ubuntu 18.10 changed something with quests though because quests/hails do not work properly on Ubuntu 18.10 or 19.04.

I haven't tried Debian proper, but I might... Once I get everything working I'm going to pick a version of Linux to stick with.

So once you change this, if I do another clean install, I'll get the new loginserver with that, right? Probably going to change Linux distros again anyway.

**Akkadius** · #15 07-08-2019, 05:26 PM

Quote:

Originally Posted by whiteknight33

Awesome. From first hand experience, EQEmu Linux runs equally as well on Ubuntu 18.04 LTS and Fedora 30. Ubuntu 18.10 changed something with quests though because quests/hails do not work properly on Ubuntu 18.10 or 19.04.

I haven't tried Debian proper, but I might... Once I get everything working I'm going to pick a version of Linux to stick with.

So once you change this, if I do another clean install, I'll get the new loginserver with that, right? Probably going to change Linux distros again anyway.

Debian 10 and latest Ubuntu have the same issue, they share a similar package release stream since Ubuntu streams from Debian