The Mana World Forums

I've noticed that char-server can stop working using only one user account.
There's how I did it:
1) After do login, I just send a loop with CMSG_CHAR_SELECT packets (0x0066) choosing the same char slot. The char-serv window got flooded with Character selection notifications.
2) While the loop is running, the char-serv cann't authenticate new users because is busy with the char select request

I did the test in localhost and tmw server and both were vulnerable. PoC >

please refrain from "testing" vulnerabilities on the production server and only do so locally
the version of tmwAthena in use isn't any different from the version available on GitHub so anything that works locally would work in production
it's not nice to affect other users with downtime caused by your actions

There's a lot of variables (RAM, procesator, users connected) that I can't reproduce in my testing environment, but I got the idea:
Testing bugs on production is as bad as abuse GM commands on production, We all learned that this year

I found a new way to crash char-server, but this time only test it on localhost:
1) I send a loop with CMSG_LOGIN_REGISTER packets (0x0064) with a valid username.
login-serv start showing a "being read" with a random number and finally go decreasing. When reached "being read 0" the players cann't access their character slot, and a new error warning shows up.
"ERROR: Unknown char-server failure"

Please do not do anything that may affect uptime in production.


tmwAthena is a very buggy mess. The snapshot taken was from eAthena when it was in the middle of a major refactoring, and for the longest time we weren't even able to troubleshoot the source in proper encoding. Now, the comments are encoded correctly, they just happen to still be Japanese.

While some efforts (including some fairly big ones) have been made to limit the worst exploits and troubles, tmwAthena remains fairly easily crashable. The long term plan (when it involved still having a server component at all) has always been to get away from tmwAthena and move to some more maintainable server platform, whether that be tmwserv, manaserv, or an updated hercules variant.


I'm not really sure what you're hoping to achieve by pointing out these problems in particular? Development time from the old tmwAthena devs has become quite limited, so unless you're planning on fixing them yourself (which would certainly be more than welcome, and we might be able to offer guidance if you're chasing after anything in particular) the odds of any given problem getting fixed quickly is pretty low.

If you're looking to explore what happens over connections with latency, you can always set up your client connections to happen over a different network namespace, bridged with a custom qdisc for whatever characteristics you want to replicate (delay, packet loss, reordering, corruption, whatever you want). Or if you really want to test things over global internet conditions, you might find it useful to run the server on a VPS somewhere. Keep in mind that the recent write buffer escapades meant 50 sockets expanding their write buffer sizes to 134217728 bytes all at once, for a total of needing to be able to send nearly 7 gigabytes in the space of less than two seconds (which is still ignoring all the other sockets which were increasing their write buffers to abnormal sizes that hadn't quite hit that figure), so you might want to pay careful attention to the bandwidth/abuse policies of any potential provider and their upstreams before taking that route.


---Freeyorp

playerone wrote: ↑28 Dec 2018, 23:09 Testing bugs on production is as bad as abuse GM commands on production, We all learned that this year

This is the type of testing that is done locally or left for developers to do. Many things can be problematic for this delicate server, commands abuse is rare and usually accidental if causing crashes. This was not accidental. Please do this kind of testing locally.

WildX wrote: ↑29 Dec 2018, 20:00This is the type of testing that is done locally or left for developers to do.

The harsh truth is: no way networking service available to general public can count on it to happen. And I do think world is better place to live when people stick to "responsible disclosure" approach instead of wrecking chaos. And devs better to stay sharp and react on bug reports reasonably rather than count on non-realistic assumptions like "left for developers". Should project be anyhow alive, people could and eventually would poke it with a stick. That's the way this world works.

Freeyorp101 wrote: ↑29 Dec 2018, 07:22Keep in mind that the recent write buffer escapades meant 50 sockets expanding their write buffer sizes to 134217728 bytes all at once

If that refers to kernel-side socket buffers, these are tuneable if I remember, no?

huge memory usage is not on kernel, but in user space
if buffer too small, tmwa double it in size, and probably never decrease in size.