Hello I have a VERY WEIRD problem with 3 dietpi headless / serial connection not enabled => Network error connection refused
latest Dietpi version
1x Rpi 3a+, just had the time to install fresh version of Diepi, than I got the “Network error connection refused” after reboot
I tried again, a new fress install on a second Rpi 3a+ and got exactly the same issue.
I plugged in an other Rpi 3b+ with its own SD (that was still working yesterday), and got exactly the same issue, impossible to connect anymore !
In each case I see the IP address (Fing Oveerlook) and I can still access the logitech media server web page…
I erased the cache from my putty on Windows, tried from another Windows PC, Switched off and restarted my internet router, no way !
I tryed another router, not connected to Internet and from none of the peripherals had ever been connected to, still
Network error connection refused, although I got the IP address of each peripherals.
In other words, I can’t access anymore my long time running setup and I can’t install new setups !
Do you have any hints to recover the connection and most important to avoid this problem in the future ?
You said, you can successfully access other network services provided on your devices, but not ssh, correct?
Did you tried to ping the devices running DietPi? What was the result?
Do you have the chance to recover the log files from the DietPi devices, e.g. “journalctl -u ssh”? Do you see any error logs that may correspond to your problem?
Yes, you got it right, I can sort of ping the Pi as the Pi IP adress is seen by IP scanners and I can access the Media server that is running on the Pi.
Alas, as i didn’t allow serial access, I can’t investigate.
Anyway, TBH, I will not investigate further, I already lost too much time on that.
The only thing I’m thinking about that could result in such behaviour is Fail2Ban that was running on all these install
I’ve erased the SD card, as I couldn’t do anything and I will test a new fresh install without Fail2Ban.
I made a fresh new install, WITHOUT FAIL2BAN
And I got the exact same issue !
It happened just after that I changed the priorities, nice etc… with the dietpi-process_tool utility
I did the change and it corrupted my setup.
On my last setup I was wise to keep Serial connection so I just tried again to connect to my latest setup with a serial connection.
OK, I get access.
(Note that I should have thought of moding the DietPi/config.txt manually, it would have saved me a lot of time)
I had a look at the Dropbear service and found it inactive !
I made it active again and could connect through putty port 22.
However after each reboot, I get the same issue, meaning that the dropbear is again inactive and I have to activate it through Serial connection.
The result of : journalctl -u ssh
– No entries –
So now the questions are :
Why does dropbear can suddently become inactive without any inteaction from the user side ?
Strange, that “journalctl -u ssh” returns no logs on your machine. I am using OpenSSH. I see the start of the service in journalctl:
Jul 18 12:41:40 rasputin systemd[1]: Starting OpenBSD Secure Shell server...
Jul 18 12:41:40 rasputin sshd[2012]: Server listening on 0.0.0.0 port 22.
Jul 18 12:41:40 rasputin sshd[2012]: Server listening on :: port 22.
Jul 18 12:41:40 rasputin systemd[1]: Started OpenBSD Secure Shell server.
Jul 18 12:42:59 rasputin sshd[2402]: Accepted publickey for ...
I would expect that journalctl returns similar logs on your machine that show Dropbear has started. And I would expect logs when Dropbear transits to “inactive” …
Did you tried “systemctl status ssh” right before restarting Dropbear to get any hint what could cause the problem?
Although I could find some ways to avoid this problem, I would like to inform you that there is still a bug.
In fact there are a few.
1 Dropbear desactivated after cpu allocation
2 Console with no login prompt
3 Console no more activated
Dropbear desactivated after cpu allocation:
I confirm that this bug is still active since around 6.12
I have just tested it on the latest Dietpi version, headless, fresh minimal install, It is easy to replicate:
From ssh console, in DietPi-process_tool : change the CPU allocation of dropbear
When done, that’s it, no more access.
To solve the issue, one need to completely uninstall dropbear from the serial console, reboot and reinstall dropbear.
see the error reported (attachement)
I also encountered Console with no login prompt but can’t remember exactly what was involved
I also encountered Console unactivated which is quite annoying should you can’t access through ssh…
I am not able to reproduce this problem.
I remember in the past I changed the CPU Affinitiy, Sch. Policy, etc for processes, including dropbear and it never hanged.
I just tried it now and it still is responsive after restarting the dropbear service.
dietpi@odroid:[~]$ cat /etc/systemd/system/dropbear.service.d/dietpi-process_tool.conf
# WARNING: Do not manually edit this file, use "dietpi-services" to adjust values!
[Service]
CPUAffinity=0,1
CPUSchedulingPolicy=rr
CPUSchedulingPriority=64
IOSchedulingClass=realtime
Can’t access from ssh, and other services (http, samba…).
Connecting monitor to hdmi : no signal.
But pings replied…
I am on RPi 3 Model B (armv7l) - DietPi v6.30.0 , issue happened at same time when very huge nzb downloaded from sabnzb.
I think it’s cpu or ram issue, when sabnzb calculate all file before doing extract.
After 4 hours I decided to power off/on rpi, at now par2 it taking a lot of cpu and memory usage https://imgur.com/SSyAY9L.png
I sent a bug report if it has any information, reference code: 1b578e79-c7bf-44af-9d97-4ca47016f2e0
possibly that you are running out of CPU/Memory. As well I/O could be an issue. Are you going to download to an external device/HDD? If yes, which file system format did it use?
