Path: csiph.com!news.mixmin.net!news2.arglkargh.de!news.in-chemnitz.de!3.eu.feeder.erje.net!feeder.erje.net!news.mb-net.net!open-news-network.org!.POSTED!not-for-mail From: Marcel Mueller Newsgroups: comp.os.linux.networking Subject: How to get rid of client disconnected network sockets Date: Thu, 12 Jun 2025 12:54:16 +0200 Organization: MB-NET.NET for Open-News-Network e.V. Message-ID: <102ebko$2pkej$1@gwaiyur.mb-net.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 12 Jun 2025 10:54:16 -0000 (UTC) Injection-Info: gwaiyur.mb-net.net; logging-data="2937299"; mail-complaints-to="abuse@open-news-network.org" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:TQG6HFxOpJddSldaJ0xJpUcVSkQ= sha256:NgyiA8a5pR0PcsqQNx9eZwZ0a0glRlSTpIqojvV/1UI= sha1:2GwGsNcOjzbLHo6M+97w552BmW8= sha256:NAhON43UAWoiw8i/Z7wYC3u/9Z4Xaz+6sfFp8gtKPtk= Content-Language: de-DE, en-US Xref: csiph.com comp.os.linux.networking:8545 Hello! from time to time network sockets are stuck for a very long time when the client is no longer online: netstat -4np > tcp 0 0 192.168.121.129:40830 192.168.121.1:49000 VERBUNDEN 1449463/vdr > tcp 0 0 192.168.121.129:2049 192.168.121.137:939 VERBUNDEN - > tcp 0 0 192.168.121.129:2049 192.168.121.139:912 VERBUNDEN - > tcp 45 0 192.168.121.129:5143 192.168.121.24:41072 VERBUNDEN - > tcp 0 0 192.168.121.129:22 192.168.121.137:55826 VERBUNDEN 1475830/sshd-sessio > tcp 0 0 192.168.121.129:2049 192.168.121.143:857 VERBUNDEN - > tcp 0 0 192.168.121.129:22 192.168.121.137:42194 VERBUNDEN 1479707/sshd-sessio > tcp 45 0 192.168.121.129:5143 192.168.121.24:43014 VERBUNDEN - > tcp 45 0 192.168.121.129:5143 192.168.121.33:56454 VERBUNDEN - > tcp 0 0 192.168.121.129:5143 192.168.121.33:52444 VERBUNDEN 1460557/VBoxHeadles The clients 192.168.121.24 is disconnected for at least an hour, but the sockets at the server seem to stay for an infinite time. At some point I can no longer connect to the service at :5143. The client software (xfreerdp) just hangs. The only way to recover from this state is to end the listening process. Since this is a virtual machine this option is not very applicable. The lost connections are often related to client network disconnects, e.g. by a laptop entering suspend or WLAN interference. But this should result in a socket with state CLOSE_WAIT which is cleaned up after a short time. Of course, it is not reproducible. It happens only from time to time. How can I force the sockets to disconnect? System is Debian 13 running VBox headless VMs. (I do not use VBox NAT.) Marcel