On Mon, 28 Mar 2022, RVP wrote: > On Mon, 28 Mar 2022, Jeremy C. Reed wrote: > > > Any ideas why telnet works slowly but ssh does not at all in these > > cases? telnet is usable but cannot even see one character sent over ssh > > when ssh locks up (again it restores about 5 to 10 seconds after I stop > > or suspend a speedtest or rsync job). > > > > Could be a QoS issue when a lot of packets are being xferred. > > Try out a few different QoS options (explicitly) in ssh (though it should > already be setting some kind of low-delay one by default): > > ssh -oIPQoS='lowdelay' ...
Thank you! That did not work for me for the client, but gave me a hint. The two clients I tried this from were Ubuntu Linux. At least one of them defaulted to that already. I don't think the QoS tagging or DCSP is honored on NetBSD by default. All of these work: 1) Connect to NetBSD router via telnet, then connect to itself again using ssh (so NetBSD ssh using defaults for ssh/sshd). 2) Run the NetBSD sshd with sshd_config "IPQoS none" instead of default of "af21 cs1" (first is for interactive) and use ssh (as is) from my Linux client. 3) Run the NetBSD sshd with sshd_config "IPQoS lowdelay throughput" instead of default of "af21 cs1" and use ssh from my Linux client. I wonder if the "af21" default on NetBSD sshd doesn't work as expected. Thanks again for the hint. I will need to understand the Ubuntu side better as it doesn't appear to have any iptables rules other than default ACCEPTs so I don't think it has any QoS. Maybe the ssh client (even when set to none) also honors the server-side sshd tagging and not the Linux kernel. > Adding QoS rules to PF/NPF might also help. pf.conf(5) has a bare-bones > example. I may try it later, but now I think the QoS is done on the Linux system. (I had done lots of testing with dscp with BIND named and also extensively tested and wrote about it for pfsense. I had no idea it was in sshd/ssh nor did I think I had anything utilizing it.)
