I have two applications that talk via TCP, both of which run on Windows XP machines. The client is a third-party application for which I have only the executable, no source. The IP address of the server it connects to is set in a text configuration file. The server is an application I am writing.
All netmasks are 255.255.255.0.
In all cases, the client runs on 192.168.142.202.
I am seeing a case where if I run my server on 192.168.142.207, everything works, but if I move my server over to another machine on the same subnet (192.168.142.105), everything does not work fine. Specifically, the connection does not seem to get properly established. I have looked at what's going on in Wireshark and would like to request assistance interpeting what I see.
On the server side, I see the 3-way handshake: SYN, SYN/ACK, ACK. I get no error codes on the return of accept(), and netstat shows the connection as established.
On the client side, the connection does not seem to be established properly. This causes the client to reconnect periodically, and it will also occasionally close all of the not-correctly-connected sockets that get created as a result. When I look at the client side in Wireshark, I most often see a SYN, SYN, SYN pattern, rather that the expected 3-way handshake. Occassionally, the 3-way handshake does appear, but even then, the client doesn't seem to be happy with the connection because it closes it.
I will note that there are actually two TCP connections between the client and server. The other connection (i.e. not the problematic connection I described above) works just fine. The problematic connection has listening port 5004; the good connection has listening port 1234.
I have placed both .txt and .pcap versions of the client and server Wireshark captures at this link: https://skydrive.live.com/redir.aspx?cid=c5beaf58ac752bb0&resid=C5BEAF58AC752BB0!105&parid=root
As far as the physical network setup goes, there is one switch in between the client and server in the case that works, and there are two switches in between the client and server in the case that doesn't work. All ping tests are successful. There are no wireless connections involved; everything is wired.
All firewalls are off.
Does anybody have any thoughts on either what the problem is or what further data I could gather to solve the problem?
Well, it appears this is not a network or network programming problem at all. I've figured out by trial and error that the third-party software that connects to me wants the machine it runs on to have a smaller IP address than the machine my software runs on. This seems completely arbitrary to me, but empirically, this very strongly appears to be the case. Arghhhh............
Thanks to any and all who may have spent time poring over the Wiresharks dumps I provided...
Related
The goal is to make an http request from the client browser to my server. Simple stuff; however I'm hitting a wall with the networking portion. In order to expose my server to WAN I have used one of my public IPs and NAT to translate to the private ip of my server on inbound traffic and to my public IP on outbound traffic.
The issue is that I can't make a connection. Specifically I can't get the last part of the TCP handshake. Using a test setup with Wireshark on the client and server I can see that the client send the SYN -> the server receives the SYN -> the server sends a SYN/ACK -> the client receives a SYN/ACK -> the the client send an ACK -> the server DOES NOT receive the ACK. It waits for a moment then does a retransmission. Eventually resetting.
I have tried adding various firewall rules even though I don't think it could be the firewall because the first packets make a successful round trip.
I've turned windows firewall off(the server)
I've tried disabling TCP checksum offloading
I've looked for network anti virus settings on the server and on the sonic wall(the router)
I would expect the the tcp connection to complete. I can't for the life of me think of a reason why the ACK would consistently go missing.
That is another thing. The behavior is consistent.
pings also work just fine.
NOTE: The server is actually a VM and the physical server that manages it is in my network.
Any guidance on what to try and where to look would be very much appreciated. Thanks.
UPDATE: I can make connection using port 5000(It's another port I have opened on the firewall). Port 80 still doesn't work though.
In my case this was caused by COX not allowing inbound traffic to port 80. I'm not sure why the first portions of the tcp handshake were getting through. If anyone can explain that part leave a comment.
This is not a hacking question.
Imagine I have an application running on a local machine which has a TCP connection to some remote server. There are numerous ways to see packets, the obvious one is Wireshark. But is there a way to send packets to both the application, and the server without getting in the middle of two? That is, without running a proxy between the two, programmatically send packets to application as if they were coming from the server, as well as to the server as if they were coming from the application.
Requesting the local machine fails right away:
telnet localhost 65535
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
while it runs forever when requesting google or any other remote machine:
telnet www.google.com 65535
Trying 2a00:1450:4007:812::2004...
I suppose non standard ports should be closed on web servers. If yes, telnet should end up with a "Connection refused" right away as well. right?
Actually, this can be caused by multiple sources. A not so known, but common one:
There are some firewalls allowing you to delay requests to specific ports.
Think about this: Scanning one IP address for all ports only takes a few seconds.
If you delay the response (in case the port is not opended for instance) it will take a potential attacker much longer to scan all ports.
You could argue that the attacker could count anything taking let´s say 5 seconds or longer as timeout, but, there are applications, SMTP servers for instance, that often actually respond only after 20 seconds or so because of this.
May protocols are trying to be attacked and if you generally define that your mailserver will only respond after 20 seconds, that does not really matter to mails in most cases, most attacks will already count this as timeout and won´t even notice that a mailserver is running there whereas the clients get configured for timeouts of 30 seconds or so and they can connect.
Another common thing is that the windows telnet client won´t really post the output until you press any key.
localhost Tcp connections randomly disconnecting. Running tcp client/server apps with simple echoing the server sees the local client connection breaking but any client connection over the network stays up. All local host connections get severed. One can immediately reconnect with no problem. This happens randomly and relatively rarely but is still problematic in my environment. Has anyone observed this pattern?
Instead of "Localhost" use 127.0.0.1
Localhost is used in Linux. Windows works better with 127.0.0.1.
Beats me, Google for explanation or just use the knowledge.
I have a simple client application which sends udp datagram to the server with known ip address and port and waits for respond. Client can be started on any computer or mobile device and it can be located behind several routers and firewalls... Server application listens certain port for client's datagram and replies to the client's endpoint with an answer. Server application works on windows computer with properly configured firewall, etc. So, as I understand, this simple scheme should work regardless to client's location and his firewall settings. But it looks like it doesn't work in about 75% of configurations. Server receives request from the client in 100% of cases, but in 75% of cases client can't receive response from the server, i.e. it looks like it's always blocked by something (server attempts 10 times to send an answer to the client, but without luck, i.e. client doesn't receive anything). I tried many different configurations of client computers to figure out the reasons of these issues and what I've found:
In some cases simple windows firewall can block respond packets (But how it could be possible? As I understand, all respond packets must be forwarded back to the client regardless to firewall settings.)
Some Hardware firewalls or NATs also can block respond UDP packets. And again, I can't understand why it could be possible?
The question is - is there any reliable method to deliver an answer to client? As I know, many programs, such as Skype works fine with UDP even with all these network "obstacles".
Thank you!