I’ve been quite interested to play Lost Saga again lately, one of “bocil” game that still exists despite kids rarely went into internet café again.
Unfortunately, the experience is not that great, there are some cheaters that Gnjoy still struggling to handle and connection issues. The connection issues get worse and worse after the Cyber 1 Building Fire incident on 2nd December. So I had the idea to put their server on monitor (since they don’t have any status pages)
Here’s the status page: https://direb.us/lso-status
I’m using Uptimerobot to run the status page, as you can see on the URL, heheheh. One of my “friend” actually use this to monitor his ISP, and currently ranting the ISP for its worst downtime despite the corporate SLA contract. So… since I’m curious with the service, and wanted to test it, I decided to make Lost Saga’s Server as a real life example (alongside my other services and servers).
Getting IPs for the game is actually quite easy. Just start Wireshark then capture the communication. Getting the port is the one that are tricky. As far as I know, there’s case where the server may listen to port 80, but it can redirects the serve to another port for the actual communication. I’ve been told that this is called ephemeral port. So I have to keep that in mind.
Finding the Endpoint
There’s several request to HTTP server at the first of the program starts. So let’s skip the HTTP requests since those are most likely just a usual version check & update sequence. The one that we want to check are those that have unusually “pretty” port. Something like
After quick look, most server are on the
202.93.25.x IP, so i can just query TCP connection that are sent to IP in that
/24 range. and… whala, we got one IP and port there. We just need to rinse and repeat to find another endpoints.
I’m guessing you’ll ask “how did you know that certain IP is for what part in the game?”
Well, during the capture, I go to some rooms: plaza, battle, etc. So when I got that endpoint, I just need to remember what room I’m joining in order.
Oh, the reason why I find the TCP, and not UDP packets, is because UptimeRobots only supports TCP connections right now. I’m guessing that they use the TCP handshake to determine if such server up or not. So it’s not actually able to detect during-game performance, rather, its more like more general “Are you listening or not?” status. They do have specific service protocol on their monitoring service such as SMTP, etc, but since the protocol they used is proprietary, we’ll just take the easy path.
I’ve been told that most FPS games usually uses UDP for communication (i think because UDP can deliver packets quicker since it doesn’t care whether the client received the packets or not lol). In this particular case, I’m lucky that the server actually have TCP connection that I can use to test with.
Tuesday is maintenance day, or so, I’ve been told. So this will be great opportunity to test the bot, heheh.
During the maintenance period, the server has been… idk, restarted several times? The autostart were disabled so nobody can actually start the game(?) I don’t know, I’m just guessing wildly. But what I’m sure are, during the maintenance period, the bot can actually detects what’s happening (roughly) on the server.
The maintenance period starts at 09:00WIB to 14:00WIB, but there’s an upsie-daisie on 20:05WIB, noting that the connection to the server is not that stable, lol.
The night after maintenance session, there’s a downtime on the main website (gnjoy.id), i feel like there’s update to the web files on this time, or maybe just another server restarts.
So, to conclude the testing, I think the status page is able to (at least) inform my guild that Lost Saga is currently accessible or currently have dodgy connection or not.