"Eric J. Schwertfeger" <[EMAIL PROTECTED]> writes:
> 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.
lsh/lshd prints this message when the other end exceeds the window
size it has been given. It's a flow control error rather than a packet
format error. Even if bugs in packet formating or could show up as
flow control errors. But it seems unlikely that bugs in the
compression support should cause flow control errors; things like
truncated packets should be detected earlier, and cause a protocol
error and a disconnect.
> 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.
Hmm. I guess the help message needs some improvement. The default
behavior is to support zlib (in case the other end requires it), but
not ask for it. I.e. the list of compression algorithms, in preferred
order, is "none, zlib".
Saying -zzlib (or just -z, for convenience) changes that list to only
"zlib", i.e. it makes zlib the preferred algorithm, and handshake will
fail if the other end doesn't support it.
Saying -z none changes the list to "none", i.e. make no compression
the preferred mode of operation, and the handshake will fail if the
other end insists on using compression.
The other algorithm options (-c and -m) works the same way, but with
different defaults.
-n only applies to flags classified as "modifiers", and that have both
--foo and --no-foo versions. It is mostly useful for those modifiers
that have short equivalents, i.e. -n -t instead of --no-pty. And only
for lsh, not lshd.
/Niels
