search for: incoming_packet

...======================= RCS file: /home/markus/cvs/ssh/packet.c,v retrieving revision 1.70 diff -u -r1.70 packet.c --- packet.c 27 Sep 2001 11:59:37 -0000 1.70 +++ packet.c 22 Oct 2001 18:36:47 -0000 @@ -96,12 +96,14 @@ /* Buffer for the incoming packet currently being processed. */ static Buffer incoming_packet; +#ifdef WITH_COMPRESSION /* Scratch buffer for packet compression/decompression. */ static Buffer compression_buffer; static int compression_buffer_ready = 0; /* Flag indicating whether packet compression/decompression is enabled. */ static int packet_compression = 0; +#endif /* defaul...

...ion_buffer)) != 0) + goto out; + } sshbuf_reset(state->outgoing_packet); if ((r = sshbuf_put(state->outgoing_packet, "\0\0\0\0\0", 5)) != 0 || @@ -1657,9 +1859,15 @@ ssh_packet_read_poll2(struct ssh *ssh, u_char *typep, u_int32_t *seqnr_p) sshbuf_len(state->incoming_packet))); if (comp && comp->enabled) { sshbuf_reset(state->compression_buffer); - if ((r = uncompress_buffer(ssh, state->incoming_packet, - state->compression_buffer)) != 0) - goto out; + if (comp->enabled == COMP_ZSTD) { + if ((r = uncompress_buffer_zstd(ssh, state...

I added ZSTD support to OpenSSH roughly three years ago and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

I hacked zstd support into OpenSSH a while ago and just started to clean it up in the recent days. The cleanup includes configuration support among other things that I did not have. During testing I noticed the following differences compared to zlib: - highly interactive shell output (as in refreshed at a _very_ high rate) may result in higher bandwidth compared to zlib. Since zstd is quicker

I added ZSTD support to OpenSSH roughly over a year and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

http://bugzilla.mindrot.org/show_bug.cgi?id=1360 Summary: Connection aborted on large data -R transfer Product: Portable OpenSSH Version: 4.7p1 Platform: Other OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org ReportedBy: t8m at

Dear OpenSSH Portable sshd developers, I'm having a problem where sshd login sessions are occasionally (as often as once a day) getting stuck indefinitely. I enabled debug messages and got a backtrace of a stuck sshd, and I think I've found the bug. I wanted to run it by the list once before filing. sshd version: OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004

...2:01 2003 @@ -473,6 +473,18 @@ { buffer_put_int(&outgoing_packet, value); } +#ifdef CHARSET_EBCDIC +void +packet_put_binary(const void *buf, u_int len) +{ + buffer_put_binary(&outgoing_packet, buf, len); +} +void * +packet_get_binary(u_int *length_ptr) +{ + return buffer_get_binary(&incoming_packet, length_ptr); +} +#endif void packet_put_string(const void *buf, u_int len) { @@ -1417,8 +1429,12 @@ return; if (setsockopt(connection_in, IPPROTO_IP, IP_TOS, &tos, sizeof(tos)) < 0) +#if !#system(bs2000) error("setsockopt IP_TOS %d: %.100s:", tos, strerror(...