Help Unknown packet header 45, 81 and 34 [PAY]

[Klaus 158]

Hello, my client is closing many times, mainly after a teleport or receiving a private message, when he clicks to open, the client is terminated. I don't have any new system related to packages with error, I've already checked variables and packages several times, compared with several other sources and I haven't had any success. I also searched and couldn't find anything about it. If anyone can help me, it doesn't have to be a fix, but where the problem is, I'd be very grateful. If need be, I'm willing to pay for the correction.

Here are some logs I saved:

Quote

 

Phase Game does not handle this header (header: 81, last: 45, 81)

528 21:55:26441 :: Phase Game does not handle this header (header: 34, last: 114, 34)
0528 21:55:26780 :: Unknown packet header: 101, last: 114 34

0530 21:48:11876 :: Phase Game does not handle this header (header: 34, last: 3, 34)
0530 21:48:12275 :: Unprocessed packet header 32, state Game

0530 21:48:12666 :: Unknown packet header: 182, last: 34 32

0805 10:17:49861 :: Phase Game does not handle this header (header: 34, last: 171, 34)
0805 10:17:50149 :: Unknown packet header: 103, last: 34 46

 

Obs.: I even found some things of corrections etc, but without success.

 

Edit: 34 is present in all errors basically, being the one that occurs most frequently (when receiving private message, pm)

 

Anyway, thank you so much in advance! =D

Edited August 6, 2022 by Klaus

[WeedHex 635]

Is it happening on a release server with players or just in developing?

[Klaus 158]

4 minutes ago, WeedHex said:

Is it happening on a release server with players or just in developing?

On both, but on the test server it is very rare, on the main server, with an average of 200 players, it happens on average 5/8 times a day, with at least 50% of players.

[enzi 840]

That is most common error when you are editing packet.h without really understanding what are you doing  My advice for you is fully compare packet.h from binary+game they must be same..

check for duplicates, check if you dont have something // in game but dont in binary, check if every packet is defined in right way in (PythonNetworkStreamPhaseGame/Item.cpp)

ex. if this packet in binary = 80 it has to be 80 in game too

HEADER_CG_GUILD								= 80,

as last that = 80 must be unique so you cant use it for another packet, but be carefull there are 2 types of headers CG and GC (if you use 80 in CG packets you are free to use same number in GC but you cant use same number in 1 type of packets)

ex. WRONG

HEADER_CG_GUILD								= 80,
HEADER_CG_WHEEL_DESTINY						= 80,

I hope this will helps, if it dont, insert here your packet.h files I will look at it

[Klaus 158]

up!

Update: When receiving a private message (whisper), the client randomly closes, if it is for an item with attributes/jewels, it seems to happen more frequently than just normal messages.

Pay for help!

[iMerv3 768]

On 8/10/2022 at 6:02 PM, enzi said:

That is most common error when you are editing packet.h without really understanding what are you doing  My advice for you is fully compare packet.h from binary+game they must be same..

check for duplicates, check if you dont have something // in game but dont in binary, check if every packet is defined in right way in (PythonNetworkStreamPhaseGame/Item.cpp)

ex. if this packet in binary = 80 it has to be 80 in game too

HEADER_CG_GUILD								= 80,

as last that = 80 must be unique so you cant use it for another packet, but be carefull there are 2 types of headers CG and GC (if you use 80 in CG packets you are free to use same number in GC but you cant use same number in 1 type of packets)

ex. WRONG

HEADER_CG_GUILD								= 80,
HEADER_CG_WHEEL_DESTINY						= 80,

I hope this will helps, if it dont, insert here your packet.h files I will look at it

The compiler won't let u using the same number in a switch. The problem he have is a dynamic packet size mismatch.

[Helia01 2125]

If all packets between server and client are ok. This behavior may occur due to an attack on the server. In this case, phantom packet errors may occur. (usually this headache is created by _IMPROVED_PACKET_ENCRYPTION_) But you can't just turn off this function. We will have to rewrite some part of the code in order not to get buffer errors.

If similar problems with packages occur on your local server, then this problem is precisely the difference between packages between the client and the server.

Edited November 20, 2022 by Helia01

[Mitachi 1454]

Well, there are a few things to consider:

• If the error occurs every time you perform a certain action, the problem is definitely in the packet in question.
• If, on the other hand, it doesn't always happen but the package in question is always the same, skip to the part where I talk about the sequence system
• The packet header number itself isn't a problem, packets have their own cases in a switch, if the case has the same number, the compiler will warn you.
• It's not just the packet header number that's the problem, packages are literally typed structs, like this:

/*
	We need to be sure that the data types used match
*/

// Server
typedef struct SPacketGCTest
{
	BYTE	bHeader;
	WORD	wSize;
} TPacketGCTest;

// Client
typedef struct SPacketGCTest
{
	BYTE	bHeader;
	int	wSize; // error, int <-> WORD are not the same.
} TPacketGCTest;

Usually the sequence system (or ENABLE_SEQUENCE_SYSTEM  if you using martysama) corrects for differences in packet weights automatically but I don't like it to be honest, I don't find a valid use for it today, perhaps once it could have been useful. Honestly I turned it off, removing it I noticed less random crashes.
TIP: If you have it enabled try disabling it, you will notice the error more easily.

I have also disabled _IMPROVED_PACKET_ENCRYPTION_ in my mainline (and not, he didn't cause crashes or at least I didn't notice).
But you have to change some things first, otherwise after some hours of activity you come across the sizebuffer error. PRO: More speed performance

34th packet are usually the HEADER_GC_WHISPER, do you have some custom system related? let me know.

*ending*
When it comes to mistakes of this kind, it is not black or white; there can be many reasons. I told you what I was going to do initially.

This guide can certainly be useful to you:

[Helia01 2125]

3 hours ago, Mitachi said:

Well, there are a few things to consider:

• If the error occurs every time you perform a certain action, the problem is definitely in the packet in question.
• If, on the other hand, it doesn't always happen but the package in question is always the same, skip to the part where I talk about the sequence system
• The packet header number itself isn't a problem, packets have their own cases in a switch, if the case has the same number, the compiler will warn you.
• It's not just the packet header number that's the problem, packages are literally typed structs, like this:

/*
	We need to be sure that the data types used match
*/

// Server
typedef struct SPacketGCTest
{
	BYTE	bHeader;
	WORD	wSize;
} TPacketGCTest;

// Client
typedef struct SPacketGCTest
{
	BYTE	bHeader;
	int	wSize; // error, int <-> WORD are not the same.
} TPacketGCTest;

Usually the sequence system (or ENABLE_SEQUENCE_SYSTEM  if you using martysama) corrects for differences in packet weights automatically but I don't like it to be honest, I don't find a valid use for it today, perhaps once it could have been useful. Honestly I turned it off, removing it I noticed less random crashes.
TIP: If you have it enabled try disabling it, you will notice the error more easily.

I have also disabled _IMPROVED_PACKET_ENCRYPTION_ in my mainline (and not, he didn't cause crashes or at least I didn't notice).
But you have to change some things first, otherwise after some hours of activity you come across the sizebuffer error. PRO: More speed performance

34th packet are usually the HEADER_GC_WHISPER, do you have some custom system related? let me know.

*ending*
When it comes to mistakes of this kind, it is not black or white; there can be many reasons. I told you what I was going to do initially.

This guide can certainly be useful to you:

Maybe my answer looked terrible. Since I use a translator.
Thank you for the detailed answer. I was too lazy to describe everything in such detail.