On Wed, 17 Jun 2015, Maqbool Hashim wrote:
Finally I don't see how it could be, but be interested to hear peoples thoughts, no legitimate application could be generating this traffic could it? I mean I don't see what use an application could make of such a TCP conversation. Discarding network analysis etc. This machine runs a whole host of proprietary control system protocols, so haven't discarded the possibility totally- but I just can't see what an application protocol could find useful in a bunch of reset + ack packets being received from the destination hosts.
Okay, setting aside the malicious possibilities, it may be that someone felt they needed something like ping but without the need for a raw socket. I would worry about such code as there is usually sufficient proof the host is alive due to ongoing or new sessions. Still, in process control it may be reasonable to check aliveness if, for example, there has been no normal activity for a seemingly small period of time, e.g., 50ms. Such a test is only sufficient to prove that the TCP stack will respond, not the programs (which is where aliveness within the protocols is far more useful, classically PING and PONG). Or perhaps a fence-post bug, e.g., a program is doing its own port selection with a max of 65535 where it accidentally uses max+1 which for a 16 bit unsigned value turns out to be 0, i.e., fixing the port number (setting it to the min value) after it is used rather than before. /mark