One hour later… I get a prompt, I can enter userid/pass… but never get the prompt. TCPDUMP shows that the PiZ receives the packet if I press enter in putty, but I get no prompt after entering the password.
Weird!
A status on the service says that the password auth succeeded for root.
Then Putty times out and abort.
If I restart dropbear, I get back to the issue with no ask for user/pass.
There is something wrong here.
In the third line of the tcpdump the putty client is sending a reset packet, although it should be sending an ack.
In the next lines the dropbear is sending synack to putty, but putty seems to be ignoring them and keeps resending syn.
It looks to me that putty is not receiving the packets from dropbear, hence the high send-q number.
12h later, after a night’s sleep! All is ok, I can log in through dropbear and get a prompt.
Seems that every time I touch something on this Pi Zero, it takes 12h to stabilize and work!
Oh! Talking to fast here… I get a prompt but the prompt is frozen.
If in putty I press enter, I see on the console of the PiZero tcpdump an SEQ from putty and an ACK from dropbear. But nothing happens on the putty side. So I’m connected but I don’t get any response back in Putty!
Suddenly, the command I typed in putty, appeared like 2mins after. So I get something but goes through a wormhole to the alpha quadrant and back!
Looking at htop while blocked/slowed down, the CPU is 4% to 7% and I see 2 dropbear PIDs running. Both at 0% CPU.
Then for a few seconds, I get a responsive prompt I can do a couple of commands then lost connection.
Joulinar Interesting point… so from my PC, I still have the continuous ping running. I went to the PiZero console and stopped the networking.service. Ping stopped and was not picked-up by sometime else.
My network is DHCP between .10.10 and 10.149 leaving 10.1 to 10.9 for special devices like the PiZero with a static IP.
And nothing is registered on 10.3 and ping does not answer… so not an issue with duplicate IP.
Update: Unsure why, but I had to go through dietpi-config and re-apply the network config page to re-enable the network. Only doing a start on the service did not work.
I checked with putty again after a restart of network, still no prompt for login. “software caused connection abort”
tcpdump shows ack/win lines going both ways, from the PiZero to PC and back.
Running a ping -s 65500 from the PiZ to my router with no issue
Check arp tables of PC, RPi, and router to verify that they all have the correct mac/ip bindings.
Disconnect everything else from the network; leave only router, RPi and PC connected and try again.
Did you disconnect all other devices from the network, leaving the PC and the RPi only?
Also can you explain a bit the infrastructure you have there? Are both devices connected over the router or are there other devices, like switches, access points?
Do you have full control you and only you over these devices?
Are you using anytype of firewall, antivirus, antimalware on the RPi?
Have you tried to boot a clean installation of dietpi on a different SD card?
It should not be an issue. But give it a try.
Is the Access Point EAP245 running on latest firmware? I would try to factore restore it and apply a bare minimum configuration to make sure it works.
Tested on a 2.4G only SSID. Connected both PiZero and laptop, same issue. So it’s not an issue of 2.4G vs 5G
Then I tested another laptop connected with a wired connection to connect to the PiZero on a 2.4G wifi. So not going through wifi on the Putty side did not change that Putty cannot connect.
So…
Laptop (EAP245 wifi 5G) > PiZero (EAP245 2.4G) SSH on port 22 = Not working
Laptop (EAP245 wifi 5G) > PiZero (EAP245 2.4G) SSH on port 2222 = working
Laptop (EAP245 wifi 2.G) > PiZero (EAP245 2.4G) SSH on port 22 = Not working
Laptop (wired) > PiZero (EAP245 2.4G) SSH on port 22 = Not working
Laptop (Phone Wifi) > PiZero (Phone Wifi ) SSH on port 22 = working
Laptop (Bell-router Wifi) > PiZero (Bell router) SSH on port 22 = working
So, the issue is around port 22 over my EAP245 Wifi.
I checked the EAP245 config, no SSH is configured/activated on it. Firmware is up2date.
I don’t have issues doing ssh (putty) to remote servers over VPN/DirectAccess with the Wifi on EAP245
So, I’m about to close this case and put the PiZero ssh port to 2222
Ok! So I went back to port 2222… did not work like before! Then changed to port 1234… did not work… WTF!
So I reboot the AP EAP245 and bang, worked!
So it’s really the EAP245 which is buggy!
Went back to port 22… no issue!
I will open a ticket to TP-LINK
What a complicated path to find an issue… never thought an AP could be buggy for a specific protocol like SSH, since I’m doing a lot of SSH to work servers.
Thanks for all the brainstorming help guys… really appreciative.
Restarted DropBear
