Rpi3B+ ssh session drops randomly

Question

I have a Raspberry Pi 3 Model B Plus Rev 1.3 in my Ethernet network that runs headless with octoprint and an arduino pro mini connected to it via i2c. Wifi is disabled. The Rpi is powered from an official rpi power supply and the arduino has a dedicated 5v power supply. Rpi and arduino share a ground pin.

During the last week or so I tried to make a small flask page to control the rpi and the pro mini. I usually open two ssh sessions with putty, I run the development server in one session and the other is used for editing, etc. I load the flask page remotely from my pc with firefox successfully. However after some time -randomly- after I load some corrections/reloads to the page, I am kicked out of the ssh session. The other session usually is alive but again it may die as well. The rpi is alive, it is not crashing.

Looking at the following logs in /var/log/kern.log , messages , syslog, and dmesg I don't see anything.

I changed cables and Ethernet ports in the switch but the problem persists.

If this is a power thing how do I go around to verify it? If it is an Ethernet thing where do I look, what log do I look? If it is a time out of some sort what do I try and where (putty, rpi?) Is there any other suggestion? Thank you all!

1. Edit:

I have noticed also that although the session running the flask development server drops, the port and daemon/service still runs. I get an OSError: [Errno 98] Address already in use, when logging in again and trying to re-start flask. All sessions are down but the flask web server is running in the background. Also, the octoprint and 3d printing works without problems. This shows I think that it is not an Ethernet issue since octoprint continuously is in touch with a client pc.

2. Edit:

I have a putty log to post here if it shows anything (because of the length I have put the last incoming and last outgoing unsuccessfully):

Incoming packet #0x1de, type 94 / 0x5e (SSH2_MSG_CHANNEL_DATA)
  00000000  00 00 01 00 00 00 00 78 31 39 32 2e 31 36 38 2e  .......x192.168.
  00000010  31 2e 31 30 31 20 2d 20 2d 20 5b 33 30 2f 4d 61  1.101 - - [30/Ma
  00000020  72 2f 32 30 32 32 20 30 39 3a 33 33 3a 30 39 5d  r/2022 09:33:09]
  00000030  20 22 47 45 54 20 2f 62 61 73 69 63 5f 63 6f 6c   "GET /basic_col
  00000040  6f 75 72 3f 5f 5f 64 65 62 75 67 67 65 72 5f 5f  our?__debugger__
  00000050  3d 79 65 73 26 63 6d 64 3d 72 65 73 6f 75 72 63  =yes&cmd=resourc
  00000060  65 26 66 3d 75 62 75 6e 74 75 2e 74 74 66 20 48  e&f=ubuntu.ttf H
  00000070  54 54 50 2f 31 2e 31 22 20 32 30 30 20 2d 0d 0a  TTP/1.1" 200 -..
Outgoing packet #0x43, type 2 / 0x02 (SSH2_MSG_IGNORE)
  00000000  00 00 00 00                                      ....
Outgoing raw data at 2022-03-30 09:33:14
  00000000  97 ff ec 7b 24 fe 7b b7 92 f7 f4 e1 54 fb 75 68  ...{$.{.....T.uh
  00000010  39 43 e4 b2 72 1e fe a2 84 3a ec 46 1a b3 ba bc  9C..r....:.F....
  00000020  35 fa 42 82 05 bd 56 91 24 ac e7 69 3c ab 64 a9  5.B...V.$..i<.d.
Outgoing packet #0x44, type 2 / 0x02 (SSH2_MSG_IGNORE)
  00000000  00 00 00 00                                      ....
Outgoing raw data at 2022-03-30 09:33:24
  00000000  38 f0 ed 3a c1 5c fa a4 7f 09 2a b8 51 a5 a2 02  8..:.\....*.Q...
  00000010  6f a9 42 dc c1 12 a4 45 ec 79 60 5c 37 c0 ce d5  o.B....E.y`\7...
  00000020  6a 1d 66 af 8d 13 bf 91 80 b2 61 6d b3 71 d6 e6  j.f.......am.q..
Outgoing packet #0x45, type 2 / 0x02 (SSH2_MSG_IGNORE)
  00000000  00 00 00 00                                      ....
Outgoing raw data at 2022-03-30 09:33:34
  00000000  a8 2b 75 cb f0 7e 30 83 82 34 26 d9 92 5f 79 5c  .+u..~0..4&.._y\
  00000010  d3 03 9c 29 8f 5c 61 4f cd 67 11 02 e0 37 d7 49  ...).\aO.g...7.I
  00000020  25 6a cc e0 ca 4d 41 77 73 a9 ef ff a8 7c e2 48  %j...MAws....|.H
Outgoing packet #0x46, type 2 / 0x02 (SSH2_MSG_IGNORE)
  00000000  00 00 00 00                                      ....
Outgoing raw data at 2022-03-30 09:33:44
  00000000  d6 30 83 ea fa 85 4f 16 bc 01 5b 53 5b 99 41 ea  .0....O...[S[.A.
  00000010  e2 b7 57 cc 2a 0c df 17 4b 6f 16 af a1 b3 f8 b4  ..W.*...Ko......
  00000020  79 df 7d 51 47 ce bb cd b7 7b d7 88 34 8d c0 9e  y.}QG....{..4...
Event Log: Network error: Software caused connection abort

Answer 1

Have you tried pinging the Pi from another PC?

Does the ethernet interface stay up? E.G. does ifconfig show an IP address for your ethernet interface? (Usually called eth0)

You could try removing pieces of your Flask setup, to check when this random disconnect stops happening.

Maybe the Flask logs show something interesting?

Answer 2

It's possible this is a putty issue, as opposed to raspberry pi specifically. I frequently have to have multiple putty tabs open and connected at work, and disconnections/timeouts are frequent, especially if I haven't actively input commands recently (also at times, when running a .jar executable, timeouts will occur even though the java process is still ongoing.) Sometimes connections will timeout/disconnect twice in the span it takes another to disconnect

Based on your information, it seems the Pi itself is still online throughout these disconnects and timeouts. I would try playing around with putty settings, specifically keepalive settings. You can find these options under the 'Connection' tab before you connect to your pi, specifically enabling 'Enable TCP keepalives' and setting a keepalive timer. The Geek Diary has a blog post detailing how to enable this. They also include a picture of the settings you need, I'm not sure if I'm allowed to include that picture on SO (this is my first response!)

Hope this helps.

Answer 3

After multiple tries and modifications I think I have reached a stable state where ssh drops something like 1 time in 6 days, and this may be due to outside reasons like current drops or cable test. What I did that stabilized the setup was the following: I added a I2C Bi-Directional Logic Level Converter Module 5V to 3.3V circuit between the rpi and arduino. Although this is not necessary, because the rpi acts as a server in the i2c connection, let me to have a better common ground between the two components. Actually the common ground I was using was displaced after so many reconnections.

Answer 4

Wait wait, Network Packets... Put this Pi on a hub, and your "connecting" PC on it also. Do some of these processes. Run WireShark while doing them. Then you'll have the full network packet log to look at. Don't run more than 2 minutes of WireShark. Trolling all the data it always fun!

IMHO OctoPrint while not a services hog, can be. Why is the Arduino in this system? I've tried almost every model of Pi with OctoPrint. It's happiest in my experiences with a Pi 4b-4GB ... I got mine 2 years ago, when they were affordable. Good luck with your research.