Occasional SSH client disconnects

madelaney · December 14, 2021, 8:20pm

All,

I recently setup a wrt3200acm with OpenWrt 21.02.1 r16325-88151b8303 . When I'm connected via a SSH terminal to another machine on the network, both wireless (5Ghz), I'll get an occasional ssh disconnect (even happens while I'm tying in wither screen or tmux; both tested to see if either helped) with the error message: client_loop: send disconnect: Broken pipe.

If I try to reconnect, shortly after the disconnect, I get the same message.

When I try to connect with verbose logging, I see the following:

OpenSSH_8.6p1, LibreSSL 2.8.3
debug1: Reading configuration data /Users/stduser/.ssh/config
debug1: /Users/stduser/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug2: resolve_canonicalize: hostname 172.20.1.111 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/Users/stduser/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/Users/stduser/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: ssh_connect_direct: entering
debug1: Connecting to 172.20.1.111 [172.20.1.111] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x08
debug1: Connection established.
debug1: identity file /Users/stduser/.ssh/id_rsa type 0
debug1: identity file /Users/stduser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/stduser/.ssh/id_dsa type -1
debug1: identity file /Users/stduser/.ssh/id_dsa-cert type -1
debug1: identity file /Users/stduser/.ssh/id_ecdsa type 2
debug1: identity file /Users/stduser/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/stduser/.ssh/id_ecdsa_sk type -1
debug1: identity file /Users/stduser/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /Users/stduser/.ssh/id_ed25519 type 3
debug1: identity file /Users/stduser/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/stduser/.ssh/id_ed25519_sk type -1
debug1: identity file /Users/stduser/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /Users/stduser/.ssh/id_xmss type -1
debug1: identity file /Users/stduser/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.6
debug1: compat_banner: match: OpenSSH_8.6 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 172.20.1.111:22 as 'stduser'
debug3: record_hostkey: found key type ED25519 in file /Users/stduser/.ssh/known_hosts:53
debug3: load_hostkeys_file: loaded 1 keys from 172.20.1.111
debug1: load_hostkeys: fopen /Users/stduser/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug3: order_hostkeyalgs: have matching best-preference key type ssh-ed25519-cert-v01@openssh.com, using HostkeyAlgorithms verbatim
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c
debug2: host key algorithms: ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
debug2: ciphers stoc: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
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
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:Z9oqGRlH5vpg4Sj1hZPDzDO4Ccb78Ckf3j51e2KC/6o
debug3: record_hostkey: found key type ED25519 in file /Users/stduser/.ssh/known_hosts:53
debug3: load_hostkeys_file: loaded 1 keys from 172.20.1.111
debug1: load_hostkeys: fopen /Users/stduser/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host '172.20.1.111' is known and matches the ED25519 host key.
debug1: Found key in /Users/stduser/.ssh/known_hosts:53
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /Users/stduser/.ssh/id_rsa RSA SHA256:zpLWJIjAi3eJ6STQDJWuEuJIbnETkUznnCX55txXS3A
debug1: Will attempt key: /Users/stduser/.ssh/id_dsa
debug1: Will attempt key: /Users/stduser/.ssh/id_ecdsa ECDSA SHA256:BLXORCMtsZSHyKvcQRCgfPJd+f5XLGWby+eamvJDeD4
debug1: Will attempt key: /Users/stduser/.ssh/id_ecdsa_sk
debug1: Will attempt key: /Users/stduser/.ssh/id_ed25519 ED25519 SHA256:muW5Q2sgpczK6UA/U1S3k+nghs7VO5b4i1ehRPj7pOk
debug1: Will attempt key: /Users/stduser/.ssh/id_ed25519_sk
debug1: Will attempt key: /Users/stduser/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/stduser/.ssh/id_rsa RSA SHA256:zpLWJIjAi3eJ6STQDJWuEuJIbnETkUznnCX55txXS3A
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /Users/stduser/.ssh/id_dsa
debug3: no such identity: /Users/stduser/.ssh/id_dsa: No such file or directory
debug1: Offering public key: /Users/stduser/.ssh/id_ecdsa ECDSA SHA256:BLXORCMtsZSHyKvcQRCgfPJd+f5XLGWby+eamvJDeD4
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: /Users/stduser/.ssh/id_ecdsa_sk
debug3: no such identity: /Users/stduser/.ssh/id_ecdsa_sk: No such file or directory
debug1: Offering public key: /Users/stduser/.ssh/id_ed25519 ED25519 SHA256:muW5Q2sgpczK6UA/U1S3k+nghs7VO5b4i1ehRPj7pOk
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: /Users/stduser/.ssh/id_ed25519 ED25519 SHA256:muW5Q2sgpczK6UA/U1S3k+nghs7VO5b4i1ehRPj7pOk
debug3: sign_and_send_pubkey: ED25519 SHA256:muW5Q2sgpczK6UA/U1S3k+nghs7VO5b4i1ehRPj7pOk
debug3: sign_and_send_pubkey: signing using ssh-ed25519 SHA256:muW5Q2sgpczK6UA/U1S3k+nghs7VO5b4i1ehRPj7pOk
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to 172.20.1.111 ([172.20.1.111]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: filesystem full
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: client_input_hostkeys: received RSA key SHA256:afks5SBb4uOec9t93HJq/eKq0zp/W9PhGUiCGUeFQIE
debug3: client_input_hostkeys: received ECDSA key SHA256:zalMVjkkUr4xesN3TGpOFM73lYYFL9+qrMPJmxErfBk
debug3: client_input_hostkeys: received ED25519 key SHA256:Z9oqGRlH5vpg4Sj1hZPDzDO4Ccb78Ckf3j51e2KC/6o
debug1: client_input_hostkeys: searching /Users/stduser/.ssh/known_hosts for 172.20.1.111 / (none)
debug3: hostkeys_foreach: reading file "/Users/stduser/.ssh/known_hosts"
debug3: hostkeys_find: found ecdsa-sha2-nistp256 key under different name/addr at /Users/stduser/.ssh/known_hosts:25
debug3: hostkeys_find: found ecdsa-sha2-nistp256 key under different name/addr at /Users/stduser/.ssh/known_hosts:30
debug3: hostkeys_find: found ssh-ed25519 key under different name/addr at /Users/stduser/.ssh/known_hosts:51
debug3: hostkeys_find: found ssh-ed25519 key under different name/addr at /Users/stduser/.ssh/known_hosts:52
debug3: hostkeys_find: found ssh-ed25519 key at /Users/stduser/.ssh/known_hosts:53
debug1: client_input_hostkeys: searching /Users/stduser/.ssh/known_hosts2 for 172.20.1.111 / (none)
debug1: client_input_hostkeys: hostkeys file /Users/stduser/.ssh/known_hosts2 does not exist
debug3: client_input_hostkeys: 3 server keys: 2 new, 18446744073709551615 retained, 2 incomplete match. 0 to remove
debug1: client_input_hostkeys: host key found matching a different name/address, skipping UserKnownHostsFile update
debug3: receive packet: type 4
debug1: Remote: /home/stduser/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /home/stduser/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: set_sock_tos: set socket 3 IP_TOS 0x08
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug1: channel 0: setting env LC_TERMINAL_VERSION = "3.4.14"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: channel 0: setting env LANG = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: channel 0: setting env LC_TERMINAL = "iTerm2"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug1: channel 0: setting env LC_ALL = "en_US.UTF-8"
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: send packet: type 1
client_loop: send disconnect: Broken pipe
Exit 255

If I wait for a while, say about thirty minutes, it works again but this will inevitably happen again. Maybe it will happen in three hours, maybe tomorrow but it will happen. I've seen a few posts about turning off "Software flow offloading" which I do not have enabled.

Here are some more data points:

Even when I cannot SSH to 172.20.1.111, I can SSH into the gateway (172.20.1.1).
I can connect to the same host (in this case 172.20.1.111) via HTTP/HTTPS, it's only SSH that seems to have an issue.
I can also ping the host 172.20.1.111 with zero packet loss.

Any help would be awesome.

Thanks in advance.

Mike D.

madelaney · December 14, 2021, 8:30pm

Here are some of my config files:

file - etc/network/config

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fded:e4f3:cc40::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '172.20.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config device
	option name 'wan'
	option macaddr 'c6:41:1e:37:13:c0'

config interface 'wan'
	option device 'wan'
	option proto 'static'
	option ipaddr '10.9.1.25'
	option netmask '255.255.255.0'
	option gateway '10.9.1.1'
	list dns '9.9.9.9'
	list dns '1.1.1.1'
	list dns '149.112.112.112'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'

file - etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '36'
	option hwmode '11a'
	option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
	option htmode 'VHT80'
	option country 'US'
	option cell_density '0'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option macaddr 'c4:41:1e:37:13:c2'
	option encryption 'psk2'
	option key 'password12345'
	option ssid 'MAGRATHEA'

config wifi-device 'radio1'
	option type 'mac80211'
	option channel '11'
	option hwmode '11g'
	option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
	option htmode 'HT20'
	option country 'US'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option macaddr 'c4:41:1e:37:13:c1'
	option encryption 'psk2'
	option key 'password12345'
	option ssid 'MAGRATHEA'

config wifi-device 'radio2'
	option type 'mac80211'
	option channel '34'
	option hwmode '11a'
	option path 'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'
	option htmode 'VHT80'
	option disabled '1'

config wifi-iface 'default_radio2'
	option device 'radio2'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'

psherman · December 14, 2021, 8:31pm

Do you have multiple APs?

madelaney · December 14, 2021, 8:36pm

Yes, I have two AP's. However, in this scenario there is only one AP (in theory) that is part of the equation; both machines are connected to the same AP.

Both AP's are on the same WAN (connected to the same switch) but with different CIDR blocks (within the 172.16.0.0/12 network).

psherman · December 14, 2021, 8:47pm

Chances are that your client is switching over to another WiFi network, causing it to be on another network. When it returns to the wifi on this device, the network address changes back to the one in question, it then reports the broken pipe.

Next time the problem manifests, immediately look at your computers IP address. .

madelaney · December 14, 2021, 9:09pm

Thanks for the idea @psherman.

I looked at my IP address of my wireless adapter when I lost connection and I was still on the same AP so it doesn't appear that I jumped AP's.

psherman · December 14, 2021, 9:44pm

try running some concurrent persistent pings to see what is happening:

to the router in question
to the other router that is on a parallel network in the 172.16.0.0/12 block
to the upstream router (10.9.1.1)
and even to something on the internet like 8.8.8.8

Look for patterns in the pings if there are dropouts.

It should go without saying that all of your SSIDs should be unique if they are associated with different networks. It would be a good idea to ensure that the wireless client in question cannot associate with any other SSIDs that may be in proximity (do one or more of the following: "forget" the network from the OS's wifi priority list, remove the password, disable the auto-connect option). This way you can ensure your device will absolutely stay on the desired network.

madelaney · December 15, 2021, 7:45pm

The two AP's do have their own unique SSIDs, sorry about not being clear on that before.

On the machine that I'm testing on, I did remove the old SSID so only the SSID associated with the wrt3200acm (the router that is giving me issues) is configured/enabled.

When I do a ping test, to the router (10.9.1.1) and to a public DNS server (8.8.8.8), I didn't encounter any dropped packets even when my SSH connection dropped and I received client_loop: send disconnect: Broken pipe from my SSH client.

psherman · December 15, 2021, 8:15pm

What about the other system? Does it stay consistently connected to the same network? does it experience any dropouts or other network issues?

madelaney · December 15, 2021, 9:04pm

All other systems seem like they stay connected (based off DHCP lease times).

I did notice that once I receive the error message client_loop: send disconnect: Broken pipe from any host (in this case 172.22.1.111), other hosts also stop responding to SSH connections.

I feel like the router is blocking the connections for some reason.

psherman · December 15, 2021, 9:18pm

Is this true of both wired and wireless hosts, or just wireless?

Not likely, unless there is an issue with the wifi bridge itself. When the hosts are on the same network, the router and firewall engines are not involved in the connections between those hosts. The only way that the router (as a device, not a routing engine) is responsible for any issues connecting between two hosts on the same network is if there is a problem with the wifi stack, and this would be more of a global connectivity issue than specific to certain ports. The wired network (when not moving between two or more distinct network) is entirely switched (L2). Wireless is nominally also an L2 bridge, but from time to time there can be bugs that affect the wifi bridge.

madelaney · December 16, 2021, 6:46pm

I setup a raspberry pi (wired) to the wrt3200acm. I wanted until I get booted from the 172.20.1.111 host, once I got disconnected I tried to ssh into the raspberry pi and I was able to open an ssh connection to the raspberry pi.

One thing I did test, not sure if it's helpful but it's curious. When I get disconnected from a host (lets say 172.20.1.111), just after the disconnect (within ~15 seconds), I can open a telnet connection to port 22 and I get a response.

telnet 172.20.1.111 22
Trying 172.20.1.111...
Connected to kesteven.lan.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.6

This may be a red herring due to a lack of an handshake or other negotiation but I figured I'd mention it.

psherman · December 16, 2021, 6:49pm

My instinct is that there is an issue with the host at 172.20.1.111 and not the router/wifi. But I don't know what is causing the issue.

madelaney · December 16, 2021, 7:32pm

I was thinking that too. I hate that machine (it's from work).

Just to add more weight to that theory, I launched an external machine in Google Cloud. The purpose of that external machine was to test if after losing connectivity to 172.20.1.111 via SSH, if I could still SSH into another machine.

Shortly after getting disconnected from 172.20.1.111, I was able to SSH into the external (Google Cloud) machine. Yet, I was not able to SSH into 172.20.1.111.

I then went to Raspberry Pi, that I setup for a previous test, and tried to SSH into 172.20.1.111. Using the Raspberry Pi, I was able to SSH into 172.20.1.111.

I'm confused.

anon50098793 · December 16, 2021, 8:27pm

i'm not... that's enough info to pinpoint the work machine...( check for norton or whatever is causing your drama )... definitely not related to openwrt....

madelaney · December 16, 2021, 8:35pm

I just ran a test that after getting disconnected. If I restart br-lan after getting dropped, I'm immediately able to connect via SSH to the host 172.20.1.111. If I do not restart br-lan, it may take a few minutes (I have not timed this for accuracy) for me to be able to SSH into the 172.20.1.111 host.

anon50098793 · December 16, 2021, 8:38pm

ok... back to square one

psherman · December 16, 2021, 9:16pm

I'm not so certain that the OpenWrt / br-lan is really the culprit here. I think it is more likely that you are hitting it with a stick, forcing the network stack on the misbehaving host to restart.

Remind me -- is the host (.111) wired or wireless?

madelaney · December 17, 2021, 12:56pm

At the moment 111 is a wireless host (Latitude 7420 running Fedora 34). I've requested a dock from work to see if going wired helps.

madelaney · December 17, 2021, 2:42pm

Based on the some ideas from @psherman / @anon50098793 I was able to do more testing yesterday, it gets complicated so lets set the landscape but I think it adds some clarity (or I hope).

machineA - Mac Pro (macOS Monterey; 12.1); Wireless
machineB - Latitude 7420 (Fedora34); Wireless
machineC - Raspberry PI (running Raspbian); Wired
machineD - Ubuntu 20.04 (running in Google Cloud)

While working (which is me on machineA connected to machineB) via SSH, I'll get disconnected from SSH from time to time.

When this disconnect happens, any machines on the local network that I'm connected to via SSH drop regardless of wired or wireless connection and I am unable to reconnect to said machine for an unknown about of time. After the disconnection, if I try to SSH into another machine, on the local network, that I had not been connected to when the drops occurred, said machine is accessible via SSH.

For example. If I'm connected to machineB (local wireless), and machineD, from machineA and I get booted from machineB. I'm not able to reconnect to machineB for some time, however my connection to machineD is alive and well. If I try to open a new connection to machineC, it's working just fine.

Another example. If I'm connected to machineB, machineC, and machineD from machineA. My SSH connection will drop from only machineB (local wireless), and machineC (local wired) but not from machineD (external gcp).

My apologies this is just a mess, I'm lacking the experience to know how to articulate this behavior in a clear and concise manor.