0

Not too long ago I asked this question. I was very surprised that no one came up with any answers, so I am pretty sure my issue is fairly rare. Yesterday, as I was self-diagnosing the issue, I began connecting the dots. My Twisted TCP server won't work, IDLE fails at startup because of a "Socket Error" and returns the message: "IDLE Subprocess: socket error: No connection could be made because the target machine actively refused it", and I get this same error when I try running a (local) TCP client connecting to a (local) TCP server.

So I came to the conclusion Yesterday, that these weren't just individual issues, but rather a larger issue with creating and running TCP endpoints using Python Sockets. Keep in mind, UDP servers and clients that I run both on a local network and locally work, so I don't think it's a problem with the Socket module as a whole, but just the TCP side of things.

Some info on my computer: Windows 64bit, running Python 2.7.9 (for some reason, 32bit), Laptop connected to a network via (built in) Wireless card. ISP is Comcast (if it makes a difference), and the Router/Modem (it's an all-in-one) is a TechniColor provided by Comcast (again, if it makes a difference).

Things I've tried:

  • Reset my .../etc/hosts file
  • Reinstalled Python 2 months ago (while trying to troubleshoot)
  • Turned off all Firewall (I only have 1)
  • No antivirus other than Microsoft Security Essentials
  • The issue was still present when I still had Bitdefender installed, but I installed it to be sure

I also went through a small troubleshooting session on the previous thread I mentioned earlier. The biggest error I get when using TCP Sockets is: socket.error: [Errno 10061] No connection could be made because the target machine actively refused it.

So, anyone have an idea as to what's wrong here? Thanks.

EDIT: Looks like I missed something, the port is 45002, which is out of the range of default Windows ports, and I am pretty sure nothing uses it, as I have been able to run a UDP server on that port with good results. The port is also port forwarded, just in case.

Community
  • 1
  • 1
said
  • 474
  • 4
  • 8
  • 18
  • Is it possible that a firewall might be blocking it ? – Meghdeep Ray Jul 22 '15 at 16:46
  • What port are you opening the socket on? Is something else already using that port? – Thomas Owens Jul 22 '15 at 16:48
  • @ThomasOwens Ah sorry, knew I missed something, the port is 45002, which is out of the range of default Windows ports, and I am pretty sure nothing uses it, as I have been able to run a UDP server on that port with good results. The port is also port forwarded, just in case. Ill make sure to add this info to the OP. Thanks. – said Jul 22 '15 at 16:50
  • @MeghdeepRay I am pretty sure the firewall is not the issue. I have tried turning off the firewall with the same error being returned. Don't know if UDP communication requires Firewall permission, but if it does, it would prove my point further, as I have ran a UDP server/client locally with success. – said Jul 22 '15 at 16:54
  • Also, are you starting the server before the client? Is the server set to accept incoming connections to port 45002 before the client starts transmitting to that port? – Thomas Owens Jul 22 '15 at 16:56
  • @ThomasOwens Yeah, Server before client, ports/IPs match up, and I have the server in a while loop with an `accept()` in it. But I have to remind you, this isn't only the programs I type, but anything that relies on Python's TCP socket protocol fails as well. Thanks for the input. – said Jul 22 '15 at 16:59

3 Answers3

1

The fact that you get the error 'No connection could be made because the target machine actively refused it.' Means that nobody is listening on the port you are trying to connect to. A TCP kernel responds with a RST each time someone tries to connect to a port where nobody is listening, on that IP@ so you are in fact reaching the host, but the host is not servicing anything on the port.

You did not forget to start your server by any chance ? Run netstat -a on the server machine you are trying to connect to so that it shows a list of ports it is in fact listening on.

Philip Stuyck
  • 7,344
  • 3
  • 28
  • 39
  • Nope, there is a server listening on the port. Still doesn't connect. Also, please keep in mind, the issue isn't only with my own Sockets, but both Twisted and IDLE can't connect on TCP sockets and return the same error. – said Jul 22 '15 at 18:48
  • Try a different machine. – Philip Stuyck Jul 22 '15 at 19:16
  • Will do as soon as possible. – said Jul 22 '15 at 19:28
  • Just tried it on another laptop. Although it didn't work, it didn't give me the same error, the error it gave me on the other laptop was about the server not being able to connect to the client, but on this laptop, the opposite is happening, the server doesn't even notice the connection, and the client just returns the error I mentioned in my OP. – said Jul 22 '15 at 21:28
  • First try everything with loopback on the same machine. – Philip Stuyck Jul 23 '15 at 00:16
  • Sorry, how would I do this? – said Jul 23 '15 at 03:09
  • You run Server and client code on the same machine and set the destination to localhost – ikstream Jul 23 '15 at 07:11
  • @ikstream Sorry, for some reason, StackOverflow didn't show a notification that someone commented. Anyway, same error. I have been running them on the IP of the current machine, so technically, although I wasn't putting localhost, I guess it still counted that way. – said Jul 26 '15 at 18:24
0

This type of error usually happens when the initial TCP SYN is replied to with a RST (reset). Unless something is seriously wrong with your OS, socket or Twisted, that message must have occurred on the wire - someone must have sent it, and that's the person to blame! :)

My advice is running wireshark on your computer in order to figure out where the RST is coming from.

If it comes from another device inside or outside your network, you must investigate that device.

If it comes from your computer, and you do have a socket listening at that address, the blame rests on your OS (or some program that meddles with it, such as a firewall, antivirus or virus).

If there's no RST message, something is wrong with your application (or Twisted, or python, or your OS), and you must investigate what caused the exception to be raised (check your stack trace).

loopbackbee
  • 21,962
  • 10
  • 62
  • 97
  • Is there any way you could possibly guide me through the steps? I have never used Wireshark, and I am new to networking as a whole, so I am pretty lost right now. Thanks for the input. – said Jul 22 '15 at 18:42
  • @Scoutdrago3 It's a bit involved to do it in this format, but wireshark has excellent documentation. My advice is to [download it](https://www.wireshark.org/download.html) and install it (just follow all installation steps carefully, including pcap ) and then check out the [Capturing live data section](https://www.wireshark.org/docs/wsug_html/#ChapterCapture) of the user guide, which should be enough for this task. Make sure to [filter](https://www.wireshark.org/docs/wsug_html/#ChWorkDisplayFilterSection) by `tcp`, in order to make things easier – loopbackbee Jul 23 '15 at 09:31
  • Hey, I got a few 3 minute TCP filtered captures where I started up a TCP connection and IDLE. Now, how do I find the ones that are being made by the specific programs that aren't working (pythonw.exe and IDLE)? – said Jul 26 '15 at 18:26
  • @Scoutdrago3 Ideally, try to minimize network traffic while capturing (close browser and other processes that might access the network) so its easier. You can't filter by specific programs, but you can filter by port with `tcp.port==X` – loopbackbee Jul 27 '15 at 09:23
  • So I found a problem. I figured out I could filter by port, so I went ahead and did that, and apparently neither IDLE nor my Python server/client is sending or receiving any packets. I filtered to the TCP port 45002 and started running my server, no packets. So then I ran my client. The client fails, returns the aforementioned error in the OP, and, oddly, still no packets received or sent. So then I filtered to 8833 (supposedly, the port for Python's IDLE's subprocess), started up IDLE, IDLE crashes, and nothing. No packets. Got any ideas? What would stop packets before they even get sent? – said Jul 28 '15 at 04:11
  • I don't think it's possible to get a connection refused error without sending any packets - more probably, there's a problem with your capture. Are you sure you're capturing on the right network interface? Also, make sure you're not connecting to localhost on Windows, as it does not have a [loopback interface](https://en.wikipedia.org/wiki/Loopback#Virtual_loopback_interface) for you to capture on – loopbackbee Jul 28 '15 at 11:44
  • Ah, so I should host the server on a different computer and run the client on this computer? – said Jul 28 '15 at 13:34
  • OK, so I hosted my server on a different computer on the network, and launched the client from my computer, and I saw some packets, but the server still returned an error about it not being able to `recv` the data because I am using a Datagram connection (I'm not, I made sure to include a ".connect(addr)"), and datagram connections use `.recvfrom` and `.sendto`. But the packets include no RSTs. They're all ACK, SEQ, etc..., and no FIN either. That still doesn't explain IDLE though. I am trying to find out what it's port is, since its obviously not 8833... – said Jul 28 '15 at 14:00
  • @Scoutdrago3 that seems like a completely different problem. You should probably ask another question. – loopbackbee Jul 28 '15 at 15:00
  • OK, well I'll do that, but after figuring out that IDLE uses any empty port, I had to set a port range filter, and even then, when I was 100% sure that it was using a port in the range (I am using cport with Wireshark), Wireshark wasn't picking up any packets. Thanks for all the help. – said Jul 28 '15 at 16:02
  • @Scoutdrago3 note that on a tcp connection there's two ports involved, the source and the destination port. The source port is usually random, but the destination isn't. `tcp.port` filters by both. – loopbackbee Jul 29 '15 at 14:43
  • I believe cports shows the source port. But as for the issue, I think I'm going go over to a few Networking and Tech Support websites and ask the question there, since this is no longer a coding question at all. I **greatly** appreciate all the help. – said Jul 29 '15 at 19:00
0

I couldn't read the complete post. Based on my knowledge in implementing Python for TCP servers and clients in many projects, I can give you a few tips.

  1. You have to enable TCP inbound rules on firewall on both server and client devices
  2. Correct IP address of the server is required to bind the socket connection in server
slfan
  • 8,950
  • 115
  • 65
  • 78
Lahiru
  • 1
  • 1