Re: adjust strategy



On márc. 28, 12:49, Simon Tatham <ana...@xxxxxxxxx> wrote:
<attila.r.n...@xxxxxxxxx> wrote:
[...]
Consequently the Erlang server also sent a couple of small adjust
messages which somehow confused the Maverick client to send only
small messages and the whole upload didn't work.

By 'didn't work', do you mean that something actually _failed_, or
just that the correct data was exchanged but only in extremely small
fragments leading to a very slow connection?

The server started to use 100% CPU and eventually the data transfer
stopped. I'm not sure that this was due to some timeout in an
application level above the SFTP layer - usually I stopped the
testcase, because the slowness is also unacceptable in this case.

If the former, it sounds as if the client is actually broken, in the
sense that it is receiving a packet stream consistent with the spec
and not coping with it. Rather than trying to modify the server to
avoid triggering the client bug, you should find the client bug and
fix that.

I only have access to the server source, that's why I tried to change
things there :-)

I've changed the implementation in the Erlang server to only send an
adjust message if all fragments are received. This seems to work, but
I'm not sure if this is correct according to the specifications - is
it correct?

No. If the client wants to send an SFTP packet which is greater than
the SSH channel's window size, it MUST send no more than the first
windowful of data and then wait to receive a WINDOW_ADJUST before
sending any more. Therefore, you MUST be willing to send a
WINDOW_ADJUST in the middle of receiving an SFTP packet, if the
packet is large enough.

If you absolutely must solve this problem by fiddling with the
server's window adjust strategy rather than fixing the client to
cope with anything legal it receives, a simple option would be to
send WINDOW_ADJUST only once your window drops to half its original
size, which would mean you'd still send them in the middle of large
packets but wouldn't send too many very small ones.

So the current solution breaks the protocol. I'll look at this
solution, because I'd prefer not to break compatibility with other
clients.

I am surprised to hear that any implementation - client _or_ server
- has this much cross-talk between its ssh-connection layer and its
SFTP layer.
[...]

I'm working with an older version of the Erlang SSH server. The newer
one seems to be better separate the SSH and SFTP layers. Unfortunately
that doesn't work either (the upload stops after a while), but that's
another debugging session :-)
.



Relevant Pages

  • Re: TCP packets : end of thre-way handshake and start of data-transmission - how to dete
    ... Its not the client actually sending data before it should I'm concerned ... client behaves as if I did not send that packet at all (mind you, ... RFC 793 Section 3.4 (Establishing a connection) says in part: ... packet because it would be necessary to assume a window size. ...
    (comp.arch.embedded)
  • Re: TCP packets : end of thre-way handshake and start of data-transmission - how to dete
    ... Its not the client actually sending data before it should I'm concerned ... When I send some data after receiving the first ACK the ... client behaves as if I did not send that packet at all (mind you, ... because that ACK said the window size was zero. ...
    (comp.arch.embedded)
  • Re: UDP timers
    ... In one application (network multimedia tank), ... the event that a packet is dropped or lost in the ether. ... waiting *seconds* for an acknowledgement would necessitate a very ... The client doesn't need the ...
    (comp.arch.embedded)
  • [REVS] Backdoor Spotcom Analysis
    ... Spotcom is a backdoor client application that allows a hacker to control ... The server IP address is hard-coded in ... msrsvp.exe accepts a couple of command line arguments. ... the packet payload. ...
    (Securiteam)
  • Re: Socket weirdness
    ... client) before you will notice a shutdown receive at server. ... Then eventually a packet comes from the peer, and that will contain data, so the server responds RST: ... way back across the network. ...
    (microsoft.public.dotnet.framework)