Question

I’m using a Java program to POST some XML data from a remote client machine to one our servers. I have checked individual components of the whole system independently and figured out that:

1. The client is able to successfully fetch response for a GET request to the same server. So name resolution related issues can be ruled out.
2. The client code in other networks is able to POST data to our server. So, the server code is working fine.
3. Trying to POST the same data to a different server from the same client succeeds. Moreover, the systems in other networks are running the same version of the client. So, the client code works as well.
4. I tried posting the XML file through CURL using:

   curl --header 'content-type: text/xml;charset=UTF-8' --data @5.xml -X POST http://myserver.com/updates

   but that hung up too. So, I concluded that the problem is not with the Java part but the network itself.

5. Doing a netstat -ntavp shows the following output:

       Active Internet connections (servers and established)
       Proto Recv-Q Send-Q Local Address           Foreign Address         State
       tcp6       0   6250 192.168.1.50:32771      www.xxx.yyy.zzz:80      ESTABLISHED
       

   And the client system remains in this state for a long time showing a few thousand bytes waiting in the Send queue. I have checked the server log at the same time and there are no bytes waiting to be read there. The State is also shown as ESTABLISHED and so I have to conclude that the TCP handshake went through fine. I’m kind of stuck here.

Where more could I look to find out what is causing this problem? The OS on both the client and the server is Ubuntu 10.04

Update:
Apparently, the problem is not limited to HTTP posts. I dumped the XML portion of the request in a file and tried copying it using FTP and SCP to the server. Both these attempts failed as well. So, the current situation is this:

1. The client is able to send requests and files to other servers.
2. The server is able to handle HTTP requests and file uploads from other clients.
3. The files are actually transferred to the server from the client but the connection doesn’t seem to be getting closed.
4. I have captured the packets on the server using tcpdump and found that the checksums for some of the packets originating from the server were incorrect.

Update 2
Please ignore the update about the checksums as I came across http://www.ethereal.com/faq.html#q11.1 and verified that the client is indeed receiving TCP packets with the right checksum.

Answer 1

The problem was solved by setting the MTU to a value of 1400 as suggested in the answer to this question.

Though the two problems appeared to be different at first, the underlying cause turned out to be the same.