Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Painfully slow wireless SSH & Plex Server

    Scheduled Pinned Locked Moved Off-Topic & Non-Support Discussion
    18 Posts 3 Posters 1.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      slim0287
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • S
          slim0287
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Different wifi chipset? Trying to use some weird non-standard mode?

            1st world problems indeed. 😁

            1 Reply Last reply Reply Quote 0
            • johnpozJ
              johnpoz LAYER 8 Global Moderator
              last edited by johnpoz

              @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?

              An intelligent man is sometimes forced to be drunk to spend time with his fools
              If you get confused: Listen to the Music Play
              Please don't Chat/PM me for help, unless mod related
              SG-4860 24.11 | Lab VMs 2.8, 24.11

              S 1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                He's not seeing re-transmissions.

                1 Reply Last reply Reply Quote 0
                • S
                  slim0287 @johnpoz
                  last edited by

                  @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.

                  1 Reply Last reply Reply Quote 0
                  • johnpozJ
                    johnpoz LAYER 8 Global Moderator
                    last edited by johnpoz

                    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:~ $
                    

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 24.11 | Lab VMs 2.8, 24.11

                    S 1 Reply Last reply Reply Quote 0
                    • S
                      slim0287 @johnpoz
                      last edited by

                      @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.

                      1 Reply Last reply Reply Quote 0
                      • johnpozJ
                        johnpoz LAYER 8 Global Moderator
                        last edited by johnpoz

                        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
                        

                        An intelligent man is sometimes forced to be drunk to spend time with his fools
                        If you get confused: Listen to the Music Play
                        Please don't Chat/PM me for help, unless mod related
                        SG-4860 24.11 | Lab VMs 2.8, 24.11

                        S 1 Reply Last reply Reply Quote 0
                        • S
                          slim0287 @johnpoz
                          last edited by

                          @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:~ $ 
                          
                          1 Reply Last reply Reply Quote 0
                          • johnpozJ
                            johnpoz LAYER 8 Global Moderator
                            last edited by johnpoz

                            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

                            An intelligent man is sometimes forced to be drunk to spend time with his fools
                            If you get confused: Listen to the Music Play
                            Please don't Chat/PM me for help, unless mod related
                            SG-4860 24.11 | Lab VMs 2.8, 24.11

                            S 1 Reply Last reply Reply Quote 0
                            • S
                              slim0287 @johnpoz
                              last edited by

                              @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.

                              1 Reply Last reply Reply Quote 0
                              • S
                                slim0287
                                last edited by

                                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.

                                1 Reply Last reply Reply Quote 0
                                • johnpozJ
                                  johnpoz LAYER 8 Global Moderator
                                  last edited by

                                  Whatever it was it never had anything to do with pfsense ;)

                                  Pfsense would never have been involved in any of that traffic.

                                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                                  If you get confused: Listen to the Music Play
                                  Please don't Chat/PM me for help, unless mod related
                                  SG-4860 24.11 | Lab VMs 2.8, 24.11

                                  S 1 Reply Last reply Reply Quote 0
                                  • S
                                    slim0287 @johnpoz
                                    last edited by slim0287

                                    @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.

                                    1 Reply Last reply Reply Quote 0
                                    • johnpozJ
                                      johnpoz LAYER 8 Global Moderator
                                      last edited by

                                      @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.

                                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                                      If you get confused: Listen to the Music Play
                                      Please don't Chat/PM me for help, unless mod related
                                      SG-4860 24.11 | Lab VMs 2.8, 24.11

                                      S 1 Reply Last reply Reply Quote 0
                                      • S
                                        slim0287 @johnpoz
                                        last edited by

                                        @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.

                                        1 Reply Last reply Reply Quote 0
                                        • First post
                                          Last post
                                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.