v175 redirector and server issue

[crayonfite]

Hello, I have a problem where the client just wouldn't be able to send the correct packets to the server, resulting in opcodes send such as 11502, -23451 and huge opcode headers. The v175 redirector is using the interceptedlinkedclient method with the correct v175.1 aes key:

private static byte[] CryptoKey = { 
(byte) 0xEB, 0x00, 0x00, 0x00, 
(byte) 0x49, 0x00, 0x00, 0x00,           
(byte) 0x04, 0x00, 0x00, 0x00,            
(byte) 0x47, 0x00, 0x00, 0x00,           
(byte) 0x14, 0x00, 0x00, 0x00,            
(byte) 0x69, 0x00, 0x00, 0x00,            
(byte) 0xA0, 0x00, 0x00, 0x00,            
(byte) 0x08, 0x00, 0x00, 0x00 };

client is set to send 175.1 as maple version and patch number

The server side has the same key in the mapleaesofb and updated opcodes for v175.

The problem is that when the client connects, the server gets the connection but no packet exchange happens after that (probably due to wrong packet headers), then the client freezes, right after the nexon security guard opens up.

Accepted connection on 8484
New linkclient to *serverip*
Connecting out to port 8484
Init packet: v175ident: 8
handshake complete.
packet sent 11569
packet sent -15826
packet sent 21572
packet sent -3952
packet sent 18816
packet sent -18232
packet sent 31656packet sent 27552packet sent -5481packet sent -7537packet sent 19335packet sent 23455packet sent -22925packet sent -10678

Help would be appreciated

 

[Novak]

If you are updating this redirector from an older version (lets say pre-v150) make sure to remove the maple custom encryption as it's no longer being used.

 

[crayonfite]

Hi @Novak, thanks for that, I'll look into the redirector and see if thats the case, but i tried the one u put up for 176.3 in the mushy source forums and that gave me the same error as above.

edit: sorry i think you meant in the server side right? I'll check there as well.



I checked the server side to make sure that the maple custom encryption is not there anymore, its commented out and deleted. However, the client still tries to send the same packets as stated in the main post, what could be the problem?

 

[crayonfite]

Still having the same error if not connected via localhost (which i think does not send custom packets through the server), the server receives Client_start with no issues but after that the server receives random packets from the client. on client start we send 0x24 1 to the client but the client does not receive the packet.

In localhost the server and client runs just fine, only when other people connect the issue is present, help would be appreciated

 

[Novak]

Still having the same error if not connected via localhost (which i think does not send custom packets through the server), the server receives Client_start with no issues but after that the server receives random packets from the client. on client start we send 0x24 1 to the client but the client does not receive the packet.

In localhost the server and client runs just fine, only when other people connect the issue is present, help would be appreciated

In localhost the client just uses netsh. For whatever reason the ecryption is not working on your version though.
Are you using this one?

You must be registered to see links

 

[crayonfite]

Yea, I was using that one to test out because my other redirector had same problems, but it is now solved by using the fraysa diamondo method of redirection. Not sure why the interceptedlinkedclient method doesn't work for me.

Thank you for helps