I've been able to reproduce this multiple times so I think I can say that something is wrong, both with a real box and with a VM. Setup: yamato -> headless box with sshd 5.8 running (doesn't matter whether this one is hpn or not) client -> box with ssh client 5.8 with hpn Connection between the two boxes: local gigabit or virtio/tun over yamato's br0. client's .ssh/config <<EOF ControlPath ~/.ssh/master-%r@%h:%p Compression yes Host yamato ControlMaster auto ControlPersist yes ForwardAgent yes EOF Open two ssh sessions from client→yamato; in the first run a long command, like emerge --sync, dmesg, or "dd if=/dev/zero count=10M | hexdump -v", try to use the second. After no even a minute, both sessions are completely frozen client-side.
FWIW a "slow" amount of data doesn't cut it: while true; do sleep 2; date; done is running for over three minutes now.
try the workaround in the older ebuilds: # The AES-CTR multithreaded variant is temporarily broken, and # causes random hangs when combined with the -f switch of ssh. # To avoid this, we change the internal table to use the non-multithread # version for the meantime. sed -i \ -e '/aes...-ctr.*SSH_CIPHER_SSH2/s,evp_aes_ctr_mt,evp_aes_128_ctr,' \ cipher.c || die if that doesnt help, report the issue to the hpn peeps hpn-ssh@psc.edu ... not like any of us have done development on the hpn code base ...
Actually, I have done dev on the HPN codebase, that's why I support it. Why was the AES-CTR sed removed? It is STILL needed. I'm going to restore it and revbump.
5.8_p1-r1 bump in the tree with it. Also in 5.7_p1-r1 and 5.8_p1.
you need to put real details into the comment (upstream URLs, what is broken, how to test it is fixed, etc...). using "temporarily broken" when the comment dates back literally years isnt going to fly, and neither is "Do NOT remove this in new versions". the simple test you alluded to in there passes fine for me.
Directly from the upstream page: Additionally, the MT-AES-CTR mode cipher replaces the default ST-AES-CTR mode cipher. Be aware that if the client process is forked using the -f command line option the process will hang as the parent thread gets 'divorced' from the key generation threads. This issue will be resolved as soon as possible. That paragraph has been in place for nearly 2 years now at upstream. I can still reproduce it with -f trivially. Here's your testcase: SOMEHOST=... # working ciphers for cipher in 3des-cbc aes{128,192,256}-cbc arcfour{,128,256} blowfish-cbc cast128-cbc ; do echo === $cipher ; ssh -c $cipher -f $SOMEHOST 'dd if=/dev/zero bs=1M count=1' | dd of=/tmp/ssh-ciphertest-$cipher bs=1M done ; # broken AES-CTR-MT for cipher in aes{128,192,252}-ctr ; do echo === $cipher ; ssh -c $cipher -f $SOMEHOST 'dd if=/dev/zero bs=1M count=1' | dd of=/tmp/ssh-ciphertest-$cipher bs=1M done ;
that is really only useful if the comment linked to your new information. and i see now you've done just that.
