Solved SSH freeze

R

rmomota

Hi,

Whenever I connect to other server I'm able to login and do few commands and the session freeze while I'm typing.
When frozen sometimes some chars I typed still appear very slowly one by one and freeze again.
Then after several minutes it disconnects with the error:
client_loop: send disconnect: Broken pipe

I'm able to connect to the same server if I use Linux with no problem at all.
I can see the difference between both is the OpenSSH version
FreeBSD is using OpenSSH_8.8p1 and Linux OpenSSH_9.2p1
I don't know if this makes any difference on the problem I'm reporting.

Anyone have this issue too?
 
rmomota said:
I'm able to connect to the same server if I use Linux with no problem at all.
Click to expand...
On the same machine? :-/ Because, this is a typical description of a network problem. First try ping when it happens. Also, Firewalls can easily cause such issues.
 
rmomota said:
I'm able to browse the web when SSH session is frozen.
Click to expand...
Browsers tend to have multiple connections, all running multiple, typically small, fetches. There might be a noticeable delay loading parts of the page, but you don't pick this up as easily as the browser will swiftly create a new connection if one goes down. You often don't even notice the bad connection when browsing.
 
And also, it's connecting to completely different machines. Might be relevant if this turns out to be a firewall issue.
 
I'm able to watch youtube while the SSH is frozen.
Even with 2 laptops side by side connecting to the same server using the same network only the FreeBSD one freezes.
 
Ok, let's stop guessing. Please post the contents of your /etc/rc.conf, the output of ifconfig and the output of netstat -rn.
 
SirDice said:
Browsers tend to have multiple connections, all running multiple, typically small, fetches. There might be a noticeable delay loading parts of the page, but you don't pick this up as easily as the browser will swiftly create a new connection if one goes down. You often don't even notice the bad connection when browsing.
Click to expand...
Yes, it can be networking issues.
I've another post regarding networking wifi issues.
/etc/rc.conf
Code: 
clear_tmp_enable="YES"
syslogd_flags="-ss"
sendmail_enable="NONE"
hostname="beethoven"
keymap="pt.acc.kbd"
wlans_iwn0="wlan0"
ifconfig_wlan0="country PT regdomain ETSI WPA DHCP"
sshd_enable="YES"
moused_enable="YES"
ntpdate_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
polkit_enable="YES"
rc_startmsgs="NO"
lightdm_enable="YES"
webcamd_enable="YES"
cupsd_enable="YES"
kld_list="i915kms fusefs"
vboxnet_enable="YES"
devfs_system_ruleset="system"
ifconfig_vboxnet0="DHCP"
webcamd_enable="YES"
cupsd_enable="YES"
dbus_enable="YES"
hcsecd_enable="YES"
ifconfig_em0="DHCP"
hald_enable="YES"
netstat -rn
Code: 
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.1.1        UGS       wlan0
127.0.0.1          link#2             UH          lo0
192.168.1.0/24     link#3             U         wlan0
192.168.1.92       link#3             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
::/96                             ::1                           UGRS        lo0
::1                               link#2                        UHS         lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
fe80::/10                         ::1                           UGRS        lo0
fe80::%lo0/64                     link#2                        U           lo0
fe80::1%lo0                       link#2                        UHS         lo0
ff02::/16                         ::1                           UGRS        lo0
 
Ok, routing table looks fine (assuming you indeed don't use IPv6) and I don't see any firewall stuff here.

Then next (as mentioned) above: can you ping this remote host? can you still ping it once you lost your SSH connection?
 
Not related to the current issue but webcamd_enable and cupsd_enable is mentioned twice. You can remove polkit_enable and hald_enable, they do nothing at all.

One issue that could popup:
Code: 
wlans_iwn0="wlan0"
ifconfig_wlan0="country PT regdomain ETSI WPA DHCP"
{...}
ifconfig_em0="DHCP"
If both these interfaces are up and receiving DHCP on the same network you may get some nasty routing issues. But from your netstat -rn output I can see em0 is disabled, that's good. Enable one or the other interface, not both.

zirias@ said:
Then next (as mentioned) above: can you ping this remote host?
Click to expand...
Yes, first step of network debugging. Ping your default gateway and the host you're trying to connect to. Make sure there's no packet loss being recorded. And the RTT (Round Trip Time) is reasonable. A fairly descent local gigabit network should show 0.100-0.200 ms. Wireless has a bit more latency, so the numbers might be a little higher.
 
zirias@ said:
Ok, routing table looks fine (assuming you indeed don't use IPv6) and I don't see any firewall stuff here.

Then next (as mentioned) above: can you ping this remote host? can you still ping it once you lost your SSH connection?
Click to expand...

Or just leave ping running to the destination host in one terminal while you SSH to it in another. Look for any change to ping times when your SSH misbehaves.

It’s (ping) not perfect at blaming/absolving the network but it can detect general latency / connectivity issues. (I had issues with SAMBA performance at one point but not SSH+rsync to the same host due to a SAMBA QOS setting and a flaky router.)
 
ping works just fine but ssh still freeze
64 bytes from 192.168.1.68: icmp_seq=137 ttl=64 time=1.782 ms
64 bytes from 192.168.1.68: icmp_seq=138 ttl=64 time=1.414 ms
64 bytes from 192.168.1.68: icmp_seq=139 ttl=64 time=1.411 ms
64 bytes from 192.168.1.68: icmp_seq=140 ttl=64 time=1.348 ms
64 bytes from 192.168.1.68: icmp_seq=141 ttl=64 time=1.879 ms
 
Eric A. Borisch said:
Or just leave ping running to the destination host in one terminal while you SSH to it in another. Look for any change to ping times when your SSH misbehaves.

It’s (ping) not perfect at blaming/absolving the network but it can detect general latency / connectivity issues. (I had issues with SAMBA performance at one point but not SSH+rsync to the same host due to a SAMBA QOS setting and a flaky router.)
Click to expand...
It's just the FreeBSD issue somewhere.
I've several systems, mostly Linux and Raspberry Pi, all SSH connections between every system work flawlessly except any that include the FreeBSD.
There must be something wrong.
I read about some MTU setup that could be related with this.
 
How can I explain this?
Signal almost full power but losing ping packages.
It's something I really can't explain.
Screenshot_2023-03-10_22-53-32.png


Then after a couple of
# sudo service netif restart
until the ping works just fine but still SSH seems to freeze few seconds after login.
Screenshot_2023-03-10_23-13-36.png

Something weird here, something is causing package drop that gets resolved with some netif restart.
But then after restoring the network web browsing network printing and etc is just fine, but SSH....not at all.
 
Hi all,
found someone with my problem
serverfault.com

Can't connect ssh via wireless interface but t works using eth0

Suddenly I can't connect via ssh to a server using my wireless interface but I can do it using the eth0 interface with a cable connected directly to my router. From my wireless interface I got: $ s...
serverfault.com serverfault.com

So I got the SSH connectivity resolved with this in /etc/ssh/ssh_config

Host *
IPQoS=none

I've no ideia what this does but that's it, problem gone!
it also works with
IPQoS=throughput
 
Yes it can explain it.

Here's what happens: The WiFi software stack is enormously complex. That complexity is needed to get the best throughput and latency out of an inherently difficult environment: radio transmission is difficult, and suffers from interference, echoes, and signal attenuation that depends on time, location, and frequency. The protocol implementation tries to find the best compromise, and that is optimized all the time.

This is partly implemented in firmware of the WiFi adapters involved (on the transmitter and the receiver side), partly in the operating systems of the two sides. Some OSes don't implement all the fine details, or implement them in a fashion that happens to be incompatible with other devices. Where this gets particularly complex is in the special handling for small packets (which are inherently inefficient, but necessary for low-latency traffic), and in measuring and enforcing QoS, to balance between traffic flows that have different requirements (SLOs). It is quite possible that the FreeBSD implementation of the software stack is somewhat incompatible or deficient in corner cases. That doesn't necessarily mean that it is "wrong", it may mean that its idiosyncrasies have not been taken into account in the implementation of other devices, in particular the access points.

I ran into such a problem a few years ago, when trying to use the FreeBSD 802.11 stack as an access point; that mostly worked, except when using Apple as WiFi clients: those caused a resource leak on the FreeBSD side and massive slowdowns.
 
ralphbsz said:
Yes it can explain it.

Here's what happens: The WiFi software stack is enormously complex. That complexity is needed to get the best throughput and latency out of an inherently difficult environment: radio transmission is difficult, and suffers from interference, echoes, and signal attenuation that depends on time, location, and frequency. The protocol implementation tries to find the best compromise, and that is optimized all the time.

This is partly implemented in firmware of the WiFi adapters involved (on the transmitter and the receiver side), partly in the operating systems of the two sides. Some OSes don't implement all the fine details, or implement them in a fashion that happens to be incompatible with other devices. Where this gets particularly complex is in the special handling for small packets (which are inherently inefficient, but necessary for low-latency traffic), and in measuring and enforcing QoS, to balance between traffic flows that have different requirements (SLOs). It is quite possible that the FreeBSD implementation of the software stack is somewhat incompatible or deficient in corner cases. That doesn't necessarily mean that it is "wrong", it may mean that its idiosyncrasies have not been taken into account in the implementation of other devices, in particular the access points.

I ran into such a problem a few years ago, when trying to use the FreeBSD 802.11 stack as an access point; that mostly worked, except when using Apple as WiFi clients: those caused a resource leak on the FreeBSD side and massive slowdowns.
Click to expand...
I can understand everything that was explained except why the same hardware, same drivers, same OS is working right now for hours long without any problem at all.
No ping package dropped, nothing wrong now.
But tomorrow or if I just reboot the system the problem may be back.
This is what I can't understand.
 
Neighbor starts streaming a movie over (their own) WiFi. Or a hairdryer. Or a microwave.

Radio is a shared and dynamic medium; it’s a minor miracle that WiFi works at all, but variable performance is par for the course.

You can try changing the channel you are using on your router, or try changing some of the WiFi options; there are typically a plethora of tweaks, but not much clear direction other than “try it and see if it helps.”
 
You must log in or register to reply here.
Back
Top