| I interpreted it as it was sent from the terminal, which makes me
| question if the terminal is configured for XON/XOFF. I _think_ this
| would happen;
| 
| 1. Computer->terminal: Terminal expects XON and gently throws away
|    everything sent as line noise because it never gets any XON/XOFF.
| 2. Terminal->computer: Terminal sends XON ^D XOFF, computer receives
|    this and sends XON to login which eats it up as part of the login
|    name, ^D - login dies and respawns, XOFF - part of a new login
|    name.

Okay, but my impression of XON/XOFF flow control is this - a device
will send XOFF iff it cannot buffer any more characters at the current
rate they are arriving, sending XON when the buffer is at low-water or empty?

I do not believe it is used on a per-character hand-shaking basis or you
would obtain something like < 33% actual through-put because 2/3 of the
characters on the wire are XON/XOFF?

I admit there are more terminal-cable-system combinations than I'll ever
see in my lifetime, but the few I've seen over the years general produce
some garbage on the screen if the connection is basically there - a question
of baud, start/stop bits, parity and so on.

Yeah, by all means, you don't want the terminal at this point trying
to do any flow control - nothing as primitive as XON/XOFF anyway.
Hardware RTS/CTS flow control is virtually required for high-speed
serial work (e.g. high-speed modem).  Using DTR/DSR flow control
would be A Bad Thing(tm) as the driver is likely using this normally
to determine whether a real terminal is present on the line - and will
be keeping getty hanging on the tty open waiting for DTR.

This sort of hand-shaking is commonly used to avoid yet-another-tty-line
that goes off to somewhere generating spurious noise that getty keeps
spinning on trying to carry on a logical conversation with! 8-)

Oh it also should have the "cute" effect that when someone walks into
the "lab" and switched the terminal on, that DTR comes active and
the getty wakes up and the open succeeds and out goes a login banner.
The user leaves and turns the terminal off and the driver then blocks
the process on open as DTR is no longer active.  The state-change can
also have the effect of hanging the user up as the driver forces a close
on the signal state-change, e.g. CD going off indicating the "modem"
no longer has a carrier on the phone line ... or when DTR is wired to CD
and the line goes dead (i.e. terminal is turned off).

Of course all these signals can be "tweaked" based on stty settings
I believe, e.g. to ignore or whatever.

-- Ken