I have a client device requesting data from a server device, periodically following a fin/ack, ack, fin/ack, ack, the server device proceeds to send an RST packet... why would this happen? this packet should never happen right? the session is closed, why send an RST? asked 05 Dec '13, 10:44  jwolf |
2 Answers:
The server probably never sent it. Some firewalls do this when they cleanup their connection table. Did you check the ip.ttl / ip.id of the RST packet and compare it to the server's other packets? answered 05 Dec '13, 21:23  mrEEde |
because of the way the TCP/IP stack of that device was programmed. Could be intentional, could be a bug. Without insight into the code, you will never know. Some versions of Windows do that, for no good reason. Regards answered 06 Dec '13, 11:49  Kurt Knochner ♦ edited 06 Dec '13, 11:51 it does not use windows and its not a server parse, its a device that collects and sends data to a data collection device, it technically is the server in the server client relationship. so you are saying that it is either a potential error or it was programmed that way intentionally? thanks for the response. (06 Dec '13, 12:54) jwolf I'm saying, if it is some embedded device, it could be a bug in the TCP/IP implementation. However, it could also be intentional. I don't know a good reason, but maybe the developer of that IP stack knew one while he was writing the code. Who knows.... Do you know if that device uses any standard OS (Linux, BSD, vxworks, QNX, etc.) (06 Dec '13, 13:34) Kurt Knochner ♦ There is an internet draft describing a client sending a RST after FIN to avoid too many TIME_WAIT connections. http://tools.ietf.org/html/draft-faber-time-wait-avoidance-00 . So at least someone thought of doing this as a 'good reason' (07 Dec '13, 00:01) mrEEde That's a good reason for the client to send a RST. In fact IE on Windows is doing that, while Firefox on the same client does not send the RST, which indeed leads to the situation that the Firefox connection is shown much longer in TIME_WAIT state on the server (netstat -na). However, the OP reported the server sending the RST. And I don't know a good reason for that. There might be one, I just don't know one. (07 Dec '13, 06:58) Kurt Knochner ♦ |
this is on a controlled test environment with only one switch and no firewalls. ip.ttl is 128 and the ip.id is incremented by 1 just like the previous packets from that server device, I call it a server device because that is how it is functioning in the modbus communication.