I have TOPS-20 (the Panda monitor) running on a KLH-10 hosted on
FreeBSD 13.0-RELEASEp4 (that is, the latest released version of
FreeBSD). It uses TAP/TUN to provide the KLH-10 emulated ethernet
direct access to the host network, over a simulated bridge. That
seems to work, and I can connect just fine to and from TOPS-20 and
the other machines on the network. So far, so good.

Now here's where it gets weird: I tend to open a connection from a
machine and let it sit idle when I'm doing other work. But, if I
connect from a BSD-based machine (FreeBSD or OpenBSD), then about
once every 24 hours the connection simply vanishes, by which I
mean that the telnet client errors out and the session on the
KLH-10 is gone. It doesn't seem to matter whether I'm connecting
from the machine running klh10 or another machine, nor whether
it's a local ethernet segment or something else. Curiously, if I
run `tcpdump` and monitor the connection, there is no traffic
related to the connection, nor its disappearance (e.g., I don't
see a reset segment or anything sent over the link).

If I login from Linux, this does not happen. It seems specific
to BSD-based TCP/IP stacks.

Has anyone else observed anything like this?

Thank you!

- Dan C.

On 11/2/21 3:29 PM, Dan Cross wrote:
> Has anyone else observed anything like this?

This hints of a firewall thinking that the session is expired and
clearing -- what it considers to be -- stale state thus forcefully
closing the connection.

See if you can enable TCP level keep alive traffic.

--
Grant. . . .
unix || die

On Tuesday, November 2, 2021 at 2:29:51 PM UTC-7, Dan Cross wrote:
>
(snip)

> Now here's where it gets weird: I tend to open a connection from a
> machine and let it sit idle when I'm doing other work. But, if I
> connect from a BSD-based machine (FreeBSD or OpenBSD), then about
> once every 24 hours the connection simply vanishes, by which I
> mean that the telnet client errors out and the session on the
> KLH-10 is gone.

(snip)

You didn't say if it happens to any other hosts.

Last time I had that, it was from the autologout variable in the shell, which for
some reason had a default value that I didn't know about.

Otherwise, my Macbook is set to sleep after a while, which also (eventually)
times out the TCP connections. It might be an hour or so. You might check for
any sleep modes.

In article <slsf4i$uiu$1@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 11/2/21 3:29 PM, Dan Cross wrote:
>> Has anyone else observed anything like this?
>
>This hints of a firewall thinking that the session is expired and
>clearing -- what it considers to be -- stale state thus forcefully
>closing the connection.
>
>See if you can enable TCP level keep alive traffic.

No, sadly; this is on effectively the same host and/or a directly
connected Ethernet segment. There is no firewall involved between
the hosts involved. Logging in from a Linux host one the same
ethernet segment does not exhibit the same behavior.

- Dan C.

In article <f8ca3183-9cc9-4f7b-87c2-b56ba4e99685n@googlegroups.com>,
gah4 <gah4@u.washington.edu> wrote:
>On Tuesday, November 2, 2021 at 2:29:51 PM UTC-7, Dan Cross wrote:
>>
>(snip)
>
>> Now here's where it gets weird: I tend to open a connection from a
>> machine and let it sit idle when I'm doing other work. But, if I
>> connect from a BSD-based machine (FreeBSD or OpenBSD), then about
>> once every 24 hours the connection simply vanishes, by which I
>> mean that the telnet client errors out and the session on the
>> KLH-10 is gone.
>
>(snip)
>
>You didn't say if it happens to any other hosts.

I thought that I mentioned that it doesn't happen when I login from
a Linux host? Regardless, it seems specific to the combination of
TOPS-20 and BSD TCP/IP stacks. Similar things do not happen between
various configurations of other hosts on the same network.

>Last time I had that, it was from the autologout variable in the shell, which for
>some reason had a default value that I didn't know about.

Sadly, that's not the issue. Even if it were, I would expect to
see _some_ TCP traffic exchanged; at the minimum, an RST segment
when the connection was terminated by one side or the other. That
it doesn't happen when I login to the same TOPS-20 host from a
machine running Linux on the same network would further suggest
that this isn't the case.

>Otherwise, my Macbook is set to sleep after a while, which also (eventually)
>times out the TCP connections. It might be an hour or so. You might check for
>any sleep modes.

These connections are between server hosts on the same network
that never go into powersaving modes in that sense. In particular,
the connection from, say, my workstation to the BSD machine does
not close, only the connection from the BSD host to TOPS-20.

- Dan C.

On Wednesday, November 3, 2021 at 9:34:28 AM UTC-7, Dan Cross wrote:

(snip)

> Sadly, that's not the issue. Even if it were, I would expect to
> see _some_ TCP traffic exchanged; at the minimum, an RST segment
> when the connection was terminated by one side or the other. That
> it doesn't happen when I login to the same TOPS-20 host from a
> machine running Linux on the same network would further suggest
> that this isn't the case.

I only sort-of know how this works, as most often it does.

https://en.wikipedia.org/wiki/Keepalive#TCP_keepalive

Well, one not so unusual one partly indicated by other replies,
is from NAT routers, that have to keep NAT connections open.

But even without that, there is a system for keeping TCP connections
open without any traffic, such as an idle telnet, rsh, or ssh connection.

It would, then, be a lack of keep-alive packets that close the connection.

I do remember, many years ago now, having a problem keeping
connections open, where I had a background program on the
remote end that would periodically send a null character.
I suspect that was related to NAT, as it was close to the beginning
of the need to use NAT.

You might figure out which end closes the connection,
(and goes away) first, to figure out which end to debug.

I haven't thought of the actual keep-alive intervals, though.
I do know that the remote end goes away fast enough after
my Macbook sleeps, that I don't worry about chasing them down.

In article <fd0a893f-6f10-4adc-98f2-5be41b602b81n@googlegroups.com>,
gah4 <gah4@u.washington.edu> wrote:
>On Wednesday, November 3, 2021 at 9:34:28 AM UTC-7, Dan Cross wrote:
>
>(snip)
>
>> Sadly, that's not the issue. Even if it were, I would expect to
>> see _some_ TCP traffic exchanged; at the minimum, an RST segment
>> when the connection was terminated by one side or the other. That
>> it doesn't happen when I login to the same TOPS-20 host from a
>> machine running Linux on the same network would further suggest
>> that this isn't the case.
>
>I only sort-of know how this works, as most often it does.
>
>https://en.wikipedia.org/wiki/Keepalive#TCP_keepalive
>
>Well, one not so unusual one partly indicated by other replies,
>is from NAT routers, that have to keep NAT connections open.

Indeed, but there is no NAT involved here at all.

>But even without that, there is a system for keeping TCP connections
>open without any traffic, such as an idle telnet, rsh, or ssh connection.
>
>It would, then, be a lack of keep-alive packets that close the connection.

That strikes me as odd; TCP connections are defined to stay
open in the absense of keepalives until explicitly closed.
In this case, the connection doesn't simply close; it vanishes.
No traffic is exchanged on the network at all.

>I do remember, many years ago now, having a problem keeping
>connections open, where I had a background program on the
>remote end that would periodically send a null character.
>I suspect that was related to NAT, as it was close to the beginning
>of the need to use NAT.
>
>You might figure out which end closes the connection,
>(and goes away) first, to figure out which end to debug.

Yes, that's good advice. I'll see if I can put together some
scaffolding to see what's going on.

I take it no one else has noticed similar behavior, though?

- Dan C.

On Thursday, November 4, 2021 at 8:38:04 AM UTC-7, Dan Cross wrote:

(snip)

> That strikes me as odd; TCP connections are defined to stay
> open in the absense of keepalives until explicitly closed.
> In this case, the connection doesn't simply close; it vanishes.
> No traffic is exchanged on the network at all.

But there are too many ways to break one side.

As I said above, my Macbook will sleep, and eventually the connection
times out. But I could reboot, or otherwise close the client side of the
ssh connection, and then fill up the server with sshd, waiting for
the other side. So there is keepalive to kill them off after a while.

It seems that on systems descendant from BSD, there are TCP
options set with setsockopt() that control keepalive timing.

I don't see a way for sshd to set them, though.

gah4 <gah4@u.washington.edu> writes:
>On Thursday, November 4, 2021 at 8:38:04 AM UTC-7, Dan Cross wrote:
>
>(snip)
>
>> That strikes me as odd; TCP connections are defined to stay
>> open in the absense of keepalives until explicitly closed.
>> In this case, the connection doesn't simply close; it vanishes.
>> No traffic is exchanged on the network at all.
>
>But there are too many ways to break one side.
>
>As I said above, my Macbook will sleep, and eventually the connection
>times out. But I could reboot, or otherwise close the client side of the
>ssh connection, and then fill up the server with sshd, waiting for
>the other side. So there is keepalive to kill them off after a while.
>
>It seems that on systems descendant from BSD, there are TCP
>options set with setsockopt() that control keepalive timing.
>
>I don't see a way for sshd to set them, though.

The client can enable keepalives.

$ cat ~/.ssh/config
StrictHostKeyChecking ask
ForwardX11 yes
KeepAlive yes

On 11/5/21 3:22 PM, Scott Lurndal wrote:
> KeepAlive yes

+1

--
Grant. . . .
unix || die