I see this problem as well when I cat large files.
lsh-0.2.2 Linux RedHat 6.1
"Eric J. Schwertfeger" wrote:
>
> Just what does the error message "Channel data overflow. Extra data
> ignored." mean? When I first saw it (with 0.2.1), I thought that this was
> part of the compression problems that people have been talking about.
>
> Obviously, at some point, something is writing a packet that is larger
> than it is supposed to be, because nothing is missing that I can see.
> When it happens in the middle of a (very) long ls -lR, it shows up in the
> middle of the line, but the text before the message and after the message
> are supposed to be the same line, and no other lines are missing.
>
> (The rest of this message is only for the curious, I do intend on beating
> this problem myself)
>
> The problem still occurs with 0.2.2, however. So I tried using the
> options -n -z, which by my reading of lsh --help means that
> compression should be disabled. The problem persists, so either I didn't
> read the help text correctly, or the problem isn't with compression at
> all.
>
> Is anyone else seeing this? (Yes, I've come up with other problems
> that noone else is seeing) I'm only seeing this on one of the machines
> I've tested (machine A in the description below). In both cases, I test
> it by using lsh to connect to localhost, then "ls -lR /".
>
> All three machines are FreeBSD 3.3-R boxes, with 0.2.2, and the
> generated config.h is identical on all machines, and the diffs to
> Makefile are minimal.
>
> ~/anv-lsh> diff Makefile /usr/ports/security/lsh/work/lsh-0.2.2/Makefile
> 66c66
> < BASH =
> ---
> > BASH = /usr/local/bin/bash
> 73,74c73,74
> < SCHEME_NAME = false
> < SCHEME_PROGRAM = false
> ---
> > SCHEME_NAME = scsh
> > SCHEME_PROGRAM = /usr/local/bin/scsh
>
> However, the lshd compiled by machine A is 24 bytes larger. I thought
> that this was the problem. However, the behaviour doesn't change even if
> I use the binaries generated by the other machines.
>
> Machine B, on the other hand, is the only machine that demonstrates any
> instability. lshd on that machine tends to die when I exit lsh, and in
> some cases, the xterm that the lsh was in will start beeping furiously.
>
> Machine C makes lsh look as rock solid and stable as rsh is on any of
> these machines. Haven't had a warning or a crash in any non-error
> situation.
>
> Unfortunately, machine B is the clean install, so I can't count on machine
> C reliability when I distribute my port.
>
> I've also tested non-localhost lsh in both directions between A and C, and
> it looks like whatever the problem is, it is in lshd. B is behind a
> firewall blocking port 22, so I can't test it until I get onto that
> machine and run lshd on a different port.
