lsh-bugs August 2003

lsh-bugs@lists.lysator.liu.se

7 participants
9 discussions

Start a nNew thread

e10611434346123.38996957988
by Dennis Heuer 18 Aug '03

18 Aug '03

1 0

lsh working with gss
by Dennis Heuer 17 Aug '03

17 Aug '03

I tried lsh-gss-2003-08-16.tar.gz and it works properly for me thanks Dennis

1 0

e10610317731524.80585034937
by Dennis Heuer 17 Aug '03

17 Aug '03

1 0

got parse error as below
by Dennis Heuer 16 Aug '03

16 Aug '03

In file included from client_userauth.c:58: client_userauth.c.x:516: syntax error before "gss_name_t" client_userauth.c.x:516: warning: no semicolon at end of struct or union client_userauth.c.x:517: warning: type defaults to `int' in declaration of `ctx'client_userauth.c.x:517: warning: data definition has no type or storage class client_userauth.c.x: In function `do_client_gssapi_state_mark': client_userauth.c.x:528: dereferencing pointer to incomplete type client_userauth.c.x:529: dereferencing pointer to incomplete type client_userauth.c.x:530: dereferencing pointer to incomplete type client_userauth.c.x: At top level: client_userauth.c.x:537: sizeof applied to an incomplete type

3 4

Re: got parse error as below
by nisse＠lysator.liu.se 16 Aug '03

16 Aug '03

Dennis Heuer <dh(a)onclick.org> writes: > I appended the config.h and the Makefiles of ./ and src/. As far as > I understood the thousands of parameters everything is set correctly > but I need you to check this, really... The gss related entries of your config.h: /* Work around buggy MIT library */ /* #undef GSS_C_NT_HOSTBASED_SERVICE */ /* Define to 1 if you have the <gssapi/gssapi.h> header file. */ /* #undef HAVE_GSSAPI_GSSAPI_H */ /* Define to 1 if you have the <gssapi.h> header file. */ /* #undef HAVE_GSSAPI_H */ /* Define to 1 if you have the <gss.h> header file. */ /* #undef HAVE_GSS_H */ /* Define to 1 if you have the `gss' library (-lgss). */ #define HAVE_LIBGSS 1 /* Define if gss should be used */ /* #undef WITH_GSS */ /* Whether to use gss K5 authorization (Heimdal/MIT) */ /* #undef WITH_GSS_K5 */ which seems to imply that the configure script didn't find any of the gssapi header files. (That shouldn't break the build of course, you should just get lsh built without any gssapi support, so that's a bug in the gssapi patch). Regards, /Niels

1 0

ADV: Interested in outsourcing your tech support?
by SpeakWithaGeek.com 14 Aug '03

14 Aug '03

1 0

Re: TCP_NODELAY
by nisse＠lysator.liu.se 11 Aug '03

11 Aug '03

Ok, this is a little embarassing... As some of you probably have noticed, I managed to get vacation set up wrong, and I've had some mail bounces. And the funny part is that mailman decided I shouldn't get any more lsh-bugs mail. Anyway, I've now reenabled mail delivery, and I have read the TCP_NDELAY discussion in the mail archive. I'm not terribly familiar with Nagle, but I have some comments: 1. When having an interacting session, and sending two keystrokes "X" and "Y", one may end up with loads of IP packets: Client Server ---> "X" First keystroke (a) <--- TCP ACK Ack of the data (b) <--- SSH ADJ SSH_MSG_WINDOW_ADJUST (c) ---> TCP ACK Ack of above message (d) <--- "X" The server pty echoes the data (e) ---> TCP ACK Ack of the echoed data (f) ---> SSH_ADJ SSH_MSG_WINDOW_ADJUST (g) <--- TCP ACK Ack of the above message. (h) ---> "Y" Next keystroke (i) ... Etc Then TCP uses extra delays to try to get the acks and echoes into fewer IP packets, in order to waste less bandwidth. In general, that seems like a good thing to do, and ideally, (b), (c) and (e) should get lumped together into one IP packet, and so should (d), (f), (g) and (i). 2. I'm not sure which part of this trick is the "Nagle algorithm" , and disabled, and I'm not sure in which direction it is most important. To optimize this, one would need to look at some packet traces. 3. I'm not personally experiencing any lagginess, but perhaps I'm too tolerant, or use a too fast network (I don't use anything slower than adsl on a daily basis. At the moment, I'm typing over an interactive lsh/lshd connection over a 9 hop network, 10MB at my end point, and a 10ms roundtrip time). But I'm sure this is system and IP-stack dependent, so I'll be happy to add TCP_NDELAY call, if that helps for other people. 4. There's also one additional source of small delays in lsh: When setting the client tty into raw mode, lsh fiddles with the VMIN and VTIME values (exactly if and how has varied a little between versions). The intent is that if you type reasonably fast, there should not be a simple one-to-one correspondence between keystrokes and IP-packets, to make it a little harder for an eavesdropper to observe your typing pattern. Again, some packet traces would help to determine if this really works well. The code is in unix_interact.c: static struct terminal_attributes * do_make_raw(struct terminal_attributes *s) { CAST(unix_termios, self, s); CLONED(unix_termios, res, self); CFMAKERAW(&res->ios); /* Modify VMIN and VTIME, to save some bandwidth and make traffic * analysis of interactive sessions a little harder. */ res->ios.c_cc[VMIN] = 4; /* Inter-character timer, in units of 0.1s */ res->ios.c_cc[VTIME] = 1; return &res->super; } This should result in an extra delay of MAX(0.1s, 3 * your intertyping time). I'd be happy for corrections to this description, as well as experiments with changed TCP and TTY options. The patch that adds an setsockopt(..., TCP_NODELAY) to io.c:io_connect seems to hack at the right place for the client. There should probably be configurable so that it is used only when running under a tty. For the server side of things, the corresponding funtion seems to be io.c:do_listen_callback. As some noticed, after editing io.c, the Makefile will want to recreate io.c.x, which will fail if you don't have guile or scsh installed. For these changes, it should be safe to just touch io.c.x to convince make that it is up-to-date. Best regards, /Niels

2 1

GSS support?
by Simon Josefsson 10 Aug '03

10 Aug '03

Anyone interested in working on adding GSS-API authentication a'la http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-06.txt to lsh? I'm currently working on my own GSS library (see <http://josefsson.org/gss/>) and while far from finished, it can now talk to other clients/servers via GSASL or Mailutils. I'd imagine adding the GSS support to lsh would stress test more stuff in the GSS library, so it looks like a good next step for me. However, as I'm not familiar with lsh (the gc stuff make it look a bit complex) I would appreciate if someone else did the lsh part of the work :-) or at least had an opinion on if doing this is feasible without becoming a lsh guru. Is there some major component missing from lsh that would be needed before the GSS auth/kex idea can be implemented? (Of course, once written, it will work with other GSS implementations too, like MIT Kerberos 5, Heimdal, Sun, Globus etc.) Thanks, Simon

4 17

TCP_NODELAY ?
by Pete Naylor 08 Aug '03

08 Aug '03

I'm noticing that lsh seems terribly laggy when used for an interactive shell. Looking at the source I don't see the TCP_NODELAY socket option set anywhere. Perhaps this could be added (possibly only for an interactive shell if that can be determined) ? I did try to add it to the setsockopt call in io.c myself to see if it'd help, but for whatever reason it doesn't want to build after I make any edits - something to do with the abstraction stuff I guess. -- Pete Naylor

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

lsh-bugs August 2003