¿ªÔÆÌåÓý

  1. RaspberryPi-4-HamRadio
  2. Topics

[EXTERNAL] Re: [RaspberryPi-4-HamRadio] SSH Disconnects

 

Also, consider setting up the TCP Keep-alive feature in your PuTTY configuration (you've already saved it, so you can just double-click to restart the session, yes?).

Select your session from the list, then click the Load button... Under the "Connection" menu item, select the checkbox for TCP keep-alive, and then go back to the session tab, and save your configuration again. This may also be enough traffic to trigger DHCP to renew your lease again...

Best regards,

-Z-

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Ray Wells via groups.io
Sent: Tuesday, June 29, 2021 3:01 PM
To: [email protected]
Subject: [EXTERNAL] Re: [RaspberryPi-4-HamRadio] SSH Disconnects

Just a couple of thoughts off the top of my head:

is the DHCP lease in the router expiring in the time frame stated?

have you looked at dmesg to see if anything is reported?? Use (sudo) dmesg -T? to time stamp the entries.

Ray vk2tv

On 30/6/21 7:21 am, Tom McKee K4ZAD wrote:

I am running a WSPR TX using a Pi V1. It's WiFi controlled via my
router and Putty SSH on my main PC. Putty is set to send frequent
"keep alive" requests, and this gives me continuous control and
operation during the day.

However, each night around 0130 to 0230 UTC the connection is broken,
and I have to log in to the Pi again. The message that Putty pops up
to indicate the broken connection says that the Pi broke the
connection. This is strange as there must be many applications where
continuous log-in would be essential.

I've never done much with the Pi other that getting the WSPR TX going,
so I don't know much about the Pi OS. Is there is something built into
the Pi OS that automatically logs-out every 24 hours in the middle of
the night? If so, can this "feature" be disabled or can some "keep
alive" setting change or software be added to prevent this from
happening.

Any help will be much appreciated.

Thanks,? Tom?? K4ZAD

_
Tom McKee K4ZAD
 

Gosh, let's try this again. The first attempt was a mess.

Thanks guys for the responses. They set me on the way toward a possible resolution, which I haven¡¯t yet achieved.

SOME CLARIFICATIONS:

1.??? The Putty error message is - Network Error: Software caused connection to abort.
2.??? Several different Putty ¡°keep alive¡± time setting failed to prevent the problem.
3.??? The problem is not router based. Putty stays connected to the RPi, only the login to RPi is broken.
Also the router log shows no activity at the time of the problem.
4.??? If the RPi WSPR TX is run directly on the RPi (no SSH), the login does not break even after hours
of activity and also does not break at 01:30 to 02:30 UTC as it does when run via SSH.

I believe this indicates that the problem must be with the RPi¡¯s SSHD implementation.

ACTIONS TAKEN:

1.??? root/usr/share/openssh/sshd_config was edited to enable ClientAliveInterval and set its value to
14400 (4 hours) and to enable ClientAliveCountMax and set its value to 3. This provides 12 hours of
daylight operation, but does not stop the abort at 01:30 UTC. There are probably about 30 possible settings
in my sshd_config, but only 3 (5 with my changes) are enabled. I guess the defaults are generally OK, or
should others be enabled?
2.??? As suggested, I have viewed dmesg. but all I see there seems to relate to boot up, not loss of login.
Most of the other Internet advice about sshd logs is generic Linux and references files that I don¡¯t find on
my RPi.
3.??? I have looked at the log files in root/var/log. The applicable files all carry a time stamp consistent
with my logging back into Pi again after the abort. The only one that I can read is debug and there is nothing
in it with a time stamp consistent with the abort ¨C all times are for my re-logging into Pi.

So the problem remains, and any further suggestions would be appreciate.

Thanks,

Tom???? K4ZAD
 

" Network Error: Software caused
connection to abort."
is the error you get if the wifi disconnects from the Pi, then comes back, but the ssh connection isn't automatically restarted.? if you reboot the pi while you are ssh'd in you get the same message

On Tue, Jul 6, 2021 at 8:20 PM Tom McKee K4ZAD <tom.m@...> wrote:
Gosh, let's try this again. The first attempt was a mess.

Thanks guys for the responses. They set me on the way toward a possible
resolution, which I haven¡¯t yet achieved.

SOME CLARIFICATIONS:

1.??? The Putty error message is - Network Error: Software caused
connection to abort.
2.??? Several different Putty ¡°keep alive¡± time setting failed to
prevent the problem.
3.??? The problem is not router based. Putty stays connected to the RPi,
only the login to RPi is broken.
Also the router log shows no activity at the time of the problem.
4.??? If the RPi WSPR TX is run directly on the RPi (no SSH), the login
does not break even after hours
of activity and also does not break at 01:30 to 02:30 UTC as it does
when run via SSH.

I believe this indicates that the problem must be with the RPi¡¯s SSHD
implementation.

ACTIONS TAKEN:

1.??? root/usr/share/openssh/sshd_config was edited to enable
ClientAliveInterval and set its value to
14400 (4 hours) and to enable ClientAliveCountMax and set its value to
3. This provides 12 hours of
daylight operation, but does not stop the abort at 01:30 UTC. There are
probably about 30 possible settings
in my sshd_config, but only 3 (5 with my changes) are enabled. I guess
the defaults are generally OK, or
should others be enabled?
2.??? As suggested, I have viewed dmesg. but all I see there seems to
relate to boot up, not loss of login.
Most of the other Internet advice about sshd logs is generic Linux and
references files that I don¡¯t find on
my RPi.
3.??? I have looked at the log files in root/var/log. The applicable
files all carry a time stamp consistent
with my logging back into Pi again after the abort. The only one that I
can read is debug and there is nothing
in it with a time stamp consistent with the abort ¨C all times are for my
re-logging into Pi.

So the problem remains, and any further suggestions would be appreciate.

Thanks,

Tom???? K4ZAD

1 - 3 of 3