Gentoo: aes-ctr issue with openssh / armv5tel / hpn

[sakaki]

In case this is of use to anyone out there running Gentoo on their B3, I have recently run into an issue with net-misc/openssh (and friends such as scp, rsync etc.), when performing large transfers using a counter mode AES cipher, and have tentatively traced it to the use of the "hpn" USE flag in openssh.

To elaborate: by default on arm the currently stable openssh ebuild (net-misc/openssh-7.3_p1-r7) has the high performance ssh patchset enabled (hpn USE flag). Unfortunately this appears to cause issues with the counter mode AES ciphers. I've been setting up a B3 as an automated build server, pushing binary packages to a remote (x86_64) host using rsync / ssh, and finding that it would break part way through the process (for long transfers only) when any of the aes{128,192,256}-ctr modes were in use, with the server reporting "Bad packet length <very large number>: disconnecting".

The error suggests something is wrong with the crypto, as it has passed the HMAC filter OK. It did not affect normal use such as terminal access into the remote box.

In the end, I was reliably able to recreate the problem by scp-ing a 2MiB file of random data with AES counter mode forced e.g.:

Code: Select all

b3 ~ # dd if=/dev/urandom bs=1024 count=2048 of=/tmp/bigrandom.dat
b3 ~ # scp -o CIPHERS=aes128-ctr /tmp/bigrandom.dat  www-data@isshoni.org:/var/www/test

No issue with a Gentoo B2 on the same network, same file, same keys, same transfer. Or with the same B3 (using same ssh keypair) running Arch. Or running the old Debian system either, for that matter.

After a process of elimination (kernel etc.) I found that recompiling net-misc/openssh with USE -hpn set fixed things. Need to dig a bit further before putting in a bug report but just a heads up.

As mentioned, this does not appear to affect the same software version running on B2s (but the code in the HPN patchset suffers a number of arch-specific glitches, so this is not surprising).

Also, archlinuxarm does not apply the HPN patchset in their openssh package, which probably explains why that is unaffected too (and nor, I believe, does Debian / arm).

Best, sakaki