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).
Ack.
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.
Well, perhaps some routing changed.
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
Grrr, the "mtu" field was cut out on your end because of the long lines.
# tracepath -p 22 $SERVER -n
1?: [LOCALHOST] pmtu 1500
1: $B0RKEN_FW 0.760ms 1:
$B0RKEN_FW 0.505ms 2:
$NEW_EDGE_FW 2.523ms 3:
$NEW_EDGE_FW 2.617ms reached
Resume: pmtu 1500 hops 3 back 2
Ok, so no ICMPs are returned...
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).
Well, there you are.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
