SCP Push vs Pull

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Can somebody explain to me what the real difference here is.

scp file.txt user@


scp user@ .

I realize that in the first instance I am moving the file from server
a to
and in the second I am pulling a file from to server a.

The question I really have is this.

From a firewall stand point server a would always be the src and would be the destination.

But what is happening from an application layer that makes these two
commands different.

( I am having an issue where example one fails EVERYTIME unless I use
the -l and slow it down to like 500kb but example two works EVERYTIME
with no -l being used)

I guess I just don't understand what the difference would be...

Yes I know it is in the riverbeds or firewalls or core switchs.....
and I am working with people to analyze that my question is how does
ssh work with these two examples.


Re: SCP Push vs Pull

Quoted text here. Click to load it

Isn't it obvious?  In the first case, a lot of data flows from the
client to the server and very little flows back; in the second case,
very little data flows from the client to the server but a lot flows
back.  Are you on a DSL line?

Dag-Erling Smørgrav -

Re: SCP Push vs Pull

Quoted text here. Click to load it

No, wow,  thanks for pointing that out I would have never guessed
that.... Anyway
for somebody who may stumble on to this odd behavior I have found the
issue and a short term solution

For me at least
This ended up being a firewall issue.  There is a bug in the version
of firewall code that is running on the Juniper firewalls (5.4.0r9)
detailed below.

Problem Record 219624 Window scaling factor not taken into account if
TCP sequence checking is enabled.

Description The NetScreen device detects the window scale specified by
both source and destination hosts in a session and adjusts a window
for an acceptable range of sequence numbers according to their
specified parameters. The NetScreen device then monitors the sequence
numbers in packets sent between these hosts. If the NetScreen device
detects a sequence number outside this range, it drops the packet.

The short term fix for me was to echo 0 > /proc/sys/net/ipv4/
tcp_windows_scaling This will disable my linux box from trying to use
window scaling and this fixed the issue.

Long term solution upgrade the firewall code to get rid of this bug.


Site Timeline