From: Charles Hedrick (hedrick@dartagnan.rutgers.edu)
Date: 05/25/92


From: hedrick@dartagnan.rutgers.edu (Charles Hedrick)
Subject: new ka9q ready
Date: 25 May 1992 17:49:04 GMT

The new ka9q is now ready. I've put it on my own system, as usual,
since I'm still not sure how to get it on all the archive systems. I
trust the masters of the archives will have no problems getting it.
It on cs.rutgers.edu, in /pub/linux/ka9qsrc.tar.Z and ka9qbin.tar.Z.
The binary is a static linked executable and documentation. There are
a number of changes:

  - a workaround for a bug in libc 2.11c. This was compiled
        with 2.11c using the same optimizations as the kernel.

  - a bug fix to the compression code that makes it recover
        much more quickly when a packet is dropped. Previously,
        connections would hang for around 30 sec. after a drop.

  - major changes to the telnet application. It now responds to
        more telnet negotiations, and the user interface looks
        a lot like a Cisco terminal server. This required
        making the underlying TCP understand urgent data.

  - READ.ME has been updated to include a discussion of how you
        get SLIP started, and a few other things have been
        clarified. The new features are described.

  - the recommended default packet sizes have been lowered, due
        to more experience. I'm not sure what has changed, but
        I suspect the better serial driver in 0.96a may have
        made smaller sizes feasible.

Someone asked me to put in the support for the Ethernet devices. I
have lost the request. If you'll tell me exactly what diffs need to
be installed, I'll try.

The new telnet support is described in READ.ME, but here's a summary.
You'll notice some similarity to the way the Cisco terminal servers
work (which is itself modelled after the TOPS-20 "tn" program).

  - in full duplex mode, the escape character (by default
        a ^]) is now a prefix. You must type another character.
        Two escapes will send a real escape. escape x will
        return to command mode. escape ? will print help.
        Escape followed by other characters will send the telnet
        special characters. These are non-ASCII characters that
        are sent using special telnet codes: b - break, c - interrupt,
        o - abort output, t - are you there?, h - erase character,
        u - erase line. The characters are folded, so escape followed
        by b, B, or control-B will all work.

  - telnet understands urgent data and data mark, which together
        form a "telnet sync". Telnet sync is used when you type
        something that interrupts output, e.g. ^C or ^O. If the
        other end does the right thing, output should stop
        immediately and resume at the right time. If you're
        watching the modem, you'll see that some packets come
        across after you have typed ^C, but are not displayed.
        This is because a lot of data is in buffers at various
        places along the way, and there's no easy way to clean
        it out. Note by the way that the telnet sync is generated
        by the other end. KA9Q doesn't know that ^C is special
        (at least not in full duplex), because the system you are
        talking to may use some other character (like ^Y for VMS).
        Thus the other end must send the signal saying to stop
        output. That signal is sent "out of band", so it arrives
        before other output that has been queued. This mechanism
        doesn't work very well with most telnet's. It's interesting
        that it seems to work quite well here. Note that the
        standard Sun telnetd does not send a sync. We use a
        beta copy of the 4.4 telnetd. In the process of
        implementing this I found a serious omission in iostream.
        We need an fclearbuf, which clears buffered data. I've
        done fflush followed immediately by the ioctl to flush
        output, but that's not quite right.

  - half duplex (line at a time, local echo) mode is forced on
        systems like IBM, which negotiate local echo. You can
        force half duplex by using "echo refuse". In half
        duplex, the escape character still returns you to
        command level. You can send the telnet special characters
        by typing control characters: ^B, ^C, ^O, ^T. My
        assumption was that in half duplex, you were unlikely to
        run applications like Emacs, that want the full set of
        control characters. Thus the two-character sequences
        using the escape are unnecessary. If this turns out to
        be false, please tell me. Note that some IBM software
        wants a telnet break to generate an IBM break, whereas
        other software seems to accept only a telnet interrupt
        process. Thus you should try both ^B and ^C. I confess
        that I haven't done as much work on half duplex as
        full duplex, because I don't use half duplex. (However
        I did test to make sure that break works.) It might make
        sense to enable local flow control when in half
        duplex, and it may also turn out to make sense to use
        the two-character sequences beginning with escape.

  - telnet understands the option for doing local flow control.
        Normally telnet disables ^S and ^Q. That's because some
        common applications -- e.g. emacs -- use them as command
        characters. However if your telnet daemon implements the
        "remote flow control" option, ^S/^Q will work when you
        are in normal mode, and be disabled when you are in emacs.

  - "trace telnet on" will get you a trace of negotiations and
        urgent data.

NB: remember, the term "escape" is being used to refer to a
user-selectable special character. Normally this is *NOT* ESC (ASCII
27). By default the escape character is set to ^], which is the
default for Unix telnet. I think I prefer ^^, which is the default on
TOPS-20 and Cisco terminal servers.