Painfully slow wireless SSH & Plex Server
-
@johnpoz
OK, you buried a few questions in your response so let me see if I cover them properly.There are no VLANs. Just a single LAN network. I have two Raspberry Pi 3s. One is a plex server and the other runs retropie. Both have terrible SSH speeds. When I write terrible SSH speeds, I mean: takes a very long time to connect. Sometimes they time out. When I type into the terminal, the key presses can take several minutes to respond. Interesting, the Plex server often serves up plex just fine (it streams to my Roku on the same LAN), however ssh connection into it is the terrible part.
I recently converted my network from a single wifi router-- a Linksys WRT1900ACS running OpenWrt-- to pfSense on an APU2E4 with a single TP-LINK EAP245 wireless access point. When using the Linksys, I had no issues with these two Pi 3Bs.
I recognize Pi's don't make for the best Plex, but it serves my purpose well for a couple years so I was OK with it.
By the way, I read that pfSense is not good for WiFi which is why I went for the AP rather than putting wifi cards intio the APU2E4.
-
See my edit.. How are you setup for your sshd.. Are you connecting via a fqdn, an IP? I posted up a connection from my pc to one of my pis..
Can you post such a connection attempt?
Once your connected - if slow to respond - what is the load on the pi?
top - 18:59:13 up 117 days, 2:11, 2 users, load average: 0.32, 0.08, 0.02 Tasks: 109 total, 1 running, 68 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.4 us, 0.8 sy, 0.0 ni, 98.6 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 999816 total, 94748 free, 125100 used, 779968 buff/cache KiB Swap: 102396 total, 102140 free, 256 used. 747848 avail Mem
-
@johnpoz
I've tried connecting both with a fqdn and an IP and had the same problems both ways. It gets weirder. I sat down to do a few of the things you asked, and in this case the Plex Server is largely working just fine-- ssh goes real well, no problems, as does a connection to the Plex server itself. But then 5 or 10 minutes go by and it starts taking very long to respond. It actually froze after I started running top so I couldn't give you the load on the pi. For several minutes I could not ssh into the retripie, but now I can and the verbose results are below. Although shortly after I produced this log in, the retropie is now very sluggish in responding. A few minutes go by, and SSH now responds properly.So now I am very confused. I am better off than I was yesterday, but now I have a very intermittent problem which is frustrating.
I really enjoy everything about my new setup-- pfSense on the APU2E4 plus the EAP245 WAP-- but this weird behavior restricted to the Pi3Bs is driving me batty. I'm glad it doesn't happen with my Sonos or Rokus or smartplugs or smart lights-- that would really drive my wife to the rails.
Eric
owner@iMac ~ % ssh -v pi@retropie.local.lan OpenSSH_8.1p1, LibreSSL 2.7.3 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 47: Applying options for * debug1: Connecting to retropie.local.lan port 22. debug1: Connection established. debug1: identity file /Users/owner/.ssh/id_rsa type 0 debug1: identity file /Users/owner/.ssh/id_rsa-cert type -1 debug1: identity file /Users/owner/.ssh/id_dsa type -1 debug1: identity file /Users/owner/.ssh/id_dsa-cert type -1 debug1: identity file /Users/owner/.ssh/id_ecdsa type -1 debug1: identity file /Users/owner/.ssh/id_ecdsa-cert type -1 debug1: identity file /Users/owner/.ssh/id_ed25519 type -1 debug1: identity file /Users/owner/.ssh/id_ed25519-cert type -1 debug1: identity file /Users/owner/.ssh/id_xmss type -1 debug1: identity file /Users/owner/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Raspbian-10+deb10u2 debug1: match: OpenSSH_7.9p1 Raspbian-10+deb10u2 pat OpenSSH* compat 0x04000000 debug1: Authenticating to retropie.local.lan:22 as 'pi' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ecdsa-sha2-nistp256 SHA256:+wGYxZ2WpoqGwKWeQowGCefWgJ0DLqD/3z7e7xTQeVI debug1: Host 'retropie.local.lan' is known and matches the ECDSA host key. debug1: Found key in /Users/owner/.ssh/known_hosts:46 debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 134217728 blocks debug1: Will attempt key: /Users/owner/.ssh/id_rsa RSA SHA256:5ii2IGShsbywD9tEMOzS8L2gIkFSU/MZ1gWVN53nJyg debug1: Will attempt key: /Users/owner/.ssh/id_dsa debug1: Will attempt key: /Users/owner/.ssh/id_ecdsa debug1: Will attempt key: /Users/owner/.ssh/id_ed25519 debug1: Will attempt key: /Users/owner/.ssh/id_xmss debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: /Users/owner/.ssh/id_rsa RSA SHA256:5ii2IGShsbywD9tEMOzS8L2gIkFSU/MZ1gWVN53nJyg debug1: Server accepts key: /Users/owner/.ssh/id_rsa RSA SHA256:5ii2IGShsbywD9tEMOzS8L2gIkFSU/MZ1gWVN53nJyg debug1: Authentication succeeded (publickey). Authenticated to retropie.local.lan ([192.168.152.94]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug1: Remote: /home/pi/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Remote: /home/pi/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 Linux retropie 5.4.72-v7+ #1356 SMP Thu Oct 22 13:56:54 BST 2020 armv7l The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Nov 9 17:59:21 2020 from 192.168.152.98 .***. Monday, 9 November 2020, 06:05:15 PM ***** Linux 5.4.72-v7+ armv7l GNU/Linux `***' |*| Filesystem Size Used Avail Use% Mounted on |*| /dev/root 29G 9.7G 19G 35% / ..|*|.. Uptime.............: 1 days, 08h07m15s .*** * ***. Memory.............: 397008kB (Free) / 764332kB (Total) *******@@** Running Processes..: 117 `*****@@**' IP Address.........: 192.168.152.94 `*******' Temperature........: CPU: 40°C/104°F GPU: 40°C/104°F `"""' The RetroPie Project, https://retropie.org.uk pi@retropie:~ $
-
You sure its just not loaded... Sounds like it just might be busy... You need to take a look at top.. And what the load values are.. pi's don't have a lot of horse power.. If you over tax them then they will be very sluggish..
Maybe looking to installing something like netdata to look at its history..
https://learn.netdata.cloud/guides/monitor/pi-hole-raspberry-pi
-
@johnpoz
Well, this behavior never happened with my old setup--using the Linksys WRT1900ACS wireless router. It's only been occuring once I moved to pfSense with the AP. Nothing has changed about the Pis, so I have to conclude is something about the Pi 3Bs interacting with new networking hardware.I'll look at netdata. I haven't heard of that before and it looks interesting.
-
Remarkably, this problem I was having with painfully slow wireless SSH with the Raspberry Pi 3s on my network vanished. I have no idea why because there was nothing I had done to correct it. A ghost in the machine, I guess.
-
Whatever it was it never had anything to do with pfsense ;)
Pfsense would never have been involved in any of that traffic.
-
@johnpoz
Eh, I claimed victory too early. SSH was well behaved with the two Pi 3s for about a day, and now it is back to not working.I'm surprised pfSense is not involved. Admittedly my knowledge isn't all that high but I figured the router was engaged is the LAN-side traffic (i.e., one device on LAN to another). Also, I never had SSH problems with my previous router (the Linksys running OpenWrt). Could it be the wireless AP? That is a new piece of my networking setup as well.
-
@slim0287 said in Painfully slow wireless SSH & Plex Server:
LAN-side traffic (i.e., one device on LAN to another)
No pfsense is the router to get off the LAN.. Devices talking to each other have no involvement with pfsense at all - other than say getting dhcp from it or dns - if your running those services on pfsense..
The only time pfsense would be involved in device talking to each other on the same network would be if you were running a bridge on pfsense, and device A and B were on different sides of the bridge.
-
@johnpoz
OK, in that case I suppose I have to consider if the TP-Link EAP245 is the issue. After all, both Pi3s were performing well when the Linksys WRT1900ACS was operating as the router and wireless access point. I switched to pfSense and the EAP245 WAP only about a month ago and had this issue.Thanks for pointing me in the correct direction for investigation.