Running Windows 7 Enterprise 64 bit, and Python 7.2.1 64 bit Python failed to read and send UDP packages when ran in cmd.exe. This is not the case when ran with IDLE.

Example; two simple programs. First one listening to a UDP port

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(('', 10015))

reading data from socket and printing the received data, using;
data, addr = sock.recvfrom(1024)

this will lock, if not ran from IDLE.

Same for sending data, using;

sock.sendto(DATA_MESSAGE, (HOST, 10015))

this will work with both, but only send when running from IDLE.

> this will lock

I should expect so! recvfrom is a blocking method. The interpreter will block on said socket until (if recvfrom) data arrives from the remote end of the socket.

sendto is non-blocking, though. And it works for me:

Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> sock.sendto('data', ('localhost', 1005))
4
>>>

Ah, bad formulation by me. While testing I had both the same machine and external machine sending UDP packages to the port I was listening to.

The listening server would not receive anything on 64/64bit (unless running from IDLE).

The reverse try, running the listening server (same program) on another computer, it would receive only from its own stream (while the 64/64 would only send packages while running from IDLE).

This was verified running Wireshark on both machines.

So in short, the 64/64 running from cmd.exe would not send or receive on UDP, while running from IDLE this was not the case.

I can't reproduce this. I'm also running 64-bit Python on 64-bit Windows 7 and socket operations are fine for me.

Kristoffer: are you using a personal firewall software? These filters often filter traffic out depending on what process is receiving it, so you may want to turn the firewall off (or explicitly configure it to allow this port to be open).

I am facing this same issue.

I set recvfrom to have a timeout of 5 seconds and stuck it in an infinite loop with some response code based on what is received.

The sending functionality of the socket is not compromised at all. It can always send. However, after about 10-20 minutes of normal operation (i.e. packets are being sent and received properly) - python stops being able to receive packets (but is still able to send them).

Cross-checking this with wireshark showed me that incoming packets are being received by the system (so the problem is somewhere between receiving them on the network adapter and accessing it in python).

I'm running 64bit Windows 7 with 2 network adapters (wired and wireless).

I also tried running the same python script in 4-200 processes simultaneously (but on different ports), and the error happens at the same time for ALL windows.

All firewalls are disabled.

> I set recvfrom to have a timeout of 5 seconds and stuck it in an
> infinite loop with some response code based on what is received.

Does it make a difference if you set specify a timeout?
Could you upload a script that reproduces the issue?
Also, which Python version have you been running?

I'm unsure what you mean by "set specify" a timeout, but I do use the "settimeout()" function.

I've stripped my program of everything that is not dealing with the socket and replaced the string being sent back with a dummy one. But this is essentially how it's laid out.

I'm using Python 2.7.2

I still can't reproduce it. I'm attaching client and server scripts that communicate over 127.0.0.1. This works just fine.

I solved the problem - sorry it's taken me so long to reply. I know how frustrating it is when people don't respond with what they found out in the end.

Turns out there's no bug as you said and it was based around something I did (as these things usually are). I was passing the packet as a string through redis before sending it which caused it to modify some bytes in there after they passed a certain value. I pickled the messages and it all worked in the end.

Sorry about the trouble and thanks for the help!

Thanks for your response! I'm closing the ticket.