In logs that were provided to me phpseclib sent a packet that was 2536 bytes long (excluding the bytes denoting the channel and data length) but the length packet said it was 32764 bytes long (ie. $max_size).
So when $max_size is less than the data being sent and has to be adjusted by a new window adjust message from the server and the adjustment makes $max_Size bigger than the data being sent over problems arise.
SSH's window size has caused issues before. Overall I don't think the SSH specs really explain the window size very well. I opened up an errata on SSH's RFC a while back about the issue.
- PHP4 doesn't allow method chaining
- $_SESSION isn't always defined
- on PHP5.1 and earlier using 0x100000000 instead of 4294967296 gives E_NOTICE
- array('Net_SSH2', 'func_name') doesn't work so we fix this by passing $this to it.
to make that work on PHP4 pass by call-time reference. normally this would result
in a fatal error on PHP5.4+ but doesn't seem to in this case. the following URL
elaborates:
http://stackoverflow.com/q/20732563/569976
sending the close channel packet right after the eof seems to make some scp transfers terminate prematurely.
unfortunately, sometimes this behavior is undesirable as it is in this case:
http://www.frostjedi.com/phpbb3/viewtopic.php?f=46&t=29457
hence the $want_reply parameter
also, this commit makes the scp packet length account for the length portion
Removed unused piece of code @2352.
Added $this->_get_interactive_channel() to reset(). Unless we don't want to close the subsystem channel?? Leaving that decision up to you.
- keep track of server -> client window size and look out for NET_SSH2_MSG_CHANNEL_WINDOW_ADJUST packets as appropriate
- send client -> server window size packets based on channel of received packet - not of desired channel
- buffer incoming packets based on received packets channel - not on desired channel
