Mailing List Archive

On Thu, Nov 03, 2005 at 10:26:30AM -0800, lorne vaught wrote:
> Was there a major change between 7.2.7 and version 8 that would cause this
> difference in response? Is there an option I should configure that will address
> this issue? Anyone using a similar configuration of OS, terminal server, version?

wow...interesting! there were so many changes, i'm not sure what would
be going on. but, i am curious what telnet options might be
negotiated...this might (maybe?) be triggering something bad. the
easiest would be to have conserver only connect a single port and run
with -DDD. then use the client, connect, type a few things, and shut it
all down. if you could send that info, perhaps something will look
suspicious. if the 'got telnet' and 'sent telnet' debug lines don't
show me much, perhaps the other will.

and what happens if you have conserver connected to one port and you
telnet to another? does that second port respond slowly? if so, we
must be making the term server go ballistic. if not, then it's
undoubtedly all inside conserver (assuming that one console is still
showing lags).

there's my 2 cents on where we should start.

Bryan
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

oh, and one way to test if the telnet options are causing issues, you
can use 'protocol raw;' to tell conserver to just send bytes...no option
negotiations. that might be an interesting test.

Bryan
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

lorne and i have been working offline about this and it looks like the
perle term server (CS9032) has a telnet option processing bug. at
least, that's what i believe. after looking at the debug output, it's
obvious that the "ECHO" and "SGA" options keep getting renegotiated,
which is causing the lag. the term server is running 8.3.0G (basically
the latest), and perle has been notified (though they haven't confirmed
there is a bug or have an eta for a fix - since i don't have a support
contract). but it has been sent to their engineering group, at least.

if anyone else runs into this, one way to work around the problem is to
set the 'protocol raw;' option for the consoles. that will prevent
conserver from doing any telnet option negotiation (though you'll end up
with those coming out a text, being sent to clients and logged to
files...but that's just an annoyance). i'm currently thinking about
putting some logic in conserver to determine when it's already "acked"
an option and to ignore future ones. this is kind of specified in the
telnet rfc (854):

b. If a party receives what appears to be a request to enter some
mode it is already in, the request should not be acknowledged.
This non-response is essential to prevent endless loops in the
negotiation. It is required that a response be sent to requests
for a change of mode -- even if the mode is not changed.

it's kind of ambiguous (does this apply to "DO" requests only or "DO"
and "WILL"?). i also think i'll be looking at a good open-source
reference implementation, just to see what others do. anyway, a
non-response should be ok, i think.

and here's the summary of the option negotation, for those who are
curious. it doesn't stop at the end...it keeps bouncing between ECHO
and SGA.

Term Server Conserver
----------- ---------
WILL ECHO ->
<- DO ECHO
WILL SGA ->
<- DO SGA
DO TERMTYPE ->
<- WONT TERMTYPE
WILL ECHO ->
<- DO ECHO
WILL SGA ->
<- DO SGA
DONT TERMTYPE ->
WILL ECHO ->
<- DO ECHO
WILL SGA ->
<- DO SGA
WILL ECHO ->
<- DO ECHO
WILL SGA ->
<- DO SGA

Bryan
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users