One-way failure of UDP transmission with Python on Docker Desktop for Windows

[adevilliers]

Description

While using Docker Desktop on Windows with WSL2, I've encountered what appears to be a one-way UDP transmission failure when using Python UDP sockets in a particular way.

If I use a single Python socket.socket object to send UDP packets from a container to the Windows host, and vice-versa, I quickly get into the state where the container can receive messages from the host, but the host does not receive messages from the container.

This appears to happen only when "sharing" the socket object for both sending and receiving UDP, rather than using two separate socket objects.

When using host networking with --net=host, it appears to work for a short while (the time varies between one minute or several), after which the host ceases to receive any messages from the container.

I've left my WSL settings at their defaults. Likewise with Docker desktop, with the exception of enabling host networking:

Python code running on container (container.py)

import socket
import time

SEND_IP = "127.0.0.1"
SEND_PORT = 50101
RECEIVE_IP = "0.0.0.0"
RECEIVE_PORT = 50100

send_address = (SEND_IP, SEND_PORT)
recv_address = (RECEIVE_IP, RECEIVE_PORT)

if __name__ == "__main__":
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.settimeout(0.01)
    sock.bind(recv_address)
    
    message = b"Hello from container!"
    print(f"Listening on {recv_address}")
    print(f"Sending on {send_address}")
    
    while True:
        sock.sendto(message, send_address)
        print(f"Sent to {send_address}")
        try:
            data, addr = sock.recvfrom(1024)
            print(f"Received message from {addr}: {data.decode()}")
        except (socket.timeout, ConnectionResetError):
            pass
        time.sleep(1)

Python code running on Windows host (host.py)

import socket
import time

SEND_IP = "127.0.0.1"
SEND_PORT = 50100
RECEIVE_IP = "0.0.0.0"
RECEIVE_PORT = 50101

send_address = (SEND_IP, SEND_PORT)
recv_address = (RECEIVE_IP, RECEIVE_PORT)

if __name__ == "__main__":
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.settimeout(0.01)
    sock.bind(recv_address)
    
    message = b"Hello from host!"
    print(f"Listening on {recv_address}")
    print(f"Sending on {send_address}")
    
    while True:
        sock.sendto(message, send_address)
        print(f"Sent to {send_address}")
        try:
            data, addr = sock.recvfrom(1024)
            print(f"Received message from {addr}: {data.decode()}")
        except (socket.timeout, ConnectionResetError):
            pass
        time.sleep(1)

After stopping and restarting both scripts a few times and a few minutes have gone by, the container will be printing:

Sent to ('127.0.0.1', 50101)
Received message from ('127.0.0.1', 33060): Hello from host!
Sent to ('127.0.0.1', 50101)
Received message from ('127.0.0.1', 33060): Hello from host!

while the host will be printing:

Sent to ('127.0.0.1', 50100)
Sent to ('127.0.0.1', 50100)
Sent to ('127.0.0.1', 50100)
Sent to ('127.0.0.1', 50100)

i.e. no packet coming through from container -> host.

Is this a known issue? If so, is there a solution or workaround?

Thanks in advance.

Reproduce

Dockerfile

FROM python:3.12-slim

COPY . .

CMD ["python", "container.py"]

Building and starting the container

docker build -t dockertest .

docker run --rm -it --net=host dockertest

Running the script on the host

python host.py

Expected behavior

I would expect this to work (reliably) in both directions using host networking, i.e. the container should be printing something like:

Sent to ('127.0.0.1', 50101)
Received message from ('127.0.0.1', 58885): Hello from host!

and the host should be printing something like:

Sent to ('127.0.0.1', 50100)
Received message from ('127.0.0.1', 53786): Hello from container!

docker version

Client:
 Version:           27.5.1
 API version:       1.47
 Go version:        go1.22.11
 Git commit:        9f9e405
 Built:             Wed Jan 22 13:41:44 2025
 OS/Arch:           windows/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.38.0 (181591)
 Engine:
  Version:          27.5.1
  API version:      1.47 (minimum version 1.24)
  Go version:       go1.22.11
  Git commit:       4c9b3b0
  Built:            Wed Jan 22 13:41:17 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.25
  GitCommit:        bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e946
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    27.5.1
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v0.8.0
    Path:     C:\Users\drood\.docker\cli-plugins\docker-ai.exe
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.20.1-desktop.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v2.32.4-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.38
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Beta) (Docker Inc.)
    Version:  v0.1.4
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-dev.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.27
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.5
    Path:     C:\Program Files\Docker\cli-plugins\docker-feedback.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.16.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 6
 Server Version: 27.5.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
 runc version: v1.1.12-0-g51d5e946
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
 Kernel Version: 5.15.167.4-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 28
 Total Memory: 15.53GiB
 Name: docker-desktop
 ID: 54eb4d75-e644-42b6-a218-b720ceb8ae65
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile

Diagnostics ID

C34DD40D-59B9-44F2-9D83-AFA75093768D/20250226162832

Additional Info

I've noticed the following things:

1. The problem resolves temporarily when either restarting Docker Desktop or WSL (with wsl --shutdown).
2. The problem temporarily resolves when changing the bound port on the host.
3. The problem temporarily resolves when using published ports and the the IP of the WSL virtual adapter directly (as reported by ipconfig - output below), but ultimately also ends up in this one-way state. The docker command I used for this is docker run --rm -it -p 50100:50100/udp dockertest with the SEND_IP of container.py set to the gateway IP address.

Ethernet adapter vEthernet (WSL (Hyper-V firewall)):
   Connection-specific DNS Suffix  . :
   ...
   IPv4 Address. . . . . . . . . . . : 172.19.32.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

[adevilliers]

To elaborate further, what seems to trigger this relatively consistently is to run the container and the host script for a while, and then stop both of them. Wait a few minutes, then re-rerun both. Repeat this process until eventually the host stops receiving. It's almost as if the port bound on the host "goes to sleep".