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]

Reply via email to