Keresztfalvi Gabor <[EMAIL PROTECTED]> writes:

> Zlib seems to work now, but an other problem occured, when I tried to
> check whether it really compresses:
> heloka:~/lsh/lsh-0.2.2/src>./lsh --no-pty -p 4711 localhost >c
> Password for keresztg: 
> User authentication successful.
> cat /vmlinuz
> read_packet: Receiving too large packet.
>   32788 octets, limit is 32768

Hmm. Seems that the test in read_packet is a little too strict. The
spec says:

: 4.1.  Maximum Packet Length
: 
: All implementations MUST be able to process packets with uncompressed
: payload length of 32768 bytes or less and total packet size of 35000
: bytes or less (including length, padding length, payload, padding, and
: MAC).  Implementations SHOULD support longer packets, where they might
: be needed e.g. if an implementation wants to send a very large number of
: certificates.  Such packets MAY be sent if the version string indicates
: that the other party is able to process them.  However, implementations
: SHOULD check that the packet length is reasonable for the implementation
: to avoid denial-of-service and/or buffer overflow attacks.

So we should either increase the limit to something larger than 35000,
or at exactly 35000. In the latter case, we have to calculate the
limit given the length of the current MAC algorithm.

> If there is no --no-pty param, then everything seems OK.
> Further details (if necessary) after tuesday (indeed, after Control
> Theory exam).

I'm not sure why --no-pty matters. I would guess it's buffering inside
the pty driver.

> P.s.: In ChangeLog Kerezstg != Keresztg and I prefer Keresztg. ;)

Fixed. I have to learn that you and Bazsi spell differently.

/Niels

PS: Bazsi, I have your latest proxy patches here, but haven't applied
them yet. Too many of those other bugs... At least, I think they
should still apply cleanly.

Reply via email to