[Guide] Why doesn't my client connect to my server? - Part 1 - IPs and Ports

[bobsobol]

[Guide] Why doesn't my client connect to my server? - Part 1: IPs and Ports

To view the content, you need to sign in or register

Why doesn't my client connect to my server?
Part 1 - IPs and Ports​

Okay... We are getting a lot of these questions lately, and as server devs are constantly changing their clients to ensure they only connect to their server this is only going to get worse.

Most people list a whole load of database stuff, and a ream of configurations that they are trying to use, presuming they must have configured one or the other wrong... Just as likely you are using a client that isn't designed to work with the server you have.

Either way, tracing the communication will trace both problems very quickly.

Step One - Downloads
You are going to need some simple tools to trace the operation of your client and your server. But don't worry, the process is pretty much the same at both ends.
Download

To view the content, you need to sign in or register

by Mark Russinovich from Microsoft TechNet.
--- Edit --- I'm finding version post 2.54 are less informative about which System Process (Services) is holding what port open, so I've hunted down an

To view the content, you need to sign in or register

for you. It may have compatability issues on newer OS though... I suspect that is why they are dropping functionality.
--- Edit ---
I like to include alternatives if I can, so I have found that

To view the content, you need to sign in or register

is equally good, and also free of charge.
---/Edit ---
For advanced analysis get

To view the content, you need to sign in or register

or

To view the content, you need to sign in or register

(the newer Wireshark seems to ignore anything that isn't a known protocol, unless I'm using it wrong) or

To view the content, you need to sign in or register

(

To view the content, you need to sign in or register

,

To view the content, you need to sign in or register

) or maybe even

To view the content, you need to sign in or register

or any other good packet sniffer.

Step Two - Checking the Server Port
Open TCPView on your server machine before you start the server running.

​

If you have lots of programs opening ports, that's normal but it's also the attack surface for hackers. You may want to shut as many of those services down as possible if you are going public with your server.

Once you start your server, and it completes the initialization it will open a listening port, and show up in the list. Recent changes are highlighted, green for a new port open, red for one just closed. This server is looking for clients to connect on port 10007... and I haven't touched a config file, hex editor or debugger. How easy is that?

Next, do the same on your client system, open TCPView, and then start the client.

Yup, it's a client workstation, not a server. It's attack surface at any particular time is going to be a complete mess. lol This is why you have a really good firewall and a good router... right?

The client will not even attempt to connect to the server till you try to log in... however, I notice a lot of them, even the non-Korean ones open a connection to one of 4 or 5 Korean sites on port 4545 just briefly at start-up... I was slightly concerned about that so I remove that code from my client, but most "Private" servers don't.

As you can see this client is trying to connect on port 10009 so it's not going to connect to the server we have, at least not without some modification.

The good news is that 192.167.1.5 is the LAN address of my server... and I'm working on a LAN set up, that's how both are configured. So that confirms that that client is reading the correct configuration information, and is trying to connect to the correct IP. It's just using the wrong port.

This client, shown alongside it's connection on the server is compatible, and you can see that it's connecting on the correct port.

Again, I can see that 192.168.1.7 is my gaming PC... that's the one with my client running, so I know that my server has seen the correct machine, and if I have a friend trying from another PC, I can tell which is me, and which is her/him from the IP shown in TCPView on the server.

Having changed the client exe for another one, to try and get the correct port, I could find that the IP issue raises it's ugly head again. This is because not all clients look for their configuration in the same place, or read the same commands from the config files. Additionally, if there are settings in a file left over from a different install, the new client could prefer those, and the old client may not even have read them. (more on that in part 2)

If you see it connect from the server side on the right port, and almost instantly disconnect, then it is communicating, but not using the same protocol. They are talking to each other, hearing each other, but they can't understand what the other one is saying. There are at least 4 different protocols, or encryptions... depending on how you look at it, and I don't have a lot of skill in changing the communication "style" in a client or server... but people have done it. ^_^

Client: "Hello. I would like to log in to the Priston Tale server please."
Server: "¡Hola! Esto es el Servidor de Cuento de Priston Tale."
Client: "I beg your pardon?"
Server: "¿Qué dijo usted?"
Client: "I'm sorry, I don't understand you."
Server: "Yo no comprendo."
Client: "Never mind. Goodbye."
Server: "Adiós."

The other possibility, is that it looks right on the server alone, looks right when the client tries to log in, but nothing happens server side so the client disconnects again. That means the "signal" is not getting through. Never mind your software set up, something is blocking the transmission so start looking at firewalls, routers, ISP etc. etc.

So we've done one simple test, and learned a whole heap more than we would have if we'd spent days pouring over configuration files, hexing and debugging exes and messing around. At least that's the way I see it.

Step Three - Advanced Analysis (Expert: brief description)
If you find your client and server are using different protocols, and you don't want to just change one or the other for one that "just works", you are going to need to analyse the protocols that each are speaking. If you can find a client that speaks the right protocol, but isn't the client you want to use, that will be helpful because you can take it's protocol code and use it as a template for editing the client you do want to use.

So, first you need to fire up one of the packet sniffers above.

You will find both machines probably have a lot of network traffic, so you will want to filter it down to something simple.

I don't know Ethereal well, and haven't found a good way to make it work, but it is a known classic tool for doing this. My server is Windows 2000 and the Microsoft solution needs XP, so that's not ideal for me either, but may well be a good choice for others.

I usually use Sniphere, and a good filter is to run the application twice, either on the server machine and on the client machine, or both on one machine... you can do that. Filter everything except the port your game uses. Use the source port in one instance and the destination port in the other instance, or, if you run one instance on each machine, use the source port on each.

You can save reports of the communications, and if you have a client that works and one that doesn't you can combine the packet logs with your analysis of the code to see how the encoding of the exact same information is different.

In SmartSniff, you get the entire conversation in a single window, where in Sniphere you get each packet separated out. It's kind of "your preference" which you use... in some cases the packetisation may be very helpful to know, in others, you only care how the information is transmitted, not where the chunks are broken up.

One nice point about SmartSniff is that it filters on a single string, so I can just tell you to use the display filter string "include:both:tcpudp:xxxxx" where "xxxxx" is the port your game is running on, in my examples above, the port is 10007 so the string would be "include:both:tcpudp:10007"... pretty simple.

In Olly, I would look for calls to remote procedures in "WinSock.dll" and then trace memory usage back from there. I'm no expert in doing this, and maybe someone would like to elaborate on the process here. Until then, all I can say is that you now know the tools and procedures to follow to get started, you just need to figure out how to find and change the code that produces the data captured by these tools.

Next Time
That's all I'm going to write on tracing your network information. I'll post Part 2 in a separate thread, and cover how to find out what configuration information you client is reading from where, and maybe give some insight into how to change it to work the way you want.

Hope you enjoyed reading this guide, and I hope you find it, and the links to tools in it useful in determining why you can't connect to your server... See you all next time.

If you have anything to contribute on deciphering the packets I'd love to hear about that. As you can see, I know how to start, but can't go very deep.

To view the content, you need to sign in or register