firestack icon indicating copy to clipboard operation
firestack copied to clipboard

Err: Use of closed network connection

Open hussainmohd-a opened this issue 1 year ago • 1 comments

2024-06-02 21:23:51.184  8765-17004 GoLog  com.celzero.bravedns  E  multihost.go:142: W multihost: wg5dns no domains or ips
2024-06-02 21:23:51.184  8765-17004 GoLog  com.celzero.bravedns  E  wgconn.go:413: W wg: bind: wg5 recvFrom(invalid AddrPort): 0 / err? read udp4 0.0.0.0:42381: use of closed network connection
2024-06-02 21:23:51.184  8765-17004 GoLog  com.celzero.bravedns  E  wgconn.go:413: W wg: bind: wg5 recvFrom(invalid AddrPort): 0/ err? read udp6 [::]:42381: use of closed network connection

hussainmohd-a avatar Jun 02 '24 16:06 hussainmohd-a

I think these are caused by incorrect/stale bound/connected UDP socket.

Currently WireGuard transport creates and connects the underlying UDP socket on start, and uses the same UDP socket for subsequent send/recv. When connected, this UDP socket will bind to a local IP and port.

After network change/recovery, the host's IP address will change, and this UDP socket's local IP address is no long available. The socket API doesn't give any error for UDP on this socket, so it will seem sending successfully (althouth the packet may or may not arrive at the destation) and will receive nothing afterward.

This undetected dead UDP socket also cause problems for IPv6. Some ISP will change your prefix periodically, the host's IPv6 address will change and kill the previously bound UDP socket. And during startup, when the IPv6 address is in tentative state, the connect will succeed but bind to a link local IPv6 address, which also leave a dead socket.

I think the above conditions can be simulated by manually delete/change host's ( bound UDP socket's ) local IP address and tested using docker/netcat.

If we can't easily detect this, maybe we can just recreate/reconnect the UDP socket if haven't received anything for a specific duration.

From: https://github.com/SagerNet/sing-box/issues/1415#issuecomment-1986745713

ignoramous avatar Jul 26 '24 16:07 ignoramous

It's been a while since this has bit us. The many changes done to handle network/link changes seems to have mitigated this.

ignoramous avatar May 13 '25 22:05 ignoramous