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

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: MB-NET.NET for Open-News-Network e.V. (3:633/280.2@fidonet)

On Thu, 12 Jun 2025 12:54:16 +0200, Marcel Mueller wrote:

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.

This to me points to a defect in the protocol, that it does not
periodically exchange “are you there?” packets (even, say, once every 1 minute or 5 minutes), just to be sure the other end is still up.

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 12 Jun 2025 12:54:16 +0200, Marcel Mueller wrote:

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.

This to me points to a defect in the protocol, that it does not
periodically exchange "are you there?" packets (even, say, once every 1 minute or 5 minutes), just to be sure the other end is still up.

But maybe the network connection was just interrupted and it'll be
back in a few minutes? Since my home internet via mobile broadband
is unreliable that often happens during SSH sessions. I can come
back in 15min and my SSH terminals are all working again after the
signal came back (well, not always, but sometimes). Mosh, which
uses UDP, handles that better though.

--
__ __
#_ < |\| |< _#

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: Ausics - https://newsgroups.ausics.net (3:633/280.2@fidonet)

On 13 Jun 2025 22:38:34 +1000, Computer Nerd Kev wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 12 Jun 2025 12:54:16 +0200, Marcel Mueller wrote:

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.

This to me points to a defect in the protocol, that it does not
periodically exchange "are you there?" packets (even, say, once every 1
minute or 5 minutes), just to be sure the other end is still up.

But maybe the network connection was just interrupted and it'll be back
in a few minutes?

Set the timeout accordingly.

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Am 13.06.25 um 14:38 schrieb Computer Nerd Kev:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 12 Jun 2025 12:54:16 +0200, Marcel Mueller wrote:

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.

This to me points to a defect in the protocol, that it does not
periodically exchange "are you there?" packets (even, say, once every 1
minute or 5 minutes), just to be sure the other end is still up.

But maybe the network connection was just interrupted and it'll be
back in a few minutes? Since my home internet via mobile broadband
is unreliable that often happens during SSH sessions. I can come
back in 15min and my SSH terminals are all working again after the
signal came back (well, not always, but sometimes).

For this purpose I would recommend "screen". It keeps your ssh session
as long as you like.

Mosh, which
uses UDP, handles that better though.

UDP sadly fails if a NAT router is in between. Since it cannot know when
the connection is closed it just discards the port after a timeout w/o traffic, typically only a few minutes.


--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: MB-NET.NET for Open-News-Network e.V. (3:633/280.2@fidonet)

On Sat, 14 Jun 2025 11:56:11 +0200, Marcel Mueller wrote:

Am 13.06.25 um 14:38 schrieb Computer Nerd Kev:

Mosh, which uses UDP, handles that better though.

UDP sadly fails if a NAT router is in between. Since it cannot know when
the connection is closed it just discards the port after a timeout w/o traffic, typically only a few minutes.

Again, that depends on the application-level protocol. If that has
provision for sending “noop” replies and responses, then there is a way to keep the NAT context alive, even when there is no actual data to be
passed.

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote at 09:56 this Saturday (GMT):

Am 13.06.25 um 14:38 schrieb Computer Nerd Kev:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Thu, 12 Jun 2025 12:54:16 +0200, Marcel Mueller wrote:

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.

This to me points to a defect in the protocol, that it does not
periodically exchange "are you there?" packets (even, say, once every 1
minute or 5 minutes), just to be sure the other end is still up.

But maybe the network connection was just interrupted and it'll be
back in a few minutes? Since my home internet via mobile broadband
is unreliable that often happens during SSH sessions. I can come
back in 15min and my SSH terminals are all working again after the
signal came back (well, not always, but sometimes).

For this purpose I would recommend "screen". It keeps your ssh session
as long as you like.

Or tmux.

Mosh, which
uses UDP, handles that better though.

UDP sadly fails if a NAT router is in between. Since it cannot know when
the connection is closed it just discards the port after a timeout w/o traffic, typically only a few minutes.

Is there any way to change the timeout period?
--
user <candycane> is generated from /dev/urandom

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: the-candyden-of-code (3:633/280.2@fidonet)

Am 18.06.25 um 07:30 schrieb candycanearter07:

UDP sadly fails if a NAT router is in between. Since it cannot know when
the connection is closed it just discards the port after a timeout w/o
traffic, typically only a few minutes.

Is there any way to change the timeout period?

With OpenWRT: likely. But I have never seen a ready-to-use or provider
router that allows this kind of setting.


Marcel

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: MB-NET.NET for Open-News-Network e.V. (3:633/280.2@fidonet)