Random: include the Crypt_* classes if they're available
* bantu/a-random-change:
phpseclib_is_includable() -> phpseclib_resolve_include_path()
Drop Net_SSH2::_is_includable() method.
Random: a few changes to the stream_resolve_include_path_function
Replace stream_resolve_include_path with phpseclib_is_includable.
Random: add explanatory comment
SSH2: replace _is_includable() with stream_resolve_include_path
Random: include the Crypt_* classes if they're available
none of the other statically defined variables have the potential
to change as multiple Net_SSH2 objects are created but this one does.
ie. if you connect to one SSH-2.0-SSHD server then no subsequent server
will use hmac-sha1-96 even if it could
Also, in Net_SSH2::_connect() $host is used in multiple places. Rather than changing all references to {$this->host}:{$this->port} preserve existing $host reference and update it accordingly
this change will make it so some parameters can be set after the
Net_SSH2 object has been created. eg. instead of doing
define('NET_SSH2_LOGGING', NET_SSH2_LOG_COMPLEX) one can now do
$ssh->setLogging(...) or something.
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
