rsync - Feb 2019 - linux rsync <-> SSHDroid has started becoming unreliable after an upgrade of Fedora 28 to 29

People,

For some years I have been using rsync quite happily to send / retrieve 
files to / from SSHDroid Pro but recently I have started having a 
problem when transferring large numbers of file - I am pretty sure it 
started after upgrading from Fedora x86_64 28 to 29 - but I am not 100% 
sure.  Below is the tail end of the output of:

   rsync -avvv root at 192.168.1.100:/storage . > err.txt 2>&2

.
.
sending file_sum
got file_sum
set modtime of 
storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/.19.60878.1538877264113.v3.exo.lj1voL
to (1538877264) Sun Oct  7 12:54:24 2018
renaming 
storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/.19.60878.1538877264113.v3.exo.lj1voL
to 
storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/19.60878.1538877264113.v3.exo
false_alarms=0 hash_hits=0 matches=0
sender finished 
//storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/19.60878.1538877264113.v3.exo
send_files(2996, 
//storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/19.818.1538877263732.v3.exo)
send_files mapped 
//storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/19.818.1538877263732.v3.exo
of size 60060
recv_files(storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/19.818.1538877263732.v3.exo)
storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/19.818.1538877263732.v3.exo
calling match_sums 
//storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/19.818.1538877263732.v3.exo
sending file_sum
got file_sum
set modtime of 
storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/.19.818.1538877263732.v3.exo.825nBl
to (1538877263) Sun Oct  7 12:54:23 2018
renaming 
storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/.19.818.1538877263732.v3.exo.825nBl
to 
storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/19.818.1538877263732.v3.exo
false_alarms=0 hash_hits=0 matches=0
sender finished 
//storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/19.818.1538877263732.v3.exo
send_files(2997, 
//storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/2.3339089.1529636238000.v3.exo)
send_files mapped 
//storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/2.3339089.1529636238000.v3.exo
of size 1655452
recv_files(storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/2.3339089.1529636238000.v3.exo)
storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/2.3339089.1529636238000.v3.exo
calling match_sums 
//storage/emulated/0/Android/data/com.google.android.youtube/cache/exo/2.3339089.1529636238000.v3.exo
Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to 192.168.1.100 port 22: message 
authentication code incorrect
rsync: connection unexpectedly closed (18049139 bytes received so far) 
[receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) 
[receiver=3.1.3]
[receiver] _exit_cleanup(code=12, file=io.c, line=226): about to call 
exit(12)
rsync: connection unexpectedly closed (146209 bytes received so far) 
[generator]
rsync error: unexplained error (code 255) at io.c(226) [generator=3.1.3]
[generator] _exit_cleanup(code=12, file=io.c, line=226): about to call 
exit(255)

Suggestions about how to further debug this problem would be greatly 
appreciated!

Regards,

Phil.
-- 
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  phil at pricom.com.au

On Sun 03 Feb 2019, Philip Rhoades via rsync wrote:
> 
> For some years I have been using rsync quite happily to send / retrieve
> files to / from SSHDroid Pro but recently I have started having a problem
> when transferring large numbers of file - I am pretty sure it started after
> upgrading from Fedora x86_64 28 to 29 - but I am not 100% sure.  Below is
[...]
> Corrupted MAC on input.
> ssh_dispatch_run_fatal: Connection to 192.168.1.100 port 22: message
> authentication code incorrect
ssh's communication gets disrupted somehow, and stops the connection,
thus causing rsync to fail.

This is a problem with ssh, not with rsync. Try enabling ssh debug
options, and try using different ssh ciphers.


Paul

Paul,


On 2019-02-03 03:00, Paul Slootman via rsync wrote:
> On Sun 03 Feb 2019, Philip Rhoades via rsync wrote:
>> 
>> For some years I have been using rsync quite happily to send / 
>> retrieve
>> files to / from SSHDroid Pro but recently I have started having a 
>> problem
>> when transferring large numbers of file - I am pretty sure it started 
>> after
>> upgrading from Fedora x86_64 28 to 29 - but I am not 100% sure.  Below 
>> is
> 
> [...]
> 
>> Corrupted MAC on input.
>> ssh_dispatch_run_fatal: Connection to 192.168.1.100 port 22: message
>> authentication code incorrect
> 
> ssh's communication gets disrupted somehow, and stops the connection,
> thus causing rsync to fail.
> 
> This is a problem with ssh, not with rsync. Try enabling ssh debug
> options, and try using different ssh ciphers.

I tried putting all the Ciphers one-by-one in:

   ~/.ssh/config

but with no improvement.  I will try ssh debugging . .

I have also sent a note to the developer of SSHDroid to see if (s)he 
responds but the last update to that app was in 2015 and ssh doesn't 
change very much so it is hard to see why that should suddenly be 
playing up - I will also try and use the ssh from Fedora 27/8 to see if 
that makes a difference.

Thanks,

Phil.
-- 
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  phil at pricom.com.au