On Mon, Mar 05, 2018 at 10:24:41AM +0100, Stoorky Stork wrote: > Not sure if it's specific to Debian or not (openssh's mailing list is > closed to public posting). Someone told me it MAY be system dependent > (see > https://unix.stackexchange.com/questions/427865/scp-l-option-bandwidth-limiting-doesnt-work-when-scp-ing-from-a-remote-ser). > > I think either it's a bug and -l option should also work between two > remote hosts, or the man pages should explicitly specify that it > doesn't work between remote hosts (see this discussion > https://www.linuxquestions.org/questions/showthread.php?p=5827084#post5827084)
Debian doesn't apply any relevant patches here; this isn't going to be Debian-specific. It would be best to file it in the upstream bug tracking system (https://bugzilla.mindrot.org/). It may just be a matter of passing through the relevant option to the remote scp process; something like this (which seems to more or less work in extremely basic testing): diff --git a/scp.c b/scp.c index a533eb09..6edf43a2 100644 --- a/scp.c +++ b/scp.c @@ -685,6 +685,10 @@ toremote(char *targ, int argc, char **argv) addargs(&alist, "--"); addargs(&alist, "%s", host); addargs(&alist, "%s", cmd); + if (limit_kbps) { + addargs(&alist, "-l"); + addargs(&alist, "%lld", limit_kbps / 1024); + } addargs(&alist, "%s", src); addargs(&alist, "%s%s%s:%s", tuser ? tuser : "", tuser ? "@" : "", ... but I'm not an expert in this code and there may be some reason upstream hasn't done that. -- Colin Watson [cjwat...@debian.org]