So, recently, I've run into a few issues with Python TCP/IP sockets. Basically, I can't make,and neither can Python's IDLE (a Python file editor) program itself, since it requires a connection at startup, any TCP communication endpoints using the Python socket module. So, I asked what was going on with my Python over on StackOverflow, and I got an answer telling me I should use Wireshark to figure out from where a RST signal is being sent to my program.

I've learned the basics of capturing. My only problem is I am not sure for which program I am looking. I am not sure at which packets I should be looking, and how I am supposed to go about finding from where the RST is coming? So, if anyone could walk me through this, that would be greatly appreciated.

  • If possible, upload your capture to cloudshark.org so that we can all take a look at it.
    – OzNetNerd
    Commented Nov 26, 2015 at 1:56
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Commented Aug 12, 2017 at 3:44

3 Answers 3


Try using the following wireshark/tshark display-filter:


Alternatively, Try using the following tcpdump capture-filter:


Both are compatible with the following logic-modifiers:

&& or and
|| or or
! or not


Assuming that you are able to capture this traffic it comes down to mapping the parameters of your connection to the packets found in the capture.

First of all you state using TCP, so applying the display filter 'tcp' should get rid of all the other packets. If you are seeing still more than one TCP session you can filter even more.

You know which TCP port you are connecting to, so applying the display filter 'tcp.port == <your port#>' should get rid of all the other packets.

Now you should be able to tell if the service process indeed sends you tcp RST.

As for finding the service process you'll have to go look at the open port list on the platform hosting the service. 'netstat -lp --tcp' comes to mind.

  • It seems that my server running on TCP port 45002 doesn't make any requests/send any data. The server, when started, isn't showing any traffic on the filter. Not only that, but once I fire up the client that is supposed to send a simple message to the server, it returns an error that it couldn't connect, and oddly there still isn't any traffic on the port the server is running on. I would imagine that if you were going to receive a RST signal, you would have to be sending packets. Same thing with IDLE, port 8833, no traffic when I start it up. What would stop packets before theyre even sent?
    – said
    Commented Jul 28, 2015 at 4:06
  • Stop worrying about resets. If your network capture is accurate then you either do not have basic network connectivity in place yet, or the client isn't actually attempting a connection. First ensure you can successfully ping the server from the client, and then check that there is no firewalling that would prevent your traffic. If networking/firewalling is OK then it's clear that the client isn't working. At which point perhaps you should refer to the Stackoverflow programming forum.
    – marctxk
    Commented Jul 28, 2016 at 12:48

I will suggest if you are comfortable that there is no firewall running on the server or it has the ports allowed and no ACL's on switches in between the server and client that deny these ports is to run NMap on the client side against the server. Default is first thousand ports plus well known ports, add -p 1-45003 and verify that the desired ports don't show (closed). Will take a little longer to scan the additional port range. Hopefully the port will show what app NMap thinks is running on 8833 and 45002 and that they are open. RST is usually the results of a broken conservation and one side says I don't like it and sends a reset to tear-down the conservation.

Not the answer you're looking for? Browse other questions tagged or ask your own question.