What causes DC with others / while a party only?

[Zydee]

I have been debugging this issue with no end that causes players to DC completely back to their desktop with no message (ex: firewall; etc) error at all. The session just closes. I have checked everywhere in the server for instances of session close, but all handle it with an error popping up after (ex: firewall; etc).

The bug happens when players are in a party with each other and are training. They dc anywhere from every 1-20 minutes.

Things to mention are:
1. we do have custom skills
2. the server is based on a source that was re-written almost completely from moople (so uncommon things are still very possible)
3. players can go hours without dc while alone.

Thank you for your time! All help is appreciated.

 

[Meteorite]

What version is this?
If it only happens in a party, then it's a packet being broadcasted only to party members (the important distinction to make is that it's NOT a packet being broadcasted to the entire map).
Also do all of the party members d/c? Or all but one?

 

[Zydee]

What version is this?
If it only happens in a party, then it's a packet being broadcasted only to party members (the important distinction to make is that it's NOT a packet being broadcasted to the entire map).
Also do all of the party members d/c? Or all but one?

I believe it's with people in the map in general, so it should be a packet being broadcasted to the entire map as I have dced without actually being in the party itself (which is why I want to rule out party being the reason for DC).As for the number of disconnections, it seems to be people one by one, not on a group basis.

 

[Eric]

I believe it's with people in the map in general, so it should be a packet being broadcasted to the entire map as I have dced without actually being in the party itself (which is why I want to rule out party being the reason for DC).As for the number of disconnections, it seems to be people one by one, not on a group basis.

LOL this sounds EXACTLY like the bug I had when I updated Orion to v92. When people were in a party training, you'd dc randomly after some period of time. Just like you as well, it was only one person each time that disconnected, not everyone in the map or party. I never did figure the primary issue out, however I managed to track down the problem to be coming from mob controllers (which explains why only one of you dc -- probably the current controller? dunno). If you disable or comment out mob movement and try testing it, you shouldn't crash (at least this was my case). I forget if I ever changed back to v90 to confirm whether or not the issue was during updating, or during a rewrite of something. I was convinced that it was the client itself doing this from a CRC check or something I had missed. Let me know if you figure it out, would be funny if it's the same issue in my source as well lmao

 

[Zydee]

LOL this sounds EXACTLY like the bug I had when I updated Orion to v92. When people were in a party training, you'd dc randomly after some period of time. Just like you as well, it was only one person each time that disconnected, not everyone in the map or party. I never did figure the primary issue out, however I managed to track down the problem to be coming from mob controllers (which explains why only one of you dc -- probably the current controller? dunno). If you disable or comment out mob movement and try testing it, you shouldn't crash (at least this was my case). I forget if I ever changed back to v90 to confirm whether or not the issue was during updating, or during a rewrite of something. I was convinced that it was the client itself doing this from a CRC check or something I had missed. Let me know if you figure it out, would be funny if it's the same issue in my source as well lmao

I know this is going to sound really nooby, but I set a lot of break points and debugged the source and it always came down to a function called sessionClosed(IoSession session) inside of MapleServerHandler. I noticed this function is recursively called, but is never actually call externally. Which makes sense as the session closes, but I don't understand where or how this function is called if nothing calls this.

I noticed there was a call for session.close, especially around packet encoder and decoder, which could potentially make sense since it was a silent session close (no error after maple closed to desktop), but I set break points there too and it worked flawlessly. So all errors seem to be pointing back to this function.

I took a screen shot because formatting on rz didn't work out well. Hope you can read it.

 

[Umbreon]

You must be registered to see links

 

[Eric]

@Zydee As sad as using MINA in 2018 is, that method is what gets invoked when a session times out or disconnects from the server. You don't call this yourself, it's invoked in the background (from MINA) by the network acceptor that you've binded. Same thing goes for when sessions are opened/created. However, I hope you do realize that just because this is called, doesn't mean it was from the server. If it was closing your sessions from the server, then you'd be disconnected to the login server, not your client crashing completely. Instead, because the client is the one crashing you (not the server, but it is very likely caused by the packet received from the server), you're still disconnecting from the server which is why that method is being called. Any crash or disconnection detected, that method will be executed.

I thought I'd also mention that the reason I believed it was the client was because even if I was in a party by myself, AND I was alone on the server, I'd still come back to my client having crashed. The only difference is that rather than it happening very quickly when training with a party, it took an hour (or a few) before I had crashed.

Oh, and by the way, a good way to debug your client crashes in this case is to log the last ~10 or so packets, and print/log them or their opcodes. Then, log the packets sent at their locations and try disabling sending some of them to see if it prevents crashing. If one of them is the cause, try comparing packet structures or given values against the function in the client (IDA) to see if you missed something.