0

A week back I posted this, and about 2 weeks back I posted this, both pertaining to an ever evolving issue with my Python sockets. I've also asked a question on the Wireshark Stack Exchange, and even after all 3 posts, I haven't been able to reach any conclusion. So heres the problem:

When I start up IDLE, it returns an error: IDLE Subprocess: socket error: No connection could be made because the target machine actively refused it and then I press ok on the dialogue boxes and it closes it out. But the issue isn't only limited to IDLE.

Any TCP ports I try to connect to via the Python socket module will fail. For example, if I run a server and a client (server first, of course, and both have the current IP of my computer and the port 45002) locally on my computer it returns: [Errno 10061] No connection could be made because the target machine actively refused it. So someone on an earlier post told me that running both the programs locally on a Windows machine will not work because it doesn't have a loopback interface (although when I look at my network interfaces via CMD, Loopback interface is listed for some reason). So then I went ahead and put the server on the computer with the issue, and the client on another computer on the network. It returns: [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. But for some reason, if I run the server on the other computer and then run the client on the computer with the issue, the server and client actually connect, and then the server fails claiming: [Errno 10057] A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied, even though I made sure to include a .connect(addr) in the client program. Sorry if this is getting confusing, but it's going to get a bit more complicated than this.

After this mess of running servers/clients on different computers, per request of another answerer on an early post, I installed Wireshark and began looking for packets being sent on the ports I am using. The results were a little weird. When I run the server on the computer with the issue, and the client on the other computer, Wireshark catches absolutely no packets on the port of the server, and the client fails with the errno 10060, as I said earlier. If I run the server from the other computer and the client from the computer with the issue, Wireshark catches some ordinary SYNs and ACKs. I only get an RST when I end the Python.exe process (this info is really only important to people who are good with Wireshark/networking, it's really only extra info).

I've also tried capturing packets from the IDLE program with Wireshark after I pinpointed the range of ports that it tends to use. When I start it up, no packets on any port in the range. Again, this is really just extra info to any of you who may be able to make something of it.

Again, sorry for the confusion, but I must go on.

And now, the issue that brought all this up. The problem that really caused me to ask myself "Hmm... Why is Python not working correctly?", my Twisted server was not able to import the reactor module returning the errno 10061. If you don't use/know of Twisted, all that's really needed to understand the problem is that, to import the reactor module, Twisted has to setup a Python TCP port, which is not working.

This issue has left me (and presumably everyone who's read it) scratching their head. I am sure that the ports I am using are not used. I'm sure the IP addresses are correct and matching. I am sure that there is no firewall blocking the connections, since I have tried running the programs without a firewall on with no luck. I am running a Wireless Windows 64bit laptop.

Heres my client program, and here's my server program, if they help at all.

Any suggestions, ideas, or answers are welcomed. At this point, any at all. Thanks.

P.S. If there is any info I can provide, or anything I can do to help find the solution to this issue, please tell. Also, I know this question is barely a programming one, so if there is somewhere else I am supposed to put this, please say and I'll move it over.

EDIT: Seems like I solved one piece of the puzzle. I can now connect a client on the computer with the issue to the computer with no issue, but not the other way around (running the client on the good computer, and running server on the broken one). I had to switch servSock.recv(buff) to cliSock.recv(buff) on the server side.

Community
  • 1
  • 1
said
  • 474
  • 4
  • 8
  • 18
  • Sorry if the question seems dumb, but isn't there a firewall(antivir), blocking the incoming connections on that particular machine? Aren't there in your network some routers that might be misconfigured or run a firewall? Isn't there an _IPv4/6_ mismatch in your network? Have you tried changing the port? Have you tried binding your server socket to `None` (all interfaces), and then try connecting with the client (locally/remotely)? – CristiFati Jul 28 '15 at 17:38
  • @CristiFati I'll go ahead and try all of those, and will report back. – said Jul 28 '15 at 17:42
  • @CristiFati I don't have a Antivirus, and I was told the router's firewall shouldn't have to do with this. Also, how could there be an IPV4/V6 mix up? And I don't know why changing the port would fix anything, since this is happening on multiple ports, some I can't even choose. And for the ones I do choose, they are not being used. – said Jul 28 '15 at 18:10
  • So you've tried on multiple ports. What do you mean by can't choose port? You can choose any port you want (as long as noone else is listening on it). Is the problem specific to _TCP_ sockets, or does it affect _UDP_. After you start your server program is it listening? You can check that by running the command: `netstat -an | findstr LISTEN`. Here's a thought: does this apply to windows server programs? For example _RDP_(port 3389, if configured), are you able to access it? to verify IP/port accesibility use `telnet ${IP} ${PORT}` (might require to install _telnet_ client). – CristiFati Jul 28 '15 at 18:20
  • @CristiFati Tried everything you suggested except the IPv4/6 mismatch and changing the port (I am 100% sure the port is OK to use). Still nothing. – said Jul 28 '15 at 18:20
  • @CristiFati When I said I couldn't choose the port, I was talking about how Twisted chooses a port on it's own, and how IDLE chooses any empty, usable port. I can't choose what port these two work on, but they still return the same errors. And no, UDP works perfectly, both locally and remotely. It's only TCP. And yes, CMD shows that it's listening. Also, telnet says "Connection failed", but I don't know what it's trying to connect to. And even then, I tested it on a bunch of other ports, they all returned the same error. How do I check if it applies to Server programs? Thanks for all the input – said Jul 28 '15 at 18:35
  • @CristiFati I was able to fix a piece of the problem, check for the edit. – said Jul 28 '15 at 18:55
  • Can you show the wireshark file when wireshark runs in the client side? It will be useful to see it in all cases. When you say "catches some ordinary SYNs and ACKs", it's important to see if those messages belong to the relevant intended communication. That is the only way you can get closer to the solution – rodolk Jul 28 '15 at 19:03
  • @rodolk There would be no point. Someone on another website fixed the issue where the client running on the bad computer can't connect to the server on the good computer, but the opposite still doesn't work, as it times out. It was really just a quick line switch. Read the edit in the original post for more info. – said Jul 28 '15 at 19:09
  • Now if you're able to connect from the bad computer (BC) to the good computer (GC), try writing some data at both ends and see if you can read it at the other ones. Also (from my prev comments) try to see if the problem applies to other server apps on the BC. I gave _RDP_ as an example. Try enabling _RDP_ (as i said _RDP_ server is a socket listening on port 3389) on BC, and see whether it's accessible (from BC and GC). Other example would be file sharing (_NetBIOS_ over _TCP_ , port 445). Regarding _UDP_ did you try sending/receiving data or just connecting? – CristiFati Jul 28 '15 at 19:51
  • @CristiFati Yeah, thats what I did. They were both aware that they were connected and they were working. I've used RDP before (connected to a Linux machine remotely), does that count? As for UDP, yes, I've done it both remotely and locally, sending messages between a client and server through a Datagram protocol. – said Jul 28 '15 at 22:01
  • _RDP_ is (mainly) for _Windows_. I noticed you are on _Windows_ based on socket error codes. I said.. connect with _RDP_ to the BC (bad computer), the one that you can't run the server app on (or you can run it but nothing is able to connect to it) – CristiFati Jul 28 '15 at 22:05
  • Only problem is, my version of WIndows doesn't allow remote desktop from one Windows machine to another. You have to have one of the more expensive versions (I think it's professional). – said Jul 28 '15 at 23:14

0 Answers0