Comet, Open Source Server (Multiple Patches)

08/14/2019 06:08 denominator#31
Ahh okay thank you for explaining :)
08/14/2019 09:25 Santa#32
Has anyone put to effort into upgrading this to >5017?

I've grabbed CptSky's implementation of Blowfish and Diffie-Hellman from CO2_CORE_DLL and think I have it implemented correctly but can't say for sure.

I'm trying to target patch 5095.

When the client connects to the game server I initiate the DH exchange. The client responds, I re-initiate the game-cipher with the new shared key, setIVs (with two byte arrays of length 8 initiated to 0s, same as original setup) and mark exchange complete.

I then receive the MsgConnect packet (1052) successfully deciphered (is this a sign my cipher is setup properly?). Obviously my character doesn't exist so I send a message packet "NEW_ROLE". The client does nothing with this, which makes me think my cipher is not properly setup. I am appending "TQServer" suffix to my packets (and not including that length in my packet length header) before I send the packet.

The fact I'm able to decipher the initial MsgConnect leaves me stumped...unless I don't fully understand the current order of things. Any Thoughts?

Blowfish:

Diffie-Hellman:

Game.Server - Received:

MsgTalk:
08/15/2019 07:33 Spirited#33
Quote:
Originally Posted by StarBucks View Post
Has anyone put to effort into upgrading this to >5017?

I've grabbed CptSky's implementation of Blowfish and Diffie-Hellman from CO2_CORE_DLL and think I have it implemented correctly but can't say for sure.

I'm trying to target patch 5095.

When the client connects to the game server I initiate the DH exchange. The client responds, I re-initiate the game-cipher with the new shared key, setIVs (with two byte arrays of length 8 initiated to 0s, same as original setup) and mark exchange complete.

I then receive the MsgConnect packet (1052) successfully deciphered (is this a sign my cipher is setup properly?). Obviously my character doesn't exist so I send a message packet "NEW_ROLE". The client does nothing with this, which makes me think my cipher is not properly setup. I am appending "TQServer" suffix to my packets (and not including that length in my packet length header) before I send the packet.

The fact I'm able to decipher the initial MsgConnect leaves me stumped...unless I don't fully understand the current order of things. Any Thoughts?

Blowfish:

Diffie-Hellman:

Game.Server - Received:

MsgTalk:
Hey, super cool that you want to upgrade this. I'm free to help in any way I can if you need it. I think it may be the way you're handling the client response? Right now, it looks like you're using the entire packet as the derived public key from the exchange. There's a random padding header with a length at offset 11. You add 15 to that length and that should be the offset of the UInt32 key length. The next field should be the public key... if this old source I'm reading is right.
08/15/2019 08:11 Santa#34
Quote:
Originally Posted by Spirited View Post
Hey, super cool that you want to upgrade this. I'm free to help in any way I can if you need it. I think it may be the way you're handling the client response? Right now, it looks like you're using the entire packet as the derived public key from the exchange. There's a random padding header with a length at offset 11. You add 15 to that length and that should be the offset of the UInt32 key length. The next field should be the public key... if this old source I'm reading is right.

Thanks for the response. Here is the function where I'm pulling out the public key from the client

Apparently I wasn't stamping my packets correctly with the TQServer footer. Changed the way I write that to the packet prior to sending it out and it works now. About to head out on vacation but when I get back ill try to clean it up a bit (not a fan of how dirty the exchange feels) and post a >5017 copy.

edit: Spent the better part of the day ripping this thing apart to figure out such a lame mistake.
08/15/2019 08:35 Spirited#35
Quote:
Originally Posted by StarBucks View Post

Thanks for the response. Here is the function where I'm pulling out the public key from the client

Apparently I wasn't stamping my packets correctly with the TQServer footer. Changed the way I write that to the packet prior to sending it out and it works now. About to head out on vacation but when I get back ill try to clean it up a bit (not a fan of how dirty the exchange feels) and post a >5017 copy.

edit: Spent the better part of the day ripping this thing apart to figure out such a lame mistake.
Sorry, totally misread your post and didn't realize you had MsgConnect *working*.
Glad you figured it out in the end. :p
08/15/2019 18:33 pintinho12#36
Quote:
Originally Posted by Spirited View Post
Sorry, totally misread your post and didn't realize you had MsgConnect *working*.
Glad you figured it out in the end. :p
It's worth if I rewrite my WCSource from Phoenix to Comet?
08/15/2019 22:06 Spirited#37
Quote:
Originally Posted by pintinho12 View Post
It's worth if I rewrite my WCSource from Phoenix to Comet?
That's up to you, but I think so. What I'd really love to see is people forking the master branch and creating public versions that people can then easily find and try contributing to. It'd also be nice for others to contribute towards the master project. I'm a bit tied up these days with commitments, but I'm always available to help lead and organize an effort, or contribute through code reviews and advice. I'll add instructions for forking the code tonight to the readme and contributing guide.

Edit: Here it is... [Only registered and activated users can see links. Click Here To Register...]
08/16/2019 17:20 pintinho12#38
Quote:
Originally Posted by Spirited View Post
That's up to you, but I think so. What I'd really love to see is people forking the master branch and creating public versions that people can then easily find and try contributing to. It'd also be nice for others to contribute towards the master project. I'm a bit tied up these days with commitments, but I'm always available to help lead and organize an effort, or contribute through code reviews and advice. I'll add instructions for forking the code tonight to the readme and contributing guide.

Edit: Here it is... [Only registered and activated users can see links. Click Here To Register...]
Then, I will create a 5729 soon ^_^
01/25/2020 21:19 bigbis#39
trying to make the correct convert but its gave me wrong length every time

04/05/2020 18:56 Abdallah Yehia#40
Nice Release Spirited,
I have only one issue regarding connecting to the client,
the client refuses any loopback adapter IP, it gives me server.dat is damaged, and when I disable the loopback adapter it accepts the same loopback IP but cannot connect to the server ofc, also I want to know what is the use of RPC IP, is this should be the same loopback adapter IP?
04/05/2020 19:59 Spirited#41
Quote:
Originally Posted by Abdallah Yehia View Post
Nice Release Spirited,
I have only one issue regarding connecting to the client,
the client refuses any loopback adapter IP, it gives me server.dat is damaged, and when I disable the loopback adapter it accepts the same loopback IP but cannot connect to the server ofc, also I want to know what is the use of RPC IP, is this should be the same loopback adapter IP?
That's not really a problem with the server. That's just what the client does on lower patches. I tend to use my local IP address instead (the one my router leases to me on 192.168.x.x). I also statically assign the address to my Mac address in the router's settings so it doesn't change on me, which also helps for port forwarding.
04/05/2020 21:34 pintinho12#42
Quote:
Originally Posted by Abdallah Yehia View Post
Nice Release Spirited,
I have only one issue regarding connecting to the client,
the client refuses any loopback adapter IP, it gives me server.dat is damaged, and when I disable the loopback adapter it accepts the same loopback IP but cannot connect to the server ofc, also I want to know what is the use of RPC IP, is this should be the same loopback adapter IP?
[Only registered and activated users can see links. Click Here To Register...]
good luck
04/05/2020 23:56 Abdallah Yehia#43
Quote:
Originally Posted by pintinho12 View Post
[Only registered and activated users can see links. Click Here To Register...]
good luck
Thanks a lot,
I followed the guide and now I can log in with 127.0.0.1.

Quote:
Originally Posted by Spirited View Post
That's not really a problem with the server. That's just what the client does on lower patches. I tend to use my local IP address instead (the one my router leases to me on 192.168.x.x). I also statically assign the address to my Mac address in the router's settings so it doesn't change on me, which also helps for port forwarding.
I followed the link mentioned in pintinho12 comment and now I can log in with 127.0.0.1, but when I log in the client crashes and the account server gives the following:

Missing packet 1052, Length 28
0000: 1C 00 1C 04 1D 46 51 0E 0A 00 00 00 72 65 73 2E | .....FQ.....res. |
0010: 64 61 74 00 00 00 00 00 00 00 00 00 | dat......... |
04/06/2020 00:24 Spirited#44
Quote:
Originally Posted by Abdallah Yehia View Post
Thanks a lot,
I followed the guide and now I can log in with 127.0.0.1.



I followed the link mentioned in pintinho12 comment and now I can log in with 127.0.0.1, but when I log in the client crashes and the account server gives the following:

Missing packet 1052, Length 28
0000: 1C 00 1C 04 1D 46 51 0E 0A 00 00 00 72 65 73 2E | .....FQ.....res. |
0010: 64 61 74 00 00 00 00 00 00 00 00 00 | dat......... |
That's just a missing packet on the account server that doesn't need to be implemented. The client at that low of a patch crashes if you use 127.0.0.1. Try getting the server running without 127.0.0.1 first and then start making your client modifications. It's important to do your sanity checks before trying anything new. Here's a document of common login issues: [Only registered and activated users can see links. Click Here To Register...]
04/20/2020 20:53 Spirited#45
First, I just want to thank a few of you for your interest and feedback on this source. I received concerns regarding how Comet utilizes channels and tasks, and so I made some improvements. I increased the number of channels to one per background service task. This means clients will now be assigned a specific worker based on availability rather than letting any worker process packets from that client. That should guarantee that packets from the client aren't accidentally processed out of order. Since this is the project's first major update, I also updated its dotnet core version to 3.1 and cleared it of all vetting issues. Additionally, packet processing is now using the async-await pattern. I'm not entirely confident in my understanding of Tasks, so please review if you have time. Thanks.