How to monitor session is not existing between two IP address on specific port

edit

Wireshark is not the tool for that purpose, but it may be useful to analyse how that particular session should look like when it is active, i.e. to determine the criteria based on which a purpose-made application would use to identify the break of the session.

Unless there is some permanent, albeit low, traffic in the monitored session, it may be impossible at all to determine the break. A TCP session may remain established for days with no packets being exchanged.

This may be possible if you used a script to monitor the output of tshark and then react to it. It depends what you are trying to do exactly and the conditions that have to be met. I think more information is required to give a complete answer.

@csereno, there is a deep trap in this idea. Neither tshark nor Wireshark can run continuously forever, as while dissecting packets, they build and keep a lot of state information related to sessions etc. which continuously grows until it occupies all the avalilable RAM sooner or later. You can run dumpcap forever, but it does not dissect packets.

@sindy, You are correct when running tshark's native commands. However, there are workarounds with scripting. I have been using tshark in a similar manner running for over 6 months now without filling file storage or RAM to pull LDAP information for an admin. That's why we would need more information in this case, and the solution would have to be scripted.

If by "scripting" you have in mind running several instances of tshark one after another with a short overlap between each pair of them, then yes. If you've been running a single instance of tshark for months, and moreover, handling a TCP-based protocol, my understanding of the world got just shaken to the roots :-)

@sindy, I went back and looked at my script. At one time I had it running a single instance and I was deleting the temporary files it created, etc. This worked for a few days/week (can't remember). However, I needed to change the report, and when I did, I decided to kill the existing tshark and start a new instance every time (actually without overlap). I did this because it was easier and worked fine for me. Now that we're discussing it again, I'd be curious to see how long my original script could have actually run without causing problems.

Either way, Wireshark won't work for this, and some sort of scripted solution using a command-line tool would be required to get close to a solution for IndWatch.

@IndWatch, Better yet...do you need to actually capture the packets? If not, you could even use other tools such as netstat, etc just to monitor the overall connection (which also ties back in with @sindy's first answer).