Hi, I have a problem in establishing a tcp connection with a device(client) and PC(server) I will list important places in the wireshark to make it comfortable for you. start - connection established till 106 - full of retransmission. then window size of tcp if full. so data starts sending again.. after this, there is no problem.(no retransmissions) at 1032 - exit is sent from PC. It closes connection in labview and device also responds for it.(this stops the labview as well) the device is programmed to always look for connection. so it send arp request even after that. at 1050 - labview started. but still connection is not establishing.. PC is sending 'ack" instead of "syn ack" as a reply to "syn" from device.. this continues.. at 1103 - a "rst" is given from PC.. after this connection establishes.. then retransmission for some time.. then proper communication... my questions are "what decides when rst signal sent by PC?", "why connection establishes after 'rst' ?" , "during retransmission there was seperate "ack" from PC. when not after that?" ," why transmits well after window gets full ? asked 17 Sep '13, 21:37  Raja Balaji edited 18 Sep '13, 02:09  Kurt Knochner ♦ |
One Answer:
The problem seems to be that your application is using the same source port for new connections. As the time between the new connections is only a few seconds, the socket on the server may still exists (not closed) in your Labview application and thus the server (Labview tool) sends an ACK for the new SYN instead of a SYN-ACK. After the server resets the connection in frame #1103, a new connection can be established, as the server now accepts connections with that source port as new connections. Solution: Don't use the same source port for new connections too fast, or troubleshoot the timing values in your Labview application. Regards answered 18 Sep '13, 00:34 Kurt Knochner ♦ edited 18 Sep '13, 02:09 ok thanks.. if not in labview, where can I change it.. (any other option available in PC to change the timing?) why do you there is re-transmissions initially?? why did it stop after the window size of tcp gets full?? have I established the tcp connection correctly?? (doubt: once I get data from server, should the client separately send an ack signal or can I make the ack flag high in the data packet and send it directly) (18 Sep '13, 02:10) Raja Balaji I have no idea how Labview handles TCP, so this might be a question for the Labview forum. However, instead of trying to change any timeout values, do the right thing and don't use the same source port several times in your client.
Well, there are some other problems in the TCP connection. I will come back on them later. In the meantime, as a first step, please fix the source port problem. (18 Sep '13, 02:21) Kurt Knochner ♦ Some problems:
These rather small window sizes will certainly call for trouble. (18 Sep '13, 03:20) Kurt Knochner ♦ |
Sorry, but that kind of description is not really good enough to really help you. A packet trace would be much better, especially since nobody here knows your application like you do and (at least I) can't exactly follow what is happening. For example:
What do you mean by
"exit is sent from PC"?
"device is programmed to look for connection", and what does an ARP request have to do with that?
If you can, put a sample trace on Cloudshark.
I am having a device which I have programmed to work as a tcp client (enc28j60+ arduino controller)
from the PC, I use a programming software called labview to "listen for a tcp connection, read some data packets, write some data packets and close a tcp connection".
based on what data I sent from this software, I get a data from the device. when "exit" is sent from labview, I have programmed it such a way that connection is closed and the labview program also stops.
when I again try to start the labview code, the connection is not getting established at once. It takes some 2 minutes to connect again. I want to know why this happens and is there a way out to prevent it?
click here you can find the wireshark log in this link. I could not upload an attachment here.(3rd conversation in the page)