Thank you for pursuing this to deeper depths. Could you please add further context for your test, for example what operation is running, in what direction, how far it got (if you can tell), where the capture was taken, where the duplicate ACKs are sent from, whether they are at TCP start etc.? Meanwhile, I’ll take an educated guess.
There are many Internet resources around for debugging network issues, and context helps to know which ones apply. I’ll somewhat randomly provide one on TCP startup, and another on duplicate ACKs generally.
Is this network issue during the mysterious 5 minute delay before the server notices, during the verification that fails, or somewhere else? From some guessing, the stack doesn’t talk about a connection problem (but I’m not positive it would) so possibly you just got a super-slow transfer. Since you’re looking at profiling (you can also watch live in About -> Show log -> Live), you probably have file names, sizes, timings, and speeds.
The implication from seeing Duplicati doing a dblock Get is that you’re back to chasing verification problem after successful backup to friend’s house, and are maybe having trouble (generally, or just on this dblock?) getting it over because friend’s house sends some data, your house acknowledges, then that ACK gets lost. Friend’s house tries to recover by sending again at the same point in the TCP sequence. Repeat until dead.
The problem is that data and acknowledgments flow both ways (though the actual data amount will be higher in the direction the dblock is going), and one can have this sort of retry going on either way. Need context…