On 17.11.21 18:48, Philipp Marek wrote:
Yeah, that smells like MTU.
Ayup, at least *this* instance turned out to have had a pMTU discovery issue as its root cause (*#%!! legacy firewall).
Not sure that the two previous instances of the problem had the same cause, though, as they fixed themselves before I could nail down the details. Neither went over that same FW and one did not go across *any* connections where I'd expect MTUs to change without *our* physical intervention ...
When you have the blocking case, run "ss -i" to see the PMTU; and/or run "tracepath -p 22 <host>" to diagnose.
Not sure that those two actually showed any telltale signs, but I admit I'm not used to them ... :
tcp ESTAB 0 0 $CLIENT:44006 $SERVER:ssh
cubic wscale:9,7 rto:226 rtt:25.756/18.351 ato:40 mss:1448
rcvmss:1386 advmss:1448 cwnd:10 bytes_acked:16274 > bytes_received:17929 segs_out:365 segs_in:336 send 4.5Mbps
lastsnd:21559 lastrcv:21548 lastack:21509 pacing_rate 9.0Mbps
rcv_rtt:140 rcv_space:29200
# tracepath -p 22 $SERVER -n 1?: [LOCALHOST] pmtu 15001: $B0RKEN_FW 0.760ms 1: $B0RKEN_FW 0.505ms 2: $NEW_EDGE_FW 2.523ms 3: $NEW_EDGE_FW 2.617ms reachedResume: pmtu 1500 hops 3 back 2
However, good ole fat ping
# ping -M do -s $SIZE $SERVER
showed pongs up to SIZE=1410, "too long"s from SIZE=1473 upward, and no replies in between (because the NEED TO FRAGMENTs came from transfer net IPs and $B0RKEN_FW doesn't do proper ESTABLISHED,RELATED).
Thanks again, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
