I'm testing an application which downloads info from photovoltaic equipment, so I have to connect to a remote power plant via Internet, using a TCP connection, I download info with my application and then I disconnect... Sometimes when I try to reconnect with remote power plant after few minutes, I can't do it, so, looking for a clue I have started capturing packets with wireshark and I can see that sometimes I send [FIN, ACK] and I get [ACK], then I get [FIN,ACK] and I send [ACK] and everything is OK for next connection, but sometimes I send [FIN,ACK] and I get [RST] and then I have to wait about 5 minutes before I can reconnect with remote router........ Any idea? asked 12 Sep '12, 09:56  pedrojpz |
2 Answers:
It sounds like (from your description) that the photovoltaic equipment is getting stuck in some FINWAIT state. In other words, it's not gracefully handling the tcp tear down and when that happens, you have to wait for a timeout (some multiples of MSL). I'm not sure you'll be able to do anything since you probably can't touch the tcp stack. answered 12 Sep '12, 14:30  hansangb |
Just a wild idea... sounds like the service that handles the TCP port crashes and then the OS sends a RST, as the local socket is no longer available. Then after 5 minutes some kind of 'watchdog' restarts the service and then you can reconnect. Regards answered 13 Sep '12, 10:28  Kurt Knochner ♦ I think you may be on to something. I didn't go into it, but I didn't like trace evidence as much to support the FINWAIT argument. I didn't want to get into it too deeply because, let's face it, what exactly can you do if the stack is bad? I think it'll come down to the fact that the stack is not handling exceptions correctly and starting the process. (13 Sep '12, 10:49) hansangb |
This is driving me crazy... Thanks for your reply.
I'd try to capture as close as possible to the remote system to see if what you send gets there unmodified. That way you can also have an unbiased look at the exact stack behaviour of the photovoltaic system, and see if Hansang's idea seems plausible (in which case you'll have to kick the vendor of the thing to get it's stack done right). Industrial TCP stacks in embedded systems are a certifiable nightmare in my experience, the developers seem to stick to RFCs only as much as they absolutely have to to get the thing to work under perfect circumstances...