similar to: Yet another question on window computations

As before, it is described on our website. This should apply fairly cleanly to both portable and openbsd ssh. http://www.psc.edu/networking/hpn-ssh/ Only in openssh-3.8.1p1-dynwindow: Makefile diff -u openssh-3.8.1p1/buffer.c openssh-3.8.1p1-dynwindow/buffer.c --- openssh-3.8.1p1/buffer.c 2003-11-21 07:56:47.000000000 -0500 +++ openssh-3.8.1p1-dynwindow/buffer.c 2004-07-12 07:49:29.000000000

We have developed a patch that enables changing the SSH window size using the tcp window size as the source. This allows SSH to obtain maximum use of the bandwidth on high BDP links. We also have a page that describes the changes and performance. http://www.psc.edu/~rapier/hpn-ssh/ The patch against CVS is included here. Common subdirectories: src/usr.bin/ssh/CVS and ssh/CVS diff -u

I am utilizing an openssh tunnel between two Linux boxes. On the client box I issue the following commands to set up the tunnel; - ssh -w0:0 root at x.x.x.x -v where x.x.x.x is the IP address of the Linux system running sshd - ip addr add 10.0.5.1/32 peer 10.0.5.2 dev tun0 - ip link set tun0 up On the box running sshd I issue the following commands: - ip addr add 10.0.5.2/32 peer 10.0.5.1 dev

I am trying to make sense of the way in which OpenSSH computes window size, so far without much success :-( My understanding is that when a client specifies a window size N at the beginning of a session, it is letting the server know that it (the server) can send, on a given channel, up to N bytes worth of data that consumes window space (essentially the payload of SSH_MSG_CHANNEL_DATA and one

http://bugzilla.mindrot.org/show_bug.cgi?id=773 Summary: OpenSSH hangs or silently exits on write failure on stdout/stderr Product: Portable OpenSSH Version: -current Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: openssh-bugs

http://bugzilla.mindrot.org/show_bug.cgi?id=790 Summary: Connection stall when client output fails and server has a lot more to send Product: Portable OpenSSH Version: 3.7.1p1 Platform: All OS/Version: FreeBSD Status: NEW Severity: normal Priority: P3 Component: ssh AssignedTo:

Hi all, I'm very new in this list, as looking for codes to plug up the lack of functionality of "Protocol 2 Remote Forwardig". Fortunately, I could find it in MARC's archive. Mr. Jarno Huuskonen posted the codes in Sept, last year, and I tried applying it to my FreeBSD box environment. I couldn't apply an original patch, of course, for incompatibility of virsion. The

Hello I have ported OpenSSH 3.8p1 to a LynxOS platform. Recently I heard a report from the field that v2 is perceived to be significantly slower than v1. Is this a known issue? Are there any configuration parameters that can be modified to make v2 faster? Thanks in advance for your response Amba

https://bugzilla.mindrot.org/show_bug.cgi?id=2529 Bug ID: 2529 Summary: direct-streamlocal channel open doesn't match PROTOCOL documentation Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: ssh

Hi ! Here's a patch to add remote port forwarding support (protocol 2) for openssh. I have tried to test that it works like it should but a more thorough testing is needed. This patch adds both client/server support. The patch should be applied to openssh-2.1.1p4 source tree. Also included is a PortForwarding sshd_config option, new ./configure option --disable-forwarding that should make it

Hi all I have a glusterfs cluster underpinning a KVM virtual server in a two host setup. Today the cluster just froze and stopped working. I have rebooted both nodes, brought up the storage again. I can see all the vm files there but when I try to start the vm the machine just hangs. How can I see if gluster is trying to synchronise files between the two servers? thanks Shaun -------------- next

FYI: I needed to update local_consumed when I pulled data out for display... Steve -----Original Message----- From: openssh-unix-dev-bounces+stevec=futuresoft.com at mindrot.org [mailto:openssh-unix-dev-bounces+stevec=futuresoft.com at mindrot.org]On Behalf Of Cooper, Steve Sent: Friday, April 20, 2007 3:40 PM To: openssh-unix-dev at mindrot.org Subject: Cannot receive more that ~64k from

The command "ssh ls -l /doesnotexist" gives various responses: Running from a 200 MHz PentiumPro with dsa key added to ssh-agent: Mistakes worst to fast machine: To a faster 600 MHz dual processor i686 600 MHz machine: ls: /doesnotexist: No such file or directory -- correct nothing at all -- wrong ls: select: Bad file descriptor -- wrong

For the last couple months, Nuance has performed extensive testing on how the Opus codec performs in the speech recognition task. I'm hoping to publish a full report in the coming months, but until then all I have is a teaser. Opus performed within about 1% of the WER (Word Error Rate) of unencoded audio. This is compared to about 5% for Speex, which was the previous codec of choice. Well

Position: Statistician in a systems biology team focused on metabolic disorders such as diabetes and obesity. The position is part of a statistics group supporting Pfizer global research and development. Role and Responsibilities: The statistician will be an integral member of a systems biology team which develops and/or uses computational and statistical approaches to manage and derive

Thanks. Unfortunately, that made no difference. On Fri, Nov 30, 2018 at 1:20 PM Thomas Durand <tom at rezoo.org> wrote: > Exactly - I removed then with > *find* . -name "dovecot.index*" -type f -delete > > There is no need to restart dovecot. IMAP client will be forced to resync > all the emails from the server. > > > Le 28 nov. 2018 ? 23:20, JCA

Thanks; I did not think of that. I have just run a few basic tests with both rsync and OpenSSH in their default settings, when it comes to compression. SSH compression seems to have a very slight edge. However, I surmise that, given the number of knobs available on both sides (OpenSSH, in particular) one can tinker with settings almost endlessly in either side, probably being able to end up with

Rsync supports the capability of compressing data before sending. So does OpenSSH. It would be probably be a waste of resources and time to enable both compression capabilities at the same time, but it is not clear to me whether, in general, it makes better sense to enable rsync compression or SSH compression. My first thought would be that SSH compression might yield better results, on the

Thanks. Assuming that the IMAP mail directory for the account affected is under /home/xyz/mail, are you talking about the contents of the index directory, excluding the log file therein? On Wed, Nov 28, 2018 at 2:29 PM Thomas Durand <tom at rezoo.org> wrote: > Hi, > > I had the similar messages after an upgrade then downgrade. I was able to > fix by removing all indexes files.

Background ========== "ssh -f ..." causes ssh to fork into the background when userauth successfully completes. WHAT === With this patch "ssh -f -f ..." causes ssh to fork into the background when the first forwarded port/x11 display/agent is successfully opened. WHY === This feature makes launching remote X11 apps more reliable: when ssh exits it must have exited because