Temporary Crypto Glitches ... ??
Jochen Bern
Jochen.Bern at binect.de
Thu Nov 18 07:45:10 AEDT 2021
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 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20211117/33947d9c/attachment-0001.p7s>
More information about the openssh-unix-dev
mailing list