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.
