Painfully slow wireless SSH & Plex Server
-
I am running pfSense 2.4.5 on an APU2E4 with a TP-Link EAP245 wireless access point. The setup works great although for the two wireless Raspberry Pi 3B+ that I have on my network, SSH is painfully slow, essentially not useable. One of the Pi 3B+ runs a Plex Server and this is often unreachable with WiFi. This is in contrast to a wireless Raspberry Pi 4 I have on the network which works fine with SSH.
As near as I can tell, the issue I am having is restricted to the Raspberry Pi 3B+ on WiFi. All other wifi and wired connections (combined, about 70 in total) I have work just fine.
Any ideas on how to approach this issue would be appreciated. I found a post from 2009 that suggested I put in the pfSense ip addresses for the DHCP server gateway and DNS address but that did not help.
Eric
-
Run a pcap on the connection, what's happening there? Load of re-transmissions?
It's almost certainly something in the wifi config though since other devices work OK. Probably not much you can do in pfSense.
Steve
-
I ran a pcap and there were not a load of re-transmissions. I will toy around with the wifi config on the clients.... but it is definitely weird that of all the wifi devices I have the only two that are misbehaving are Raspberry Pi 3Bs. Unfortunately one of them is headless and it's in a spot that makes it challenging for me to hook up a display, plus it is running dietpi so I don't have the luxury of just hooking up an ethernet connection and talking to it. Ah well, modern-day problems.
-
Different wifi chipset? Trying to use some weird non-standard mode?
1st world problems indeed.
-
@slim0287 said in Painfully slow wireless SSH & Plex Server:
TP-Link EAP245 wireless access point.
If your using an AP - how does this have anything at all to do with pfsense?
Going to move this to general off topic..
If your seeing ton of retrans then yeah going to suck..
Are you seeing a bunch of broadcast/multicast on this wifi network? You mention 70 other devices wired? Is this wifi same L2? You got a bunch of noise can really kill wifi performance. I would guess that your 4 wifi is better than your 3Bs? As for as connection speeds?
You mention "changing" gateway and dns to pfsense? What else would it have been if your using your 245 as AP?
-
He's not seeing re-transmissions.
-
@johnpoz
The AP is connected to the pfSense router so I thought it may be a pfSense problem. Granted, I don't claim to be an expert in this domain, just an enthusiastic user with moderate knowledge. So I'm happy to be corrected.I don't see any retrans at all. My wifi speeds are generally excellent. On the laptops I have as well as Samsung Galaxy tablets I see 300+ Mbps down, 300+ Mbps up, and the Rokus are usually around 80 Mbs, and I have an Xbox that is 200 Mbps down, 100 Mbs up. The 70+ devices are largely wifi, there are only 6 wired devices. Most of those 70 are smartplugs and the like, or Rokus that are usually off, Echos, Kindle e-readers, that kind of thing. So I am not using as much bandwidth as one might expect from the raw number of devices,
My Pi 4 has good WiFi although I never tested the speed. It is a server for a 3D Printer and I've had no problems with it, and SSH works great. It is the two 3B+'s that are nearly unserviceable for wifi SSH.
The "changing gateway" comment resulted from a netgate forum post I found on this issue from 2009. Granted that is 11 years ago:
https://forum.netgate.com/topic/12869/slow-ssh-access
To save you the trouble of going to the link, the single respondent wrote "I often have this problem too - it seems to have gone away once I specified the pfsense box's IP in the DHCP server section as the default gateway and DNS server. It should pass that through by default but I've noticed it doesn't always. My SSH connections are fast again for the time being."
So, I tried what the respondent suggested. As you suggest, as well as the respondent, it really shouldn't be necessary. And when I tried nothing changed so I reversed the modification.
My next step is I am going to get into the Pi 3's and re-establish the wifi connection, although one of them is in a very inconvenient spot to do so. But at this point, it is basically fiddling around to get it to work. I'd prefer to have a more directed approach.
-
Oh I misread that then - thought it said was seeing loads of retrans - doh! ;)
My point that this has nothing to do with pfsense, is your AP is a bridge that connects wifi to the wired network its attached to.. Pfsense is a router.. It has nothing to do with conversations between devices on the same L2.
If your clients are having issues that are on this wifi are having issue - then its on them, or the wifi. Or the AP connection to the network.
Pfsense is the router to route traffic from the L3 on that L2 to another L3 on a different L2.. Are you trying to stream from this plex server on a pi to something on another vlan? That routes through pfsense? Then pfsense might be involved - but pfsense has no clue to if the devices is wireless or wired, etc.
I would love to help you figure out your issues - its just not pfsense related.. For sure not wireless.. That section is related to running wireless on pfsense - which is never really a good idea either ;)
SSH is very low bandwidth sort of protocol - but it is realtime so if you are having drops or such then that could be problematic.. I have some 3B pis.. But they are all wired.. And I run multiple services for my network that are very time sensitive, dns, ntp, etc. I have no issues with them.. But they don't move about, there is little reason for them to be wireless ;)
What exactly happens with your ssh where you see this problem - long time to log in, then fine.. you type something and it doesn't show, you enter a command and it takes long to come back? You just loose the ssh connection?
While pis can sure serve up plex - they are not very "good" boxes for such services.. Especially if your having to transcode anything.
What is your configuration for your sshd, using dns can slow down the login process if not configured correctly, having it check for stuff your not actually using can slow down login like GSSAPIAuthentication, etc.
My logins to my pi's are pretty much instant from my pc, routed through pfsense.
Can you post up a connection using -v to show the login process?
C:\tools>ssh -v pi@pi-hole OpenSSH_8.4p1, OpenSSL 1.1.1f 31 Mar 2020 debug1: Connecting to pi-hole [192.168.3.10] port 22. debug1: Connection established. debug1: identity file /home/Johnpoz/.ssh/id_rsa type 0 debug1: identity file /home/Johnpoz/.ssh/id_rsa-cert type -1 debug1: identity file /home/Johnpoz/.ssh/id_dsa type -1 debug1: identity file /home/Johnpoz/.ssh/id_dsa-cert type -1 debug1: identity file /home/Johnpoz/.ssh/id_ecdsa type -1 debug1: identity file /home/Johnpoz/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/Johnpoz/.ssh/id_ecdsa_sk type -1 debug1: identity file /home/Johnpoz/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/Johnpoz/.ssh/id_ed25519 type 3 debug1: identity file /home/Johnpoz/.ssh/id_ed25519-cert type -1 debug1: identity file /home/Johnpoz/.ssh/id_ed25519_sk type -1 debug1: identity file /home/Johnpoz/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/Johnpoz/.ssh/id_xmss type -1 debug1: identity file /home/Johnpoz/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.4 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u7 debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u7 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002 debug1: Authenticating to pi-hole: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:EzN4/1q0mr8B4pmdZOsR5uyGB7DHMDzmcqlb/1I2eUE debug1: Host 'pi-hole' is known and matches the ECDSA host key. debug1: Found key in /home/Johnpoz/.ssh/known_hosts:4 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: /home/Johnpoz/.ssh/id_rsa RSA SHA256:XcDnfrK+1Djv2CpIaodjgpO8FwMBuHriXhdFCKvr/tE debug1: Will attempt key: /home/Johnpoz/.ssh/id_dsa debug1: Will attempt key: /home/Johnpoz/.ssh/id_ecdsa debug1: Will attempt key: /home/Johnpoz/.ssh/id_ecdsa_sk debug1: Will attempt key: /home/Johnpoz/.ssh/id_ed25519 ED25519 SHA256:y1pJFKtYk+f2IPWaiThbMdm9jRIkLOOIBMSS35Tgmyw debug1: Will attempt key: /home/Johnpoz/.ssh/id_ed25519_sk debug1: Will attempt key: /home/Johnpoz/.ssh/id_xmss debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,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: /home/Johnpoz/.ssh/id_rsa RSA SHA256:XcDnfrK+1Djv2CpIaodjgpO8FwMBuHriXhdFCKvr/tE debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/Johnpoz/.ssh/id_dsa debug1: Trying private key: /home/Johnpoz/.ssh/id_ecdsa debug1: Trying private key: /home/Johnpoz/.ssh/id_ecdsa_sk debug1: Offering public key: /home/Johnpoz/.ssh/id_ed25519 ED25519 SHA256:y1pJFKtYk+f2IPWaiThbMdm9jRIkLOOIBMSS35Tgmyw debug1: Server accepts key: /home/Johnpoz/.ssh/id_ed25519 ED25519 SHA256:y1pJFKtYk+f2IPWaiThbMdm9jRIkLOOIBMSS35Tgmyw debug1: Authentication succeeded (publickey). Authenticated to pi-hole ([192.168.3.10]: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 Last login: Mon Nov 9 18:49:27 2020 from 192.168.9.100 pi@pi-hole:~ $ -
@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.
