character getting stuck v146

[noviceboy55]

Source used : v146 arcenis

Basically when the "quit game" button is clicked, the character is not disconnected from the game but the client gets taken back to the login page. I added debug messages to the disconnect method under mapleclient and realised that it was completely unused when the "quit game" button is clicked

So is there a file in the server source somewhere where the functions of the "Quit Game" button is actually written? Or at least may I know what's the header for it?

 

[Eric]

If quitting the game has a header, then log all your packets and debug it. Your issue, however, sounds like a problem with your server's socket acceptors and MINA not properly calling sessionClosed. If your disconnect method doesn't get printed at all, then it's definitely an issue with sessionClosed because that is what calls client.disconnect() once triggered.

 

[noviceboy55]

Added System.out.println("test"); to multiple sections of sessionclosed in MapleServerHandler and none of them showed up in console when "Quit Game" was clicked.

Current sessionclosed

@Override
    public void sessionClosed(final IoSession session) throws Exception {
        final MapleClient client = (MapleClient) session.getAttribute(MapleClient.CLIENT_KEY);
        System.out.println("sessionClosed start");
        if (client != null) {
            byte state = MapleClient.CHANGE_CHANNEL;
            if (Log_Packets && !LoginServer.isShutdown() && client.getPlayer() != null) {
                state = client.getLoginState();
            }
            if (state != MapleClient.CHANGE_CHANNEL) {
                log("Data: " + numDC, "CLOSED", client, session);
                if (System.currentTimeMillis() - lastDC < 60000) { //within the minute
                    numDC++;
                    if (numDC > 100) { //100+ people have dc'd in minute in channelserver
                        System.out.println("Writing log...");
                        writeLog();
                        numDC = 0;
                        lastDC = System.currentTimeMillis(); //intentionally place here
                    }
                } else {
                    numDC = 0;
                    lastDC = System.currentTimeMillis(); //intentionally place here
                }
            }
            try {
                FileWriter fw = isLoggedIP(session);
                if (fw != null) {
                    fw.write("=== Session Closed ===");
                    fw.write(nl);
                    fw.flush();
                }

                client.disconnect(true, true);
                System.out.println("After client.disconnect");
            } finally {
                session.close();
                session.removeAttribute(MapleClient.CLIENT_KEY);
                System.out.println("After sesson close");
            }
        }
        super.sessionClosed(session);
        System.out.println("After super session close");
    }

Basically right now if I logged back onto game on another account, I will see the former account's character where it was when I clicked "quit game"

and, the packet on the console is actually reset_screen

Update

Closing the "flawlessrelay" AKA v146 client i'm using sent all the debug messages onto the console, for both disconnect in mapleclient and sessionclosed in mapleserverhandler

 

[noviceboy55]

As an extension of the previous problem and also a bump, I realised that I consistently crash when doing bosses (horntail, arkarium, pinkbean, von leon etc). It's kind of a weird crash issue since it seems to have something to do with the time you stay in the map or the number of attacks you used on the boss. Like I can complete those bosses if I have high damage and kills very fast but is more likely to crash when I take very long (worse on bowmaster due to number of attacks). I would think that it is an issue with fastattack but I am not completely sure if that actually just dcs people.

Also when the client crashes this way, the character still gets stuck in-game even if the redirector is closed (session close method called)

Edit:

I managed to fix the issue when it is just one person but noticed a problem with everyone but 1 player crashing when doing boss in a party. Crash happens randomly (arcenis v146) and console doesn't seem to be writing any errors out so I can't trace. Just looking for someone with experience on this issue to give some pointers

 

[noviceboy55]

Bump!

This may sound ridiculous but after much debugging, I have an issue that somewhat goes like this. (Arcenis 146 source)

When SOMETHING (possibly mob takes damage), server checks if you have SOMETHING2 (possibly stats). If you don't have SOMETHING2, SOMETHING3 happens (possibly server sends something). Client can't read SOMETHING 3 and crashes

I couldn't exactly find the a method for monsters taking damage and the closest I got, being "applyAttack" in DamageParse did not seem to have anything that might have caused this

Thus, I'm wondering if someone could shed some light on what method it might be and what check it is. I am certain there is a check of some sort because I did the exact same skill on two different characters with the only difference being stats and damage output and noticed one of them disconnects / crashes consistently while the other is absolutely fine.

 

[noviceboy55]

Bump

/2short

 

[Novak]

Use a redirector that closes the connection with the channel server after disconnecting. Which some out rn DON'T do. This causes the session to continue and the (probs crappy) MINA implementation to not recognise that the session closed.

AKA no use poop redirectors fam.

(Also eric was 100% right but didn't know crappy redirectors like this existed)

 

[noviceboy55]

Meanwhile, can't find a better redirector RIP.

Do you have any to recommend?

I mean I am currently using "your" flawlessrelay client which you linked somewhere in your arcenis thread as well as diamondo's msauth

 

[Novak]

Meanwhile, can't find a better redirector RIP.

Do you have any to recommend?

I mean I am currently using "your" flawlessrelay client which you linked somewhere in your arcenis thread as well as diamondo's msauth

Yeah mine always works, but fucks logout unless you configure it to read and write packets properly. In my latest release the setup for it should be pretty clear tho. Define version, opcodes, aes and disable the linkAllPorts or w/e i called it and you should be good.

 

[noviceboy55]

Yeah mine always works, but fucks logout unless you configure it to read and write packets properly. In my latest release the setup for it should be pretty clear tho. Define version, opcodes, aes and disable the linkAllPorts or w/e i called it and you should be good.

Yep did all that but doesn't get connection when linkAllPorts is false so definitely something wrong with the cryptokey. Is there a possibility that the values inside the source itself is wrong?

Just for the record, this is the Crypto I tried using (based on the values given in the source under USE_FIXED_IVS)

        private static byte[] CryptoKey = { (byte)0x66, 0x00, 0x00, 0x00, 0x75, 0x00, 0x00, 0x00,
                                            (byte)0x63, 0x00, 0x00, 0x00, 0x6B, 0x00, 0x00, 0x00,
                                            (byte)0x79, 0x00, 0x00, 0x00, 0x6F, 0x00, 0x00, 0x00,
                                            (byte)0x75, 0x00, 0x00, 0x00, 0x21, 0x00, 0x00, 0x00 };

Of course, anti-sniff is on so based on what I understand, that should be the cryptokey server is using?

Updated:

Tried turning off anti-sniff and tried the client's crypto with both

        byte[] key = new byte[]{(byte) 0x13, 0x00, 0x00, 0x00,
            (byte) 0x08, 0x00, 0x00, 0x00,
            (byte) 0x06, 0x00, 0x00, 0x00,
            (byte) 0xB4, 0x00, 0x00, 0x00,
            (byte) 0x1B, 0x00, 0x00, 0x00,
            (byte) 0x0F, 0x00, 0x00, 0x00,
            (byte) 0x33, 0x00, 0x00, 0x00,
            (byte) 0x52, 0x00, 0x00, 0x00

and

V146((short) 146, new SecretKeySpec(new byte[]{
(byte) 0x8B, (byte) 0x00, (byte) 0x00, (byte) 0x00, 
(byte) 0x24, (byte) 0x00, (byte) 0x00, (byte) 0x00, 
(byte) 0x8B, (byte) 0x00, (byte) 0x00, (byte) 0x00, 
(byte) 0x6D, (byte) 0x00, (byte) 0x00, (byte) 0x00, 
(byte) 0xB5, (byte) 0x00, (byte) 0x00, (byte) 0x00, 
(byte) 0xC6, (byte) 0x00, (byte) 0x00, (byte) 0x00, 
(byte) 0x08, (byte) 0x00, (byte) 0x00, (byte) 0x00, 
(byte) 0xB0, (byte) 0x00, (byte) 0x00, (byte) 0x00}, "AES")),

Didn't work :/

 

[noviceboy55]

Bump!

Can't get the client working publicly with linkallports false

 

[noviceboy55]

Bump!

After extensive testing, it is confirmed that
There is no issue with getting stuck or anything of that sort if connecting with linkallports false
However, I have only been able to get the client working on localhost if linkallports is false
and for it to be public, I need to enable linkallports (which causes the stuck issue)

Here's the code for Alllink

if (AllLink)
                {
                    LinkServer loginServer = new LinkServer(8484, toIP);
                    //LinkServer auth = new LinkServer((ushort)(Program.authServerPort), toIP);
                    ushort count = (ushort)(highPort - lowPort);
                    for (ushort i = 0; i <= count; i++)
                    {
                        LinkServer server = new LinkServer((ushort)(lowPort + i), toIP);
                    }
                }
                else
                {
                    Listener lListener = new Listener();
                    Debug.WriteLine("Listening on 8484");
                    lListener.OnClientConnected += new Listener.ClientConnectedHandler(listener_OnClientConnected);
                    lListener.Listen(8484);

                    ushort count = (ushort)(highPort - lowPort);
                    for (ushort i = 0; i <= count; i++)
                    {
                        Listener listener = new Listener();
                        listener.OnClientConnected += new Listener.ClientConnectedHandler(listener_OnClientConnected);
                        listener.Listen((ushort)(lowPort + i));
                        Debug.WriteLine("Listening on " + (lowPort + i).ToString());
                        Listeners.Add((ushort)(lowPort + i), listener);
                    }
                    //Listener authlistener = new Listener();
                    //authlistener.OnClientConnected += new Listener.ClientConnectedHandler(listener_OnClientConnected);
                    //authlistener.Listen((ushort)(Program.authServerPort));
                    //Debug.WriteLine("Listening on " + Program.authServerPort.ToString());
                    //Listeners.Add((ushort)(Program.authServerPort), authlistener);
                }

Update:

After much efforts trying to understand the client and the difference between connecting with linkallports enable/disabled, I narrowed it down to essentially 2 files being that LoginListener.cs (used when linkallports is disabled and LinkClient.cs (when linkallports is enabled).

Right now, I seem to have 2 options available which is to either figure out why LoginListener doesn't work beyond localhost or attempt to fix LinkClient such that it calls session close properly which is non-existent. Any help on either will be appreciated

 

[Novak]

Bump!

After extensive testing, it is confirmed that
There is no issue with getting stuck or anything of that sort if connecting with linkallports false
However, I have only been able to get the client working on localhost if linkallports is false
and for it to be public, I need to enable linkallports (which causes the stuck issue)

Here's the code for Alllink

if (AllLink)
                {
                    LinkServer loginServer = new LinkServer(8484, toIP);
                    //LinkServer auth = new LinkServer((ushort)(Program.authServerPort), toIP);
                    ushort count = (ushort)(highPort - lowPort);
                    for (ushort i = 0; i <= count; i++)
                    {
                        LinkServer server = new LinkServer((ushort)(lowPort + i), toIP);
                    }
                }
                else
                {
                    Listener lListener = new Listener();
                    Debug.WriteLine("Listening on 8484");
                    lListener.OnClientConnected += new Listener.ClientConnectedHandler(listener_OnClientConnected);
                    lListener.Listen(8484);

                    ushort count = (ushort)(highPort - lowPort);
                    for (ushort i = 0; i <= count; i++)
                    {
                        Listener listener = new Listener();
                        listener.OnClientConnected += new Listener.ClientConnectedHandler(listener_OnClientConnected);
                        listener.Listen((ushort)(lowPort + i));
                        Debug.WriteLine("Listening on " + (lowPort + i).ToString());
                        Listeners.Add((ushort)(lowPort + i), listener);
                    }
                    //Listener authlistener = new Listener();
                    //authlistener.OnClientConnected += new Listener.ClientConnectedHandler(listener_OnClientConnected);
                    //authlistener.Listen((ushort)(Program.authServerPort));
                    //Debug.WriteLine("Listening on " + Program.authServerPort.ToString());
                    //Listeners.Add((ushort)(Program.authServerPort), authlistener);
                }

Update:

After much efforts trying to understand the client and the difference between connecting with linkallports enable/disabled, I narrowed it down to essentially 2 files being that LoginListener.cs (used when linkallports is disabled and LinkClient.cs (when linkallports is enabled).

Right now, I seem to have 2 options available which is to either figure out why LoginListener doesn't work beyond localhost or attempt to fix LinkClient such that it calls session close properly which is non-existent. Any help on either will be appreciated

The real question is whether or not you're receiving a (corrupted) handshake when you connect with proper settings and linkallports disabled. If you don't receive any data at all some configuration in the two files you mentioned is wrong. If you receive gibberish the encoder/decoder are broken. Probs because of me not testing it low version, but possibly due to improper config.