So when you
hit Ctrl-C under a typical Telnet client in Unix, you
are sending the equivalent of a 'process' interrupt.
Most likely an
Interrupt Process (0xff 0xf4) sequence, quite possibly
an Abort Output (0xff 0xf5) and/or a Synch (0xff 0xf2 with the TCP
urgent pointer pointing just after the 0xf2) as well.
[...]
I'll snoop traffic and try a ^C to see what's really going on - at
the wire level, at least.
I've now got something to report.
This may well vary according to the telnet client. The test I did was
with a moderately old NetBSD telnet client.
When I typed ^C, I saw, on the wire (in hex), ff f4 ff fd 06. This is
IAC IP IAC DO TIMING-MARK. But I never see IAC WILL TIMING-MARK or IAC
WONT TIMING-MARK coming back, which is probably why the telnet client
hangs - it's expecting one or the other. (And, in passing, it doesn't
actually hang; I can type and what I type goes out. But it doesn't
show me anything that comes back, even though data does come back,
presumably waiting for a response to its IAC DO TIMING-MARK.)
I did server-side code for a mud for which we wanted to support telnet
connections. I had to make the server recognize enough protocol to
refuse to negotiate any options on (IAC DO xxx produced IAC WONT xxx;
IAC WILL xxx produced IAC DONT xxx). If you could do that much, and
swallow most (all?) of the other IAC xxx commands, telnet will probably
work better to connect to it.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
