TFS 1.X+ Problem with maxpacketspersecond

[Thorn]

Hello guys, i have the most annoying problem with this maxpacketspersecond, here is the explanation...

Once upon a time, i had 50 max packets per second, so players wont get disconnected when spamming keys or whatever, but that came with a high price, a problem that in otclient when ppl logged in, they only cna move one sqm and then they get disconnected, and in tibiaclient its a crash

so well i reduced the number to 25 instead of 50, but the problem continues and my players now are getting kicked very often, i have no idea how can i solve this D:

does anyone now what could i do?? :/!!!

 

[Thorn]

That still doesn’t answer the question xd
We need more info to be able to help you
Also website load fine while the feeze happens?

sorry i didnt get the question, actually i never tried using the website when this happens, im always in a crazy hurry to reset the server

 

[jigsaw]

sorry i didnt get the question, actually i never tried using the website when this happens, im always in a crazy hurry to reset the server

I think that he want to know ifthe website goes off when the server freezes.

 

[Thorn]

I think that he want to know ifthe website goes off when the server freezes.

yeah i have no idea, havent tested that yet, i will try next time this happens, should be tomorrow >.<

 

[SpiderOT]

when this freeze occurs again open terminal and check CPU usage for webserver, mysql and tfs

 

[Thorn]

when this freeze occurs again open terminal and check CPU usage for webserver, mysql and tfs

Okeeeeeey this just happened and had a chance to see these things:
-Website works fine while this error is happening.
-Cpu usage is normal and everything else also normal.

and im using 30 max packets per second, also tried 25 but this happens anyway :/

 

[Nekiro]

Okeeeeeey this just happened and had a chance to see these things:
-Website works fine while this error is happening.
-Cpu usage is normal and everything else also normal.

and im using 30 max packets per second, also tried 25 but this happens anyway :/

This is otc issue, your otc is spamming packets and thats why you get this problem, because if you use cip client it's all ok. So yeah there is nothing to fix in the source, you should rather fix your otc.

 

[Thorn]

This is otc issue, your otc is spamming packets and thats why you get this problem, because if you use cip client it's all ok. So yeah there is nothing to fix in the source, you should rather fix your otc.

All i know is that cip client doesnt kick players when spamming hotkeys and that it crashes when this problem happens, but i dont know if all my players were using tibiaclient from the start, this wouldn't happen, idk that, but thanks man, i will investigate if this is otc fault.

 

[Keal Atis]

You should register (add it in tfs source logger or something) what packets players are sending, maybe it will help you with fixing this issue.

 

[Sarah Wesker]

that problem I solved it, increasing the packages to 750

 

[Sun]

that problem I solved it, increasing the packages to 750

That's not really a solution. Maxpacketspersecond provides security against dos attacks.
The more you increase it, the more vulnerable your server will be.

@Thorn
I cannot see how increasing the limit to 50 would cause your client to crash.
Since you are merely increasing the allowed number of packets a player can send within 1 second before getting kicked.
Perhaps you've done some other edits or maybe jumped to conclusions too soon?

@topic
If I remember correctly mark mentioned that shadowcores was configured to allow up to 80 packets per seckond.

In my own far-fetched opinion the best solution would be to configure a custom client with exhaustion between actions.

 

[Sarah Wesker]

That's not really a solution. Maxpacketspersecond provides security against dos attacks.
The more you increase it, the more vulnerable your server will be.

@Thorn
I cannot see how increasing the limit to 50 would cause your client to crash.
Since you are merely increasing the allowed number of packets a player can send within 1 second before getting kicked.
Perhaps you've done some other edits or maybe jumped to conclusions too soon?

@topic
If I remember correctly mark mentioned that shadowcores was configured to allow up to 80 packets per seckond.

In my own far-fetched opinion the best solution would be to configure a custom client with exhaustion between actions.

in my case, I need to increase it.
and it does not make it more vulnerable, everything depends on how much each player needs
if I put 50, with 2 spells that the player uses, throws bug
because it is a fast game. without exhausted

 

[Thorn]

That's not really a solution. Maxpacketspersecond provides security against dos attacks.
The more you increase it, the more vulnerable your server will be.

@Thorn
I cannot see how increasing the limit to 50 would cause your client to crash.
Since you are merely increasing the allowed number of packets a player can send within 1 second before getting kicked.
Perhaps you've done some other edits or maybe jumped to conclusions too soon?

@topic
If I remember correctly mark mentioned that shadowcores was configured to allow up to 80 packets per seckond.

In my own far-fetched opinion the best solution would be to configure a custom client with exhaustion between actions.

I dont know either :/ all i know is if i increase the packets, the faster this problem happens, crash on tibiaclient and lost conection with otclient :/ i use original tfs with some custom modifications :/

 

[SpiderOT]

Okeeeeeey this just happened and had a chance to see these things:
-Website works fine while this error is happening.
-Cpu usage is normal and everything else also normal.

and im using 30 max packets per second, also tried 25 but this happens anyway :/

That makes us exclude dos attacks, therefore i doubt it's related to maxpackets
does it happen to all players or in a specific area?
what error do you get when you try to reconnect again with otclient? terminal error (ctrl+t) would be better.

 

[Madzix]

To fix the client debug you need edit sources(however if you send that large packet as "single packet" for ex. sms shop, market you still get debug because of desynchronization).
Networkmessage.h:

Spoiler

change:

enum { MAX_BODY_LENGTH = NETWORKMESSAGE_MAXSIZE - HEADER_LENGTH - CHECKSUM_LENGTH - XTEA_MULTIPLE };

to:

enum { MAX_BODY_LENGTH = NETWORKMESSAGE_MAXSIZE - XTEA_MULTIPLE };

change:

enum { MAX_PROTOCOL_BODY_LENGTH = MAX_BODY_LENGTH - 10 };

to:

enum { MAX_PROTOCOL_BODY_LENGTH = MAX_BODY_LENGTH - 16 };

Networkmessage.cpp:

Spoiler

In function:

void NetworkMessage::addPaddingBytes(size_t n)

change:

if (!canAdd(n))

to:

if ((n + position) >= NETWORKMESSAGE_MAXSIZE)

This should allow you to "correctly" send your packet however if the packet itself is big enough to overrun buffer you still get debug.

If you use old client for ex. 8.6 you might need to change the variable of NETWORK_MAX_SIZE in const.h from 24590 to 16390.

 

[Thorn]

That makes us exclude dos attacks, therefore i doubt it's related to maxpackets
does it happen to all players or in a specific area?
what error do you get when you try to reconnect again with otclient? terminal error (ctrl+t) would be better.

this happens to everyone, including me, in all of the map, i havent checked terminal tho

To fix the client debug you need edit sources(however if you send that large packet as "single packet" for ex. sms shop, market you still get debug because of desynchronization).
Networkmessage.h:

Spoiler

change:

enum { MAX_BODY_LENGTH = NETWORKMESSAGE_MAXSIZE - HEADER_LENGTH - CHECKSUM_LENGTH - XTEA_MULTIPLE };

to:

enum { MAX_BODY_LENGTH = NETWORKMESSAGE_MAXSIZE - XTEA_MULTIPLE };

change:

enum { MAX_PROTOCOL_BODY_LENGTH = MAX_BODY_LENGTH - 10 };

to:

enum { MAX_PROTOCOL_BODY_LENGTH = MAX_BODY_LENGTH - 16 };

Networkmessage.cpp:

Spoiler

In function:

void NetworkMessage::addPaddingBytes(size_t n)

change:

if (!canAdd(n))

to:

if ((n + position) >= NETWORKMESSAGE_MAXSIZE)

This should allow you to "correctly" send your packet however if the packet itself is big enough to overrun buffer you still get debug.

If you use old client for ex. 8.6 you might need to change the variable of NETWORK_MAX_SIZE in const.h from 24590 to 16390.

Thanks man! im gonna try this!!